Agile, Scrum, and Project Management
Agile Estimating and Planning
Agile methods address many of the shortcomings and risks of the traditional software development approach. Agile is typically characterized as a framework rather than a detailed set of rules. Cross functional teams work on incremental releases during sprints (iterations). In contrast to waterfall methods which emphasize long planning and requirements cycles, Agile methods focus on fast cycle time and collaborative development of requirements. Rather than creating large documents and handing them off from one discipline to another (product management to design to engineering to QA), the entire Scrum team works together to rapidly release working software every several weeks. Mike Cohn, author of Agile Estimating and Planning, was a contributor to the Scrum method and one of the founders of the Scrum Alliance.
Agile and the Seven Deadly Sins of Project Management
[youtube=http://www.youtube.com/watch?v=ey3J5KSi1Fo&w=530&h=397]
Cohn gives a brief overview of the Agile method and then describes the seven deadly sins of project management (and how Agile addresses each):
Gluttony
The desire to fix all dimensions of a project (scope, schedule, resources, and quality) which leads to impossible schedules and death marches. By timeboxing iterations and calculating velocity, Agile increases predictability. Since Agile iterations are fixed, the schedule is fixed and the focus is always on “what can we accomplish next?”
Lust
An intense or unrestrained craving for features, all of which are critical. This results in lots of overtime and surprises. By developing features in priority order (forced stack ranking) Agile offers incremental gratification in two to four week increments. The team asks: “what is most important to do next?”
Sloth
Failing to do high quality work at all times by testing quality at the end of the project. Sloth is characterized by instability during development, big delays, and unpredictable schedules. Agile/XP practices related to quality include: simple design, automated testing, test-driven development, continuous integration, pair programming, and refactoring.
Opaqueness
Obscuring the progress, quality, or other attribute of a project which obviously leads to not knowing the true state of a project. Using the waterfall method, you have no idea if three months or three weeks is the right amount of time to schedule for testing. Agile addresses quality opaqueness by not letting bugs accumulate, using continuous integration, and avoiding the “90% done” syndrome by classifying features as either done or not done. Schedule opaqueness is handled via iterations that are timeboxed so teams get used to meeting deadlines. Because work is either done or not done, the release burndown chart shows real progress. Finally, scope opaqueness can be remedied by using actual velocity numbers to calculate best case, worst case, and average case velocity and predict how much work can be done in a give number of iterations.
Pride
Believing we know everything needed to build the product. The causes of this are lack of stakeholder and user involvement which leads to failure to solicit feedback and failure to learn. Agile retrospectives, daily standup meetings, and engaging users with user stories are antidotes to this problem. Progressive refinement of user stories enables separating large stories into smaller, more specific ones.
Wastefulness
Misuse of critical resources. This issue is experienced as loss of creativity, motivation, and time. It leads to delays and mailaise. Agile has several techniques to combat waste on projects: timeboxing iterations, daily standup meetings, iteration retrospectives, self-organizing teams, and spreading intensity out evenly.
Myopia
Not seeing beyond your own work. The symptoms here are teams which don’t see the big picture and individuals who work only within their roles. This leads to unsuccessful products and delays. With Agile, planning is done at different levels (a release plan consisting of sprints) with cross-functional teams in order to provide context for everyone.
Agile Teams: Scope and Scale
[youtube=http://www.youtube.com/watch?v=FkWglejhJZM&w=530&h=397]
In this video, Cohn discusses scaling Agile up to large teams–he starts with a 700 person team example. Cohn begins by saying that many Agile books can be read as describing “a lone team on a desert island”; however, Agile can scale up very well.
He says that in a large Agile project, there is no “one guy in charge”, rather, there is a Chief Product Owber who has a vision of where the product needs to go. Reporting to the Chief Product Owner are LIne Product Owners. For example, the Chief Product Owner could be responsible for Microsoft Office and the Line Product Owners are responsible for Excel, Word, and Power Point. The individual teams can coordinate work on their own and need three things: money, moral support, and guidance (from a Product Owner).
In addition to vertical Agile teams, he recommends horizontal teams; for example, server side developers and client side developers. The horizontal teams correspond to functional areas such as software engineering and are led by a role like VP of Development.
He concludes the interview by describing the Agile estimating and planning methodology–estimate softwrae in the way estimate in the real world. First, estimate the size and then derive the duration. Agile uses story points as relatively valid units to estimate size; velocity is then calculated at the end of each iteration as the number of points completed.
More on Agile planning
Planning a Full Year Roadmap When Working with Agile
