Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Contrast to Waterfall  Contrast to Waterfall   Welcoming Change   Welcoming Change

Empowerment versus control (often called command and control in management parlance) is another difference between the two approaches: agile and waterfall. We will go through this in a bit more detail in the section on Leadership. However, in a waterfall project an individual is meant to be capable to deliver the techniques of their role. When decisions fall outside their remit they escalate it, they await a management review, and they assess the response and act accordingly sometime later in the project. In an agile project an individual is assumed, and needs, to be empowered to make decisions for the business, for the user team or for the organisation but certainly for themselves.

Rapid working of any sort inherently depends upon the autonomous nature of a team. The team works very rapidly and makes changes rapidly. The team captures advice and decisions made by the business team members embedded within the project team. This opinion is captured immediately, developed into some form of assessment deliverable and prepared for assessment.

It is this fast. Then it is demonstrated to the business team members and validated by them immediately. This is a classic low latency environment where there is often no time to plan it and no real need to plan it. It is an inherent process that always takes place, instinctively. There is little time to communicate it and little point to communicate it.

We know that the business team members embedded on a project communicate their requirement immediately and succinctly to the people who will deliver it. Then it is developed, demonstrated and validated. The project team have all the information they need to know and if they need to know more they have access to extra business personnel.

These business personnel will validate a concept or idea swiftly, the project can prototype it and assess it collectively right away. This is why truly agile projects need autonomous teams with the governance, trust and empowerment to adapt, deliver and decide independently. This very important independence though is the architect of an apparent disorderly chaos often associated with agile projects. This freedom and self-governance portrays the suggestion of a random undisciplined team. This gives the vision of an apparently casual disorderly venture and is the image that those outside the project and those involved in project funding or overseeing related programmes receive: unless they are given an alternative image and message.

Communications across the organisation is yet another gap in the standard agile methods. They appear to make claims of transparency but disallow project communications (such as project status information) to specific people and role types outside the project. Put the "SCRUM" phrases, regularly cited as inappropriate, "CHICKENS" and "PIGS" into your preferred search engine for a little more explanation of the problem. A truly agile project is going to deliver to time and to budget. So, all team members should not be concerned about sharing information about time and budget. It should not however be interrupted with bureaucratic requests for this information either. This tradition comes from conventional bureaucratic management and leadership styles. This is adverse to the agile ethos.

The quality of the deliverables is under the direct control of the user team embedded within the project. Therefore, this specific issue of deliverable quality is of little or no real concern to organisational participants within or beyond the project. However, if demand for information from a funding partner or other important member outside the project is received, it should be accommodated. Such requests that are ignored or rejected are likely to meet with an unfavourable response. It is apparent that this lack of pragmatism and reality in the proper governance of agile projects has halted the expansion and deployment of agile methods.

You will see across the web the comment that agile is not scalable. When you read further, the problem is not the scalability of the approach more the readiness and capability of agile projects to share status and other information and communications when agile is introduced or casually embedded inside organisations. These are management issues of empowerment and control. Communications across the project need to be free, frank and unfettered. The manager and any project participant need to be able to share progress or other information about the project. This candour and candidness releases a Twitter-like free-for-all across the project. This is good and demonstrably open.

This opportunity presents a management challenge to allow what may seem at first sight to be an uncontrolled anarchy in communications where anyone can say anything. However, at the same time, as a manager you will undoubtedly seek to maintain a strict management of any malicious communications or messages that seek to damage your project. You would hunt out all negative, unfounded or damaging information on any type of project using any type of method. On an agile project the agile manager is always promoting the openness of information and the open opportunity for project personnel to openly contribute to that process. The openness of communications across agile projects is self fulfilling. The openness itself starts to uncover, and almost immediately provides the checks and balances for, any negative or inaccurate information. So the promotion of good speak across your project helps to minimize the amount of bad speak. Again the popular agile methods nonchalantly ignore this.

Naturally we deal with this. The Toolkit provides a project openness to overcome these management challenges and concerns but provides techniques to identify and expose any fifth columnists hidden inside your project. These are important changes that are necessary to running a truly agile project but they are not always welcomed. Let us look at that topic now too: welcoming change.


 Contrast to Waterfall     Contrast to Waterfall   Welcoming Change    Welcoming Change

Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z

#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Empowerment versus Control


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 11  Page: 12/444  Progress: 2.7%
 About    |    Author 
Follow @BigAgileToolkit

This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL ( and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.