Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Agile Control – two terms in conflict or in harmony? by Andrew Craddock DSDM Director and Founder of nlighten training On one hand, project and regulatory governance become (project increasingly control) important has in recent years. On the other hand, many Agile evangelists consider control to be an intrinsically anti-Agile concept. So is this a paradox or just a case of mistaken understanding of both terms? The problem with control is that if it is applied in a traditional command and control way, it is anti-Agile. In most project scenarios the mode of operation where a manager of a team tells individuals what they need to do, when they must do it and, in worst cases, even how to go about it, is now and probably always has been misguided. Equally misguided is the mode of operation where individuals and teams must adhere rigidly to pre-defined detailed process standards and practices where ‘they’, the people who define and police compliance, exert control over everybody – team member and manager alike. Quality Management practices over the last 30 years have been increasingly focussed on tighter and tighter control over process, with compliance being demonstrated primarily by bureaucratic means. This has led to thousands of man years of wasted time and effort attributable to: lThe generation of documentation that has little or no business value and sometimes is not even read by those approving its content 22 www.pmtoday.co.uk | APRIL 2015 lA mistaken premise that, for projects, the best ‘plan b’ is to try and do ‘plan a’ better – through better adherence to and, in best cases, constant tweaking of the approach. Fortunately all of the above misrepresent what control really is – or at least could be – in an Agile environment. Before looking at this in detail it is equally important to debunk some of the misrepresentation of Agile too. As a consultant and trainer in the Agile arena since the late 1990’s it has been my dubious privilege to hear words of wisdom such as “we don’t do documentation because we are Agile” and “we don’t make plans because we are Agile” and, even though I have never heard the words exactly, I have certainly witnessed behaviour that states “we do exactly what we like, when we like and how we like because we are Agile and if you aren’t happy with that then it’s because you are ignorant or stupid or both”. These statements badly misrepresent Agile and certainly appear to disregard the notion of any form of control. The truth here, is that the 17 thought leaders who authored the manifesto for Agile software development in 2001, and kick-started the whole Agile movement, all agreed that defined process, documentation, plans and contracts had value; it is just that other aspects of projects such as people, teams, collaboration, responding to change and, above all delivering real business value early and frequently should take precedence over these more formal aspects. (see www.agilemanifesto.org) Human beings maintain a dominant position on our planet as a result of two main advantages over most of the other species. The first is having hands with opposable thumbs – allowing us to create and make extensive use of sophisticated tools. The second is the sophistication of our brain – giving us the ability to solve problems based on experience and creativity and the ability to do this collaboratively by exploiting our preeminent skills in communication. Interestingly, these characteristics actually describe the essence of Agility – the ability to build solutions in a collaborative way using the knowledge, skills and resources and tools available to us. DSDM is the longest established whole project Agile approach. It has been tried, tested and proven over the last 20 years to reliably deliver projects on-time, on-budget and on-quality. To achieve this level of success requires both Agility and control. In recent versions of the method the emphasis on control has become more explicit whilst every care was been taken to maintain optimum Agility. In DSDM Atern (launched in 2007), the principles were redefined as: Once Evolutionary Development of the solution begins, governance in a DSDM environment is much more about roles and responsibilities than it is about process and documents. The project relies on properly qualified individuals to engage in the project and to collaborate to ensure that the right solution is built in the right way and is appropriately documented for support, maintenance and regulatory purposes. The use of Structured Timeboxes (or structured Sprints to use Scrum terminology) with pre-defined touch-points provides the individuals with such responsibilities (Business and Technical Advisors – to use DSDM titles) with an ever-timely forum to monitor and influence the evolution of the solution. lFocus on the business need lDeliver on time lCollaborate lNever compromise quality lBuild incrementally from firm foundations lDevelop iteratively lCommunicate continuously and clearly lDemonstrate control To make the first seven of the Principles a reality DSDM describes a framework of empowerment within which sensible, disciplined people demonstrate control over the work they do. Control stems from the self-discipline of every individual participating in a project and every individual with the authority to direct or have influence over it. In the DSDM Agile Project Framework – launched in summer 2014 – and the new DSDM-based Agile Project Management – launching this month – some of the products identified by DSDM (and only created where they add value to the project) have been identified as governance relevant. These products are often analogous to products in PRINCE2® such as the Project Mandate and the Project Initiation Document (the PID) but are intended to be much lighter than their distant cousin’s and always directly relevant and useful to the members of the project – not just the Project Manager and those responsible for ‘signing off on projects’. This is an example of the demonstrate control principle in action as it simply makes visible to the project governors (project boards, steering committees, programme managers etc.) the information that is relevant and valuable to the project and the organisation not just ‘stuff’ that is provided for generic and often obscure reasons related to comfort rather than real value. At the touch-points identified above, Advisors: 1. Understand at the Timebox Kick-Off meeting whether they need to be involved in the work of the timebox 2. Help the Solution Development Team understand the requirements related to e.g. supportability, maintainability, security, compliance 3.Review the teams plans for fulfilling those requirements 4. Review whether the requirements have been properly addressed and advise on any remedial action that may be required 5. Accept (or if necessary reject) that the solution meets the agreed requirements Capturing pertinent information at each touch-point in Timebox Review Records (another governance-relevant product) provides all that is needed as an audit trail for all but the worst-formed legislation. Be aware that in most cases, the legislation itself requires an impacted organisation to define how it will ensure and demonstrate compliance it doesn’t dictate how the organisation should do this. In summary, a DSDM-based approach provides a project with an Agile framework for the development and delivery of a solution in which disciplined professionals demonstrate control over the work they do. Agile Control – two concepts in complete harmony. For further information and the latest developments from DSDM Consortium, please visit www.dsdm.org www.pmtoday.co.uk | APRIL 2015 23