Agile in General
- Waterfall Versus Agile
- An "Agile" Experiment
- Differences Between Agile, Lean, Six Sigma, PMP, and Other Methodologies
- Agile Is NOT for You ...
- Marketability of Scrum Certification and Consistency of Employment
- Certify THIS ...
- Getting the Most Value from Gatherings, Conferences, and Other Events
- I'm Certified--So, NOW What?
- Goodbye, My Friend
- Closing
Daniel Gullo, also known as “the hardest working man in Agile,” explores concepts that touch on various different areas and concepts of Agility in general. Some of these topics are Scrum related. Others address Kanban, Lean, and other approaches broadly classified under the Agile umbrella. The prompt questions and answers represent Real World examples and statements from REAL people; that is, the statements are presented exactly how they were conveyed to me by my students, clients, and others.
This chapter is from the book
This chapter is from the book
This chapter is from the book
)
When people begin to learn about Agile, they struggle with the values, principles, and practices. This is largely due to the fact that our ideal of what an organization looks like is far from what we cherish as part of our human nature. Instinctively and intuitively, human beings are inquisitive, experiential, exploratory, learning driven, and so on. The corporate world tells us that we must follow the rules and procedures—we must behave and conform.
When we adopt an Agile mind-set, we are really returning to our innovative nature as human beings by looking for ways to continuously improve in spite of process and procedures.
In this chapter, we explore concepts that touch on various different areas and concepts of Agility in general. Some of these topics are Scrum related. Others address Kanban, Lean, and other approaches broadly classified under the Agile umbrella. The prompt questions and answers represent Real World examples and statements from REAL people; that is, the statements are presented exactly how they were conveyed to me by my students, clients, and others.
Waterfall Versus Agile
Waterfall was first described in 1970 by Winston Royce in his seminal work “Managing the Development of Large Software Systems” where he mentions that it is something that is “... risky and invites failure.” Most often, people ignore or forget the key point of Royce’s whitepaper, which was intended to emphasize how iterative development is more effective than waterfall.
In essence, waterfall refers to phased development approaches; that is, any time there are various, distinct phases that occur in the development lifecycle with formal hand-off or sign-off procedures as a requirement for promotion to the next phase, we are talking about waterfall.
Figure 1-1 is an example of what a 12-month waterfall project looks like from a process flow perspective.
)
Figure 1-1 Waterfall delivery model
Notice that there is no tested working code until 9 to 12 months into the project. The value delivery in this case is delayed instead of occurring gradually throughout the lifecycle of the project (see Figure 1-2). If funding were cut somewhere along the way, there might not be any usable portion of the software; the entire thing would be thrown away. Also, the customers and stakeholders have no confirmation as the product is developed that they are actually receiving value for their investment or that the product will meet their expectations. They only have a “promise” of what the product will look like, what it will do, etc.
)
Figure 1-2 Waterfall value delivery
In theory, waterfall is very logical, and as arrogant and egotistical human beings, we believe that we can account for all contingencies, risks, and unknowns prior to the start of a particular development effort. However, history has shown time and again that we are notoriously bad at clairvoyance, fortune telling, seeing the future, and most of all, estimates. Our abilities to predict and mitigate risks, which include changes in customer requirements, market direction, and technical failures, are not the greatest.
Waterfall can work just fine in an organization that has projects where there are very specific requirements with no possibility that these requirements will EVER change. In order for this to be the case, there must be absolute certainty in terms of business strategy, customer needs, and stakeholder alignment AND absolute certainty in terms of technical design, architecture, and the implementation of the solution without any risk at all that change may be involved. Figure 1-3 shows Ralph Stacey’s various classifications of organization based on these parameters.
)
Figure 1-3 Stacey diagram—organizational complexity
In short, waterfall works in organizations where there is no change or uncertainty, but rather complete agreement and certainty around vision/strategy and technology.
Very few organizations have absolutely no change at all or uncertainty. Instead, most organizations struggle to implement rigid, predictive processes and experience issues when they encounter inevitable changes in customer demand, technology advances, legislative decisions, societal changes, shifts in workforce dynamics, and various other factors that affect development and delivery of products and services.
To more effectively deal with change, and even embrace it as a strategic and competitive advantage, organizations are better served using an iterative/incremental development and delivery approach for their products and services. This approach is also known as Agile.
Agile, strictly speaking, refers to the values and principles set forth by the Manifesto for Agile Software Development (aka “The Agile Manifesto”):
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Twelve principles are also cited, which build on top of these values:
We follow these principles:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity—the art of maximizing the amount
of work not done—is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Values and principles begin to describe and define the culture of organizations. When combined with the practices and other factors, we begin to see a full picture of the organization’s culture.
Agile does not specifically prescribe any practices per se. The 12 principles point people in the right direction, and the individuals decide what they hold true and believe in. However, if the people, management, and culture of the organization are not aligned with the values and principles, then there will be difficulties implementing Agile practices, regardless of what framework is selected. Simply stated: by definition, what makes an organization Agile is its beliefs and core values, not the practices it follows.
Agile frameworks such as Scrum, Kanban, and xEtreme Programming (XP) provide some lightweight “rules” by outlining practices that will help organizations embrace the values and principles in order to become more Agile in their thinking.
Scrum, for instance, defines a minimal set of roles, artifacts, and activities. All of these elements work together to produce valuable, working software every 1 to 4 weeks. In the worst case, the Development Team is producing a shippable increment of product value once a month instead every 12 months.
In Figure 1-4, we see what a 12-month project would look like in Scrum. Notice that there is shippable code EVERY Sprint. In this case, the Scrum Team has decided to release that shippable code into production every other Sprint.
)
Figure 1-4 Scrum delivery model
This reinforces the stakeholder(s) decision to fund this product development effort. Every Sprint, they get to see SOMETHING delivered to them, rather than yet another visit back to the “promissory note.”
Imagine that you are paying someone $750,000 to build a home for you. However, the builder is telling you that you won’t be able to see it, walk through it, etc., until it is completely finished. There is a significant risk that the house won’t be what you want in the end. You might change your mind about cabinets or the layout of the home. The builder may have misunderstood your requirements about cabling or how to orient the fixtures in the bathroom.
Now, suppose the builder puts stakes around the property and invites you out to do a “preliminary walk-through.” You notice that you would prefer to have the house rotated about 45 degrees counterclockwise on the lot. Then, when the builder has poured the foundation, you are invited out to walk the slab and basement. It looks great and meets your expectations.
As the home emerges, you have confirmation along the way that it is meeting your expectations, and there are opportunities for you to make subtle and even significant changes.
This is similar to how Scrum enables customers to see the value they are receiving as it is delivered (see Figure 1-5) and provides them with opportunities to subtly change their minds along the way so that they are assured they will have what they want in the end.
)
Figure 1-5 Value delivery in terms of usable features
Thus, the primary benefit of Agile versus traditional project delivery is that Agile provides opportunities to inspect and adapt while iteratively delivering increments of value throughout the product lifecycle, rather than just at the end.