Tuesday, July 12, 2011

Command and Control vs. Agile

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))
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.