Agile Scales, Waterfall Doesn't
•
8 likes•1,004 views
Vasco Duarte discusses how agile scales while waterfall does not. He defines scaling as when the effort to manage a project increases at a slower pace than the amount of work being managed. With waterfall, managing requirements gets exponentially harder as the number grows due to dependencies. However, with agile hierarchical requirements organization like epics, features, and stories, the effort increases more slowly. Therefore, agile scales better than waterfall for large projects.
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (13)
Similar to Agile Scales, Waterfall Doesn't
Similar to Agile Scales, Waterfall Doesn't (20)
More from Vasco Duarte
More from Vasco Duarte (8)
Recently uploaded
Recently uploaded (20)
Agile Scales, Waterfall Doesn't
- 1. Vasco Duarte Agile scales, Waterfall doesn’t
- 2. I am not
- 3. Vasco Duarte
- 4. Vasco
- 8. Disclaimer I’m experienced, but that means: I understand your questions Not: I know all the answers!
- 9. This is where the talk starts…(wake up… please…)
- 10. Ready? Here we go…
- 15. How?
- 16. What does “scaling” mean?
- 17. “Large Scale Scrum”? Craig Larman, Bas Vodde 2009
- 18. “Scale Scrum”? Schwaber, 2004
- 19. “Multi-teams project”? Cohn, 2006
- 20. “Distributed”? Sandra Durasiewicz, 2008
- 21. A definition for “scaling” Yours truly, now
- 22. Scaling = Process Property
- 23. A Software Development Processs scales if (and only if) the work it takes to manage a project increases at a slower pace than the amount of work being managed!
- 24. Relative Effort needed to manage a project when the project size increases Effort to Manage Does not Scale Neutral Scales Work being managed
- 25. Proposition 1:Scaling Property needs to apply to all “things” we manage in a project
- 26. Experiment Count “things” to manage Assess effort needed to manage those “things” If work to manage them increases faster than the number of things => process does not exhibit the property of Scalability
- 27. Growth in effort to manage those “things” Growth in number of “things” >
- 29. x = effort to manage 1 requirement
- 30. Nx = effort to manage N requirements
- 31. Nx = effort to manage N requirements without dependencies
- 32. When was the last time you saw a simple list of requirements without dependencies?
- 33. Effort to manage N requirements with pair-dependencies
- 34. Relative effort to manage a flat list of N requirements Effort to Manage Work being managed
- 35. In Plain English: Waterfall Requirements Management does not scale!
- 36. This is the cost of a non-scalable Requirements Management Process
- 37. Question 2: Does Agile Requirements management scale?
- 38. N Requirements organization in Agile User Stories 100
- 39. N Requirements organization in Agile 10 Features User Stories 100
- 40. N Requirements organization in Agile 1 Epics 10 Features User Stories 100
- 41. N Requirements organization in Agile 1 Portfolio Items – Customer marketable Epics Longer term planning (more than 1 iteration) 10 Features Where the rubber meets the road – what we do in one iteration User Stories 100
- 42. Different content abstractions for different stakeholders Product Marketing and Portfolio Portfolio Items – Customer marketable Epics Longer term planning (more than 1 iteration) Product Owner + Architect + UX Features Where the rubber meets the road – what we do in one iteration User Stories Team + Product Owner
- 43. As a Project Manager I want … 1 Epics 10 Features User Stories 100
- 44. As a Project Manager I want … 1 Epics 10 Features Less stuff to manage, so that I can keep my sanity!
- 45. Effort to manage N requirements with an Agile Requirements model Nx/102 Where N = number of requirements/user stories
- 46. The mental sanity graph…(BTW: lower = better) Waterfall Effort to Manage This is the difference between Agile and Waterfall The bigger the project gets… Where you want to be: Work being managed
- 47. Epics Features User Stories
- 48. Venues Transportation Accomodation Marketing
- 49. Different size = Different solutions Size does matter! Don’t solve problems you don’t have!
- 50. Blue Team Red Team (good guys) (bad guys)
- 51. “The first thing I told my staff is that we would be in command and out of control.”(US General Paul Van Riper, from Blink by Malcolm Gladwell)
- 54. Recap:Agile Scales, Waterfall doesn’t And hopefully you understand why now :)
- 55. Currently an Agile Coach in Nokia, Vasco Duarte is an experienced product and project manager, having worked in the software industry since 1997. Vasco has also been an Agile practitioner since 2004, he is one of the leaders and a catalyst in the adoption of Agile methods and an Agile culture at Nokia and previously at F-Secure. Vasco's humble contributions to the improvement of the software development profession can be read in his blog: http://softwaredevelopmenttoday.blogspot.com. You can follow Vasco on twitter: @duarte_vasco Foto credits: Flickr users http://www.flickr.com/photos/8867029@N07/ http://www.flickr.com/photos/_at/ http://www.flickr.com/photos/quenerapu/ http://www.flickr.com/photos/privatenobby/ http://www.flickr.com/photos/fotopakismo/ http://www.flickr.com/photos/hinkelstone/ http://www.flickr.com/photos/swamibu/ http://www.flickr.com/photos/cdevers/ http://www.flickr.com/photos/jamesbooth/ http://www.flickr.com/photos/dungodung/ http://www.flickr.com/photos/puppydogbites/ http://www.flickr.com/photos/talios/
Editor's Notes
- In 2003, back in the time when I started working in Agile SW development projects there’s one comment I heard over and over again. And that was: “sure, Agile is ok for small projects that could, anyway be managed with any process, but they just don’t work for any project that has more than 7+-2 people!”
- And this message was so often repeated that we ended up believing it and applying Agile to small projects only. The projects that couldn’t fail we were told.Now, 6 years on to my personal journey as an Agilist I know better. Agile can scale to teams larger than 7+-2 people.
- Heck, agile can scale to teams larger than 7000+-2000 people (or more).
- But you did not come here to hear this. You knew I was going to say this when you read the title of this talk. You came here to hear about “how”. How does Agile scale to such large groups? How does Agile scale to develop software systems that have several 10’s of millions of lines of code?
- Before we can dive into this we need to understand that scaling means.While researching this presentation it was really hard to find a definition for “scaling” in the context of Software Projects
- Some literature refers to Large Scale Scrum (Larman, Bas), but does not particularly define how Scrum scales, just illustrates practices you can use
- others use the term “Scale Scrum” (Schwaber) without explaining what “scale” means (as a verb)
- and others even the term “Multi-team projects” (Cohn), but this is a bad definition because I’ve literally never seen a product project with just one team, there’s always sales, marketing, it, localization, documentation on top of the development staff, which in most cases is also in multiple teams.
- Others, again prefer to talk about “distributed” development. This talks about one of the properties of large scale but does not help us define what “scaling agile mean” (except that it must work in a distributed environment…)
- So, to start us off today I’ll present what I mean by “scaling”. Something that can helps us have a proper conversation to try and answer the question: “Does Agile SW Development scale?”.None of the information in those books really helped answer the question: “what does it mean to scale Agile SW development”?Well, we know it is about larger groups of people interacting to produce what we expect to be a “product” or “service” based on software, or even custom-software. I’ll focus on Product focused software development because that’s the area that I’m most interested in. Some of this will also apply to other type of projects, but I won’t focus too much on that.
- Let’s start with the easy question. What does scaling mean? I’ll assume that scaling is a property of a development process. As in “this process scales to a large group of people” or as in “this process can work for many teams working together on a project”.But that’s not enough. That property must give us some advantage over other methods that do not exhibit that property. Here is where the definition gets interesting. Here’s my proposal.
- I propose that a Software Development method scales if and only if (necessary condition): The work it takes to manage a project increases slower than the work that is being managed.
- Here’s a visual representation:
- Now that we got the definition clear we are equipped to devise a way to test our definition. One easy way to do that is to count how many “things” we need to keep track of to be able to manage our hypothetical software development project.I’ll propose that the property of scalability needs to apply to all “things” we need to manage in a project. This is not strictly true, but provides us with an easy way to evaluate if a method can or cannot scale. This is because, if the effort we need to manage some “things” increases at the same or higher rate than the number of “things”, that method does not scale for that “thing”, once we find a “thing” for which a method does not work we have confirmation that the method does not scale as previously defined.So, now we can devise an experiment to check if a certain method “scales”:
- Explain experiment (read)
- This is what we need to get in order to have scalability in the processLet’s look at how typically waterfall projects do Requirements Management.
- They will start with listing all of the requirements that need to be implemented (in a requirements document) and then they will ensure that each of those requirements gets implemented.
- Assuming that it takes x effort to manage 1 requirement, it follows that…
- it will take Nx to manage N requirements. This is because what we have is a flat list of requirements. But….
- What about dependencies?
- Read
- If on top of this we had that it will take us y effort to manage one dependency from one requirement to another, then we have the formula (note: this is an approximate model, reality can be a bit more difficult to define mathematically!)
- This gives us this effort graph
- What does this mean? The traditional and waterfall approach to manage requirements does not scale. But, then again, this should come as no surprise because if you have been doing software project for a while you already know that you don’t actually manage the dependencies very well.
- So, we have so far established that waterfall projects with their approach to managing individual requirements does not scale for at least this key practice in software development which is Requirements Management.But now we should prove that on the other hand Agile does scale. So let’s get back to requirements management.
- In our project we have a total of N requirementsBut in effect as a project manager for a large Agile project you don’t actually manage those requirements. In Agile we would call those User Stories. They are the most relevant at the team level because they express details of the system that require deep technical or otherwise architectural knowledge. Project Managers don’t have that knowledge, so the User Stories are delegated to the individual teams who manage them together with the Product Owners. So, in Agile we establish a hierarchy of requirements. Not all requirements are created equal.
- The model I am using currently is based on Dean Leffingwell’s Agile and Lean Requirements model which you can find here: http://www.sep.com/lk2009/dean-leffingwell-a-lean-and-scalable-requirements-information-model-for-agile-enterprises/What this model says is this: In any large scale software effort you will have many people involved, not all interested in the same level of detail, and not all details serve the different purposes that they need to serve: Portfolio management, Customer understanding, Progress follow-up, etc.
- So, this model effectively defines 3 levels of requirements: Epics – What are Epics, and why are they there?Features – what are Features and why are they there?Stories – What are Stories and why are they there?
- Each of these levels is an abstraction from the previous. So Epics are an abstraction from Features and they cover the Portfolio level. What value do we want to deliver to our users. It is feasible to follow progress at the Epic level, but that is not appropriate for Product Owners, who will mostly focus on Features, and teams will focus on Stories.
- These levels of abstraction allow the organization entities to focus on managing only the appropriate set of requirements that they need to get their job done.
- Typically there a few orders of magnitude in number of items between the different levels, so one Epic may have 10-100 Features and each Feature may have 10-100 Stories.
- Therefore Project Managers can concentrate on a feasible amount of things to manage. At the right level with the right level of information.
- So, going back to the formula this gives us the following:If you are project manager for a large project you will be following up and managing the Epics for the overall project, which leads to an effort like this (N = Stories) Nx/102
- Note how the effort we spend (vertical axis) grows at a much slower pace than the number of Stories that need to be managed (horizontal axis).Why is this possible?
- We have Product Owners and Team Representatives who will manage a subset of features and will come together on a regular basis to agree on how to handle the dependencies between those. Once that is clear they go back to the team and do the detailed planning, where Stories are created. Stories are mostly managed by ScrumMasters+Teams in their daily work.What is happening here is that decisions and detailed work management are being delegated to the teams. And this is the key property of this system that enables us to run extremely large projects (Someone said the largest projects he had ever seen anywhere) with minimal amount of effort. Don’t get me wrong, this is still a huge amount of effort, but it is infinitely lower than if we would be using waterfall.
- The funny thing in this is that, when we look around, we are not using anything that has not been done before. Take the London Olympics for example: huge project. How do they manage it? They have teams for the different interest areas, each area is clearly defined and has limited dependencies to other areas (venues, transportation, accommodation, marketing, etc.) and they have some common meeting where they tackle those dependencies. It would be lunacy to ask the London Olympics project manager to manage the construction of the new Stadium, the construction of new metro/train lines, the Olympic village and still run-around the world promoting the games. It is lunacy, but that is what many projects have today. A centralized project management team that oversees the implementation of all of the requirements, in effect they “control” the project, not “manage”, but “control”. There is a clear and expensive difference.
- So, to finalize this presentation I’d like to re-visit some of the practices that help us cope with the scale of our projects and may be helpful to you when dealing with the same issue.First, let me start by telling you that “size does matter”. We cannot use the same techniques for all sizes of projects. You should be careful at selecting techniques that fit your needs. Don’t create solutions to problems you don’t have!In large scale projects one of the most important things to realize is that the project management team cannot be the decision maker for all decisions in the project. The requirements model that we saw already points to this issue in the specific area of requirements management, but this principle or pattern applies to many other areas. Always enable decisions to be made at the lowest possible level in the organization.
- There’s this example of that MalcomGladwell presents in his book: “Blink, the power of thinking without thinking”. In this example he tells us the story of a war games exercise done by the american military. They were preparing for a war in the middle east (which I guess is no state secret anymore). For that exercise they had equipped the “good” guys (or Blue team) with all of the latest technology, snooping, battle field satelite recognition, instant and continuous GPS positioning of their own troops. The blue team had complete access to everything through their technology superiority. On the other hand, they chose a veteran from the Vietnam war to be the enemy leader. Paul Van Riper was a person that did not believe in technology, he believed that you cannot really “know” what is going on by collecting huge ammounts of information. Van Riper was convinced that war is too complex, to non-linear to be neatly managed from a bunker with lots of tech gizmos.
- Once the war games started Van Riper’s Red Team did exactly the opposite of what the Blue Team expected. He had ordered his soldiers to keep radio silence at all times, so that their communications could not be heard by the Blue Team. Each platoon of the Red Team was given a set of targets that they would need to define how to achieve based on their own assessment of the terrain, and the position of other teams in the field of combat.The result was a massive surprise to the Blue Team. They were lost. There was no radio communication to listen in, there was almost no activity as far as they could tell, and suddenly the Red Team sprang into action.
- Once they had reached their positions they lauched a massive attack on the Blue Team positions, missiles, suicide attacks, etc. The Blue Team could no longer respond, and the game was stopped. What can we learn from this story? Simple, give everybody clear targets, announce the synchronization points and let the specialists do what they do better, make decisions when they need them, instead of waiting for orders from some centralized command center we used to call project management.
- There are other techniques you can use. I’ll mention only one more: Visual ManagementOne of the most effective techniques we use to manage our large projects is a common planning session where we effectively show to each other what we are planning to do based on a set of objectives set at the highest project level. In this session we will spend most of our time communicating and solving possible synchronization or coordination problems between the different teams involved.In this session we have representatives for all groups in the organization (not each team), and to prepare for this session, the group leaders will have meetings with the teams to review and plan how to achieve the objectives for the next period/iteration. The key aspect in this session is that it is held face-to-face, as that is the only effective way to handle a large number of issues in a short time-frame.
- 3496880431_e7c5910859_b: http://www.flickr.com/photos/8867029@N07/611780383_bad69da781_o: http://www.flickr.com/photos/_at/2622099393_8199976c15_b: http://www.flickr.com/photos/quenerapu/1296530240_d56d4f69e4: http://www.flickr.com/photos/privatenobby/1183485780_61c9fb3ba5_o: http://www.flickr.com/photos/fotopakismo/2435823037_982e775726_o: http://www.flickr.com/photos/hinkelstone/2223726960_cc91af1726_b: http://www.flickr.com/photos/swamibu/2189435836_2d8d21e9db_b: http://www.flickr.com/photos/cdevers/2534246751_8e01e3d415_b: http://www.flickr.com/photos/jamesbooth/2714816217_30af6ba139_b: http://www.flickr.com/photos/dungodung/3260650860_fb557535dd_o: http://www.flickr.com/photos/puppydogbites/3726484920_67c38c5725_b: http://www.flickr.com/photos/talios/