Annotated Bibliography & Problem Statement

Agile_by_Design_An_Implementation_Guide_to_Analyti..._----_Chapter_5_Analyticsthe_Agile_Way.pdf

Home >Business & Finance homework help >Operations Management homework help >Annotated Bibliography & Problem Statement

Chapter 5 Analytics—the Agile Way Analytic teams have a lot of different project delivery methods to choose from, each with their own pros and cons. If the analytic team is using a delivery methodology, most often it's the standard waterfall delivery model, where work falls in a phased, sequential approach. However, due to the ambiguous nature of analytic projects, agile methods provide analytic teams with much-needed structure and delivery discipline, while respecting the creative and iterative nature of analytic projects. Navigating the agile family of methodologies can be confusing for any team. This section provides a brief overview of the most prevalent methods and recommendation for selecting the right method for your team (see Figure 5.1).

Figure 5.1 Analytic Project Management Decision Considerations

Getting Started

Alt-Simmons, Rachel. Agile by Design : An Implementation Guide to Analytic Lifecycle Management, John Wiley & Sons, Incorporated, 2015. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=4041094. Created from harrisburg-ebooks on 2020-11-16 07:31:52.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Isabel sits down with her stakeholders. “Okay, folks, let me tell you a little about how my team works and how we'd like to engage with you as we go through this project. We know that the quality of our deliverable is critical, but we're also sensitive about speed. Analytics projects are unique, since we don't often know what the outcome will be. But we don't want to go hide out for six months without giving you any insights along the way.

“Back when I started at the company, we didn't use any project management methodologies to run our projects, and it was chaotic! Nobody knew what anyone was working on and everyone had different ideas about how the work should be done. We even got into trouble because we found that one of our analysts had personally identifiable information on his laptop. We didn't have any way to understand if our work was really important to the business and there wasn't any mechanism for prioritizing projects.

“Management got really tired of that. They hired a new executive to run the team and put some control mechanisms in place. The problem was that we went in the opposite direction: We'd gone from a free-for-all to a bureaucracy overnight. The new process included nine different approval stage-gates. We weren't allowed to move to the next phase of work unless everything was perfect—and nothing in analytics is perfect the first time! Nobody in the business wanted to leverage our team because it took too long to get approvals and to complete the work. The business started hiring consultants to do the work that we were supposed to do! They said we weren't customer-friendly and couldn't deliver in their time frames.

“As you can imagine, that executive didn't last very long. I was promoted to lead the team, and as part of my new responsibility did some research on some of the newer project delivery methods that have gained a lot of traction in the IT space. We needed to find something that respected the creative and iterative aspects of analytic delivery, but gave us some structure and discipline. I found that many companies were starting to use something called agile. But the more I looked into it, the more confusing it got—there were a lot of different agile methodologies to choose from—how would I know which one would be right for us?”

Understanding Waterfall The statistician, Dr. Edward Deming, began working with auto manufacturers in the 1950s to create continuous improvement and quality cycles, popularly known as the Plan-Do-Check-Act (PDCA) model (also referred to as the Deming Cycle or Circle). Over time, the strict approach to process quality in manufacturing was adapted to the software development processes in the form of the software development lifecycle (SDLC). The SDLC is one of the original “waterfall” processes and follows a highly structured sequence of events from analysis and design, development, testing, and release. The SDLC provides the underpinnings of the traditional software development model, most popularly used in methodologies such as the Project Management Institute's project management methodology.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

The waterfall model follows a phased, sequential approach, as shown in Figure 5.2.

Figure 5.2 Waterfall Development Process

The analytic development lifecycle (ADLC) follows a similar waterfall approach, as shown in Figure 5.3.

Figure 5.3 Waterfall Analytic Development Process

The primary criticism of the waterfall methods is that they attempt to be predictive. All of the requirements are gathered upfront, the design completed, a project plan created, and then the team runs off to build whatever the customer initially asked for. Changes to project scope are managed through sometimes-inflexible change control processes. The challenge is that that development cycle can take a long time; often when the final product is delivered, it may not be what the customer wanted or expected.

More often than not, analytic teams aren't using any project methodology at all in their projects.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

While that may make a lot of sense for smaller “just-do-it” work, lack of a disciplined approach can result in chaos once a model reaches the business and technology deployment phase. The beauty of agile methodologies is that they are adaptable and flexible in nature— they provide a level of control without being heavy-handed or introducing a lot of process overhead.

The Heart of Agile In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published an article in the Harvard Business Review titled the “The New New Product Development Game” (Takeuchi & Nonaka, 1986). They argued that in product development cycles, organizations could no longer solely compete on quality, cost, and product differentiation: Speed and flexibility were equally critical elements of the development process. The sequential development process used by many companies did not support business agility. The authors recommended that a “rugby” approach be used instead, “where a team tries to go the distance as a unit, passing the ball back and forth —[to] better serve today's competitive requirements.” Instead of a sequential approach that hands work off across functional areas, the rugby approach uses an integrated multidisciplinary team working together from start to finish.

By moving from a linear to an integrated approach, experimentation is encouraged. The close interaction between diverse team members stimulates ideas and discussions, acting as a catalyst for innovative product development.

Encouraged by Takeuchi and Nonaka's research, in the early 1990s, the software development community began to evaluate the rugby approach as a method to replace waterfall methods in project development cycles. There was growing recognition that the SDLC was not always effective at delivering value within complex development projects. In a waterfall project, all scope, time, and costs are defined at the start of the project when uncertainty is high. For complex projects, where the domain might not be well understood, the sequential nature doesn't allow for frequent feedback loops. Often, when the project was “complete” it was delivered late, over budget, and not meeting user needs.

Frustrated with poor alignment between waterfall and complex technology projects, a number of practitioners independently set out to create more effective ways to deliver products and services to customers and end users. While the methodologies varied widely, the approaches increased the development team's ability to (as agile is defined) “move quickly and easily” and unshackle itself from the process- and documentation-centric SDLC or ADLC model. These methods manifested into a number of different agile methodologies. The most popular of the methodologies, Scrum, honors the spirit of Takeuchi and Nonaka's recommendations on using the rugby metaphor to increase business agility.

The Agile Manifesto/Declaration of Interdependence In 2001, several leading practitioners and proponents of these agile software development

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

methodologies convened at a resort in Utah. The group shared best practices, identified common themes, and ultimately outlined a common purpose for agile practitioners. This purpose statement became The Agile Manifesto and established the grounding principles behind the agile philosophy for software development.

While the primary users of agile are software developers, the principles and techniques apply to other project environments. Practitioners can apply any of the agile principles to their own projects to drive customer value, productivity, and efficiency. In fact, agile is often considered more of a philosophy than a methodology. Simply put, the practitioners stated:

(2001, Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W. et al.)

You've probably noticed that the Manifesto is kept at a very high level. An important point is that agile focuses on the big picture, and while the values are uniform across the frameworks, the details that encompass each agile methodology will be implemented differently.

Let's briefly take a look at each value pair, as shown in Table 5.1.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Table 5.1 Agile Analytic Values

Agile Values What It Means Implication for Analytics Individuals and interactions over processes and tools

This principle highlights the value of people as the foundation of the project. Processes and tools are important, but it is people that get the work done. Agile emphasizes teamwork and collaboration.

Analytic groups need to integrate with the whole team—business stakeholders, application developers, ETL developers, etc. throughout the analytic development process—and work together.

Working software over comprehensive documentation

Agile's focus on delivering customer value places an emphasis on getting working software into customer hands quickly. This is not to say that documentation is not important, but that documentation needs to add value.

Focus on working together and creating a common language instead of trying to fix a broken development cycle with process overhead, templates, and documentation. Uncover what information is important to capture and institutionalize.

Customer collaboration over contract negotiation

A primary difference between traditional waterfall methods and agile is that the customer is a key resource that is often embedded with the delivery team. Your customers are best positioned to tell you what they want or need through the project lifecycle, not just in an upfront contract negotiation.

Business stakeholders and domain specialists are critical throughout the analytic lifecycle. They are best positioned to define what's important to the business and how the business works. Establishing relationships and building trust are important elements of deploying effective, relevant analytics into business processes.

Responding to change over following a plan

Agile's original intent was to facilitate better delivery of working, relevant software to end users. Anyone who has worked on a software project knows how quickly requirements or business needs change. The ability to adapt to customer needs is a critical point of difference in agile.

A key difference in an analytic project is that you don't always know what you will find. Analytic projects are iterative by nature, requiring constant revalidation of the business problem, the data sources used to analyze the problem, and the outcome.

Scrum and Scrum variants are by far the most popularly utilized methodologies. Interestingly, not only are a large percentage of companies adapting the methodologies to fit into their organizations, but we're also seeing an increase in hybrid methodologies that leverage right- sized practices from several of these methods. The implication for analytic teams is that most of these methodologies don't work well for you in isolation—there's no one-size-fits-all. Don't fall for the “my way or the highway” mantra positioned by a lot of external influencers. The following section will provide an overview of several popular methodologies, and then we'll

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

focus creating your own agile analytic framework.

The good news is that the core tenets of agile are at the heart of each of these methodologies. How you select a methodology depends on your organization, your culture, and the type of project that you're working on. If you're new to agile, Scrum may be a good place to start as it provides a simple framework that can expand and scale as your team gains confidence and maturity.

The bad news is that there's a lot of confusion out in the marketplace. Many consultants have created sub-methodologies and frameworks, each with their distinct characteristics, ceremonies, and practices. Unlike more mature methodologies, there's no single body of knowledge to use as a guidepost. So teams must carefully select the agile frameworks and practices that will work best in the context of their organization.

Selecting the Right Methodology It's important to note that agile methodologies are not appropriate for all types of projects and organizations, and that using an agile methodology is not a guarantee of project success. Agile analytic projects work best in environments where complex decision making requires an iterative development approach. Political and cultural challenges may necessitate a plan- driven approach, as will an environment that is too far over the edge of chaos and requires structure. Even if your project seems well suited to an agile methodology, cultural or organizational barriers may inhibit the success of the methodology. After all, agile projects are all about team empowerment—that in and of itself requires a significant cultural shift within many organizations.

In our ABP project, Isabel says: “As we work with our customers, we're flexible on the methodology that we use. One of the things that we uncovered early on is that different projects require different approaches. In fact, as we learned more about each of the methodologies, we found elements that we could pull together and make our own. Even more importantly, our internal customers are using different delivery methodologies in their projects—most of our work needs to integrate in some way with theirs. Agile gives us the flexibility we need to link our work together.

“When we created the methodology that our team would use, we first looked at Scrum since it seemed to be the most prevalent method.”

Scrum Jeff Sutherland and Ken Schwaber, the founders of Scrum, derived the methodology from Takeuchi and Nonaka's work, applying the rugby metaphor to software development practices. With its lightweight project delivery approach and applicability to different types of projects, Scrum has rapidly become one of the most widely used agile project management methods. Scrum leverages a simple iterative framework that is appealing to organizations looking to

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

incorporate agile into their development processes. The broad appeal of Scrum is enhanced by its applicability to multiple types of projects beyond the software development realm.

Scrum structures work into cycles called “sprints” of typically no more than 30 days in duration. During a sprint, the development team selects customer requirements in the form of user stories from a prioritized list. This allows the team to work on functionality that will deliver the most value to the customer. The goal at the end of each sprint is to have a potentially shippable product delivered to end users for feedback. Sprints are rolled into a predetermined release schedule.

Scrum features several distinct roles:

The product owner facilitates the process of identifying and prioritizing customer requirements and serves as the liaison between the development team and the end users. Requirements are captured as user stories and are organized and prioritized in a product backlog. At the start of each sprint, the project team selects the highest priority stories, estimates the work effort, and then plans the sprint based on the amount of work the team believes they can accomplish during the sprint. Once the sprint is complete, the product backlog is groomed and reprioritized by the product owner, and the team again selects the next highest priority requirements.

The ScrumMaster is responsible for facilitating (not directing!) project activities. His/her focus area is on keeping the team aligned to the Scrum process and removing impediments or interference with the team's progress. ScrumMasters may have a technical background, which helps smooth communication between the development team and the business community.

The development team is a cross-functional representation of people performing the work. The rule of thumb is to have five to nine people on the team. The development team members may have a variety of roles, such as programmers, architects, testers, database administrators, and so on. Scrum empowers the development team to self-organize. This means that the team determines how the work will be performed.

“The simplicity of Scrum was really appealing,” says Isabel. “Basically, we have three roles on the team. We ask our business sponsors to take the role of the product owner. We have a dedicated project coordinator role for our ScrumMaster—we make sure that they're trained in both traditional waterfall and Scrum methodologies, depending on the type of project that we're on. If the project is large enough, we'll ask architects, data modelers, ETL specialists, and data scientists to form the development team. Once we get the green light to get moving on this project, we'll determine who should participate and then get a meeting together.”

eXtreme Programming (XP) XP is a software development methodology based on four core values: simplicity, communication, feedback, and courage. XP's strength is rapid analysis, design, coding, and

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

testing cycles within short iterations, typically one week in duration with a collocated team. The emphasis on face-to-face collaboration eliminates the need for the team to run through long requirements for design and testing phases. Similar to Scrum, the team selects several user stories in each iteration and completes all development phases for each story. The software is deployed on a predetermined basis (often weekly) for review and feedback. A differentiator for XP is the technical discipline and sophistication of testing practices, which are highly automated.

XP is not widely used as a stand-alone agile methodology. Most teams incorporate XP technical practices into their processes as a way of ensuring quality in their deliverables.

Isabel walks back to her office with the new junior analyst on the data sciences team, Jeremy.

“I think you're really going to like working on this project, Jeremy. It will be a good opportunity for you to learn some of our team's operating principals. As we got deeper into Scrum, we realized that something was missing,” Isabel sits down and leans back in her chair. “Scrum provides a rhythm—it's like the beat of the drum—but it doesn't prescribe practices for getting the work done. Everything we do in analytics is pretty unique, but there are a lot of things that we wanted to make repeatable. We came to the realization that we needed to create our own technical best practices and bring them into the Scrum framework.

“I was talking with some friends of mine in the IT department. The told me about an agile methodology called eXtreme Programming, or XP. Their group had been able to incorporate some of the XP technical practices recommended into their Scrum implementation.”

Isabel goes on, “XP has twelve supporting practices and several of them were particularly important to us. We liked the XP concepts of Simple Design, Pair Programming, Refactoring, Collective Code Ownership, and Coding Standards. We took these concepts and made them relevant to our team's work. While these aspects of our agile analytic methodology might not be interesting to the broader organization, everyone appreciates the outcome in the quality of our work and our ability to consistently deliver regardless of the project. Once you get into this project, we'll assign a mentor to work with you and teach you some of the XP practices in our day-to-day work. Remember that agile is all about continuous improvement and providing customer value, so if you see ways that we can be doing our job better, don't be afraid to speak up.

“And finally, we use lean as a management philosophy and apply it to all of our other tools, techniques, and processes. Lean teaches us to see everything from the customer's perspective, only doing work that will add value to them. This helps us avoid process for process's sake.” (See Figure 5.4.)

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Figure 5.4 The Team's Agile Framework

Summary Analytic teams have many different options when selecting a delivery methodology. There is no “one size fits all” model. Cultural factors play an important role when selecting your methodology; it's important to understand specific needs and constraints within your organization. With its simple framework, Scrum provides a good starting point as it's easily extensible. Technical practices within XP can be incorporated to provide the team with more technical discipline in their delivery approach. Regardless of which method you select, follow the guiding principles of The Agile Manifesto: Focus on customer value and high-quality deliverables.

Takeuchi, H., and Nonaka, I. (1986, January). “The New New Product Development Game.” Harvard Business Review. Retrieved online from: http://hbr.org/product/new-new-product- development-game/an/86116-PDF-ENG.

C op

yr ig

ht ©

2 01

5. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

http://hbr.org/product/new-new-product-development-game/an/86116-PDF-ENG