April 19, 2015

Scrum advantages explained – in 2 simple whiteboard sketches (part 2 of 2)


Image you had only ten minutes plus a whiteboard to convince people to introduce Scrum in your organization. What would you tell and show? I would try to capture the essence of how Scrum improves your software development process. Two whiteboard sketches should be enough for that. Check out sketch one first. Here’s sketch two.

Scrum is founded on the same pillars other agile methodologies consider crucial factors for successful software development – people and knowledge.

In this second post I’d like to show how Scrum embraces uncertainties and supports knowledge building by deferring decision making. This is what my second and last whiteboard picture illustrates:

Tranditional vs. Scrum approach to knowledge building in a whiteboard sketch

The “Traditional” approach

In a “traditional”, waterfall-based project, all decisions are made up front. It’s exactly laid out what will be done, how it will be done, what technologies and tools are used, how the team works together and with the customer, and exactly how long everything is going to take. This is what the sketch illustrates:
  • At the beginning of the project, all decisions are made for the entire length of the project. Detailed effort estimates are made for every single forecasted work item. These initial decisions are irrevocable as the project planning is hard-wired to match the original effort estimates.
  • After the project started, few adjustments can still be applied to the initial planning, but more profound changes which would endanger the initial planning are impossible, and shortly after that, no further decisions will be made, or can be made.
  • Even if the project’s duration is separated by milestones which provide a means to inspect, they do not provide a means to adapt as the project must go on based on the initial planning.
Unfortunately, this is exactly the opposite of how building knowledge throughout the project works. This is especially unfavorable as knowledge is the single base for the decision making process. The whiteboard sketch illustrates this very clearly:
  • At the beginning of the project, knowledge is naturally zero. We do now know anything about the customer or what he wants, we do potentially not know the project’s technological base or how the team’s individuals will work together.
  • However, after the team started to work on the project, as it collaborates and as it interacts with the customer, it will quickly build up knowledge about the stakeholders, tools and processes involved in the project. Its knowledge will typically increase sharply right after beginning, and continue to grow until it reaches a high, stable level.
Now, the problem with this project model becomes apparent. To sum it up, all decisions are made when there is the least amount of knowledge in place; and as soon as there is more knowledge, no more decisions will or can be made. That does not sound like a good plan!

The Scrum approach

Scrum, on the other hand, embraces uncertainty at project start, and allows the team to adapt its strategy as knowledge is gained. Let’s at first observe the knowledge building process in Scrum:
  • There are no differences to a traditional project and there is no magic involved. The team will build up knowledge as it works on the project. This knowledge is gathered in an empirical process.
 However, Scrum addresses the process of how knowledge is naturally gathered by adapting the way decisions are made:
  • There is no need nor use for a detailed overall plan. At the beginning of the project, only those decisions are made which are required to perform the work of the first Sprint. (In reality, in the first Sprint, there are potentially a few more decisions made than in later Sprints.)
  • As in a waterfall-based project, throughout the Sprint, there are fewer and fewer opportunities to make decisions and adapt. This is okay as only a bare minimum of decisions are involved in the Sprint’s initial planning, unable to endanger the entire project, and as a single Sprint will not last longer than four weeks.
  • At the end of the Sprint, the team’s performance will not only be inspected, but the strategy and planning can also be immediately adapted as the team can now, based on its experiences in the current Sprint, plan the next Sprint.
  • Dividing the project into Sprints obviously is key to the success of this model. Each Sprint offers the opportunity to both inspect and adopt. Thus, each Sprint could in fact be considered a small (waterfall) project on its own!
Scrum is based on the agile method of positive procrastination to defer decision-making and commitment until the utmost amount of knowledge, essential to back any decision, is gained. It also reduces risk by only allowing to make decisions about the immediate future and within a well-defined and confined scope. This process model really values knowledge as the key ingredient to software project management. Knowledge is brought back into the process frequently, and knowledge building is highly encouraged and thus potentially enhanced.

Conclusion

As these two articles have shown, Scrum’s advantages for managing two major driving forces of software development – people and knowledge – are tremendous.

Scrum gives responsibility and authority to those who have the knowledge and eligibility to perform the actual work: the Development Tean, and the customer as the domain expert and Product Owner. It facilitates communication and collaboration within the Development Team, and between the Development Team and the Product Owner (customer). This is key to increase transparency, thus helping to build trust, lower risk, and increase Team motivation.

Scrum embraces the complexity and uncertainty which come with software development, and most notably with custom software development, and it accepts initial lack of knowledge and experience, allowing the Team to learn from its mistakes, following an empirical path, whilst considerably lowering the risk of any failure by enforcing clear, time-boxed scopes for planning and decision making.

These are, in my opinion, two very strong points for Scrum and Agile. They make it very clear that any waterfall-based approach is very ill-suited for the shaky business of software development.

Please let me know in the comments section whether you agree with my position. I am also highly interest in hearing how you would try to convince the essence of Scrum “in ten minutes or so” – or even how you would support an attitude of refusing Scrum.




Pages: 1 2

No comments:

Post a Comment