Command and Control vs. Agile

In her book, Coaching Agile Teams, Lyssa Adkins nicely maps out the transition in beliefs that traditional project managers have to go through when adopting agile.


Lyssa explains that the command and control project management beliefs on the left need to be replaced with the agile beliefs on the right:

Project management belief	Replaced with
We can plan the work and work the plans.	Planning is essential, plans are useless.
The triple constraints can be traded off for one another to correct for unknowns.	Time and budget are held constant. Only scope flexes.
The plan gets more accurate over time as we flush out the project through phases of activity: requirements, design, testing, and so on.	The plan gets more accurate over time because it is constantly reviewed and tuned up based on the teams actual performance.
Delivering on time, within budget and on scope equals success.	Clients getting the business value they need is the only value of success.
Scope can be locked down with later discoveries being handled as change requests against the schedule end date.	Scope remains flexible and changes of any kind are welcomed even late in the schedule.
Controlling through the project plan is my job.	Controlling through a plan is not possible; releasing the team into the safety of agile is my only measure of control. So I coach the team to use agile well.
Completing tasks and delivering deliverables indicate progress and value delivered.	Only delivered end products indicate progress and value delivered.

Agile PMP

At Agile 2009, Mike Cottmeyer presented Agile PMP. Mike starts out by defining traditional project management from a PMPs perspective as managing the 9 knowledge areas of the PMBOK. He defines agile as a combination of engineering best practices, a leadership framework, and project management techniques. The PMBOK and Agile are not exactly the same. But the skills of a PMP are still valuable in an Agile project.

In traditional project management, we are trying to remove uncertainty. We are trying to learn enough up front so we can plan. In Agile we do not to take uncertainty out of the equation. We want to embrace it and manage it.

Next Mike reviews the Agile Manifesto and discuss how we still value the stuff on the right, but we value the stuff on the left even more:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Then Mike describes how agile inverts the iron triangle and says cost and time are our primary constraints. We need to figure out how much are we willing to spend and how long are we willing to give it and then figure out what we can deliver within those constraints.



Mike describes time management as breaking the project into releases and breaking the releases into iterations. Iterations are fixed in duration and do not overlap. The milestones are defined 1st, and for each milestone we define how much scope we can fit in it.

In software cost management in generally based on the amount of people on the team. Cost is the amount you are paying people times the time you are giving them.

Scope management is done by rolling wave planning or progressive elaboration, Epics (high level needs and goals) are defined at the project planning level (18- 24 months), features are developed during release planning (3 – 6 months), and stories are detailed during iteration planning (2 -4 weeks). We let details emerge as we learn more and more about the software we are building. At the iteration level is when we make the hard commitment.

Introduction to Agile for Traditional Project Managers

At Agile 2007, Stacia Broderick mapped the PMBOK process groups and knowledge areas to agile practices. She started by defining agile as a value driven approach to building working software by collaborating with customers and embracing change. The characteristics of agile are:

1. Iterative, incremental

2. Risk mitigation via use of timeboxes

3. Continuous improvements

4. Team ownership of quality

5. Value based prioritization of requirements

6. Dedicated self managing teams

7. Collaborating with customer

8. Embracing change

9. Modern engineering practices

Next she went over the Agile manifesto and the principles of:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

She then mapped the PMBOK process groups of Initiate, Plan Execute, Control, and Close to the agile practices of Envision, Speculate, Explore, Adapt, and Close. She described how the traditional iron triangle of Scope, Time, Cost or Budget has a fixed scope from which a date and cost is derived where as in agile, the triangle is reversed with the date and cost fixed and the scoped varied or derived based on a prioritized product backlog.

Agile in the Waterfall Enterprise

At Agile 2007, Michelle Sliger discussed some hurdles that agile teams face in a waterfall enterprise and how to clear them:

1. Resistance: There will be resistance from management, the business and the team. Don’t try to sell agile to management. Instead fly under the radar, operate in stealth mode and just go ahead and product working software of high quality. When talking to management about agile, advocate using their language. Avoid using terms like agile, xp, scrum sprints and use terms they are already familiar with like ROI, cutting costs, increasing quality, earlier to market, or share success stories that prove increase in productivity. When dealing with resistance from the business, try to get them involved early on and suggest trying things for 30 days and then have a retrospective. Try to get a client or at least a proxy on site. It is easier to start out with XP technical practices. When facing resistance from the team, try to get the right people on board and empower them.

2. Culture: Review the companies mission statement and see if there are values mismatch between what is stated and what goes on a daily basis. Try to clear up misconceptions of Agile. It’s a new methodology but not a fad.

3. Resource management: What if the organization has a matrix environment. Agile teams are collocated and dedicated to the project. But agile can be distributed, but it won’t be as effective and efficient as collocation. Dedicated is different from devoted. Dedicated means team sticks to the project through completion. Use a release plan or quarterly plan to help resource manager in allocating people. Use release plan and product roadmap to assist project managers in the allocation of the budget.

4. Vendors and Contracting: If a vendor is not agile, evaluate the duration of the relationship. If it is short term, then there is no need to explain agile, but if it is longer, then you should explain it. If customer is not agile, then think about how to present the contract. Start a conversation with them. Would you like us to show you progress on application every 2 weeks? Would you like to change or adjust your requirements after reviewing the progress? Work through time and material contract with option to renew or cancel every 30 days.


5. Facilities and Tooling: Use what works for you. Ask the team and find a solution, create or find an open space, make it a war room, use a whiteboard. Use open source tools.

6. Cost accounting and reporting: How are we going to do the budgeting without a BUFD (Big upfront design document)? You have to do it, but you do it differently. Find out cost per iteration. Find out cost per story points. Find out what metrics need to be tracked. If GANTT chart is still needed then you can give it but duration will always be the same, task assignment will always be ‘TEAM’. Are you capitalizable or an expense?

7. Auditors: talk to auditor and find out what they are looking for. Add those to the product backlog and include them in an iteration to create these docs. Be barely sufficient in your documented proof.

8. Communication is key. Agile is a silver bullet but only if it is implemented properly.. Inspect and adapt and communicate. Have a communication plan in your transition rollout plan. Provide support for sharing knowledge and experience and continued education. Define escalation and issue resolution.

9. Miscellaneous:

• a. passing off code to production (add one iteration to make it production ready – get sign offs, get help desk up to speed, get training materials, get docs).
• b. Reward and recognition: Not about individual performance but about the team making its commitment. How do we do that? Ask the team. As agile team become more and more performing, they will level off. We need to keep them consistently challenged and motivated. Organizational change will happen. Instead of silos, there will be groups around product lines.

Next, Michelle lists 10 tips for an agile/waterfall cooperative:

1. Find an executive champion that will help you by pulling those hurdles out of the way.

2. Socialize, don’t evangelize

3. Use the power of the backlog It should include more than just coding items.

4. Do not wait until everything is figured out and perfect. Just get started. Later you can inspect and adapt

5. Use barley sufficient guideline. Do the simplest thing possible to satisfy a request

6. Invite non agile reps to all agile planning meeting

7. Establish a rhythm of inspection and adaption

8. Start sending the ideas up the chain. Help your managers become more agile

9. Pay attention to your behaviors and your team’s behavior. It is easy to revert back to the old ways especially under stress and pressure.

10. Include everybody in project retrospective. Improve things in the team and across the organization

Finally, Michelle concludes that Agile and waterfall can coexist. You need to build the bridge together. Invite everyone who is interested to help you with the transition to agile.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger