The future of agile
It was a great pleasure and honour to be asked by Steve Wake to start a blog on agile and how it affects and can enhance the APM community. At the same time, it is perhaps not surprising, as what is known as agile is 15 years old. Its strength is demonstrated in how it has survived its early criticism and is now becoming the norm rather than exception, with blue chip organisations now embracing it and even those working in very controlled industries.
So what has made it so successful? In future posts, I will explore specific aspects of agile, but, to whet the appetite, I would like to give you a brief history, current trends and how APM can and should be involved.
Agile has its roots in IT development. IT projects were being seen more and more as initiatives that delivered late and cost far more than originally planned. If that wasn’t enough, what was delivered often didn’t meet current business requirements – either being out of date or full of misunderstandings. This was happening in a fast moving, competitive business environment and with a world economy in recession. Traditional approaches (often called “waterfall”) implemented a process-driven, almost production line, structure on what is essentially a creative and innovative discipline. Too much was determined up-front without allowing the evolution needed to ensure the end result will meet requirements of today, necessarily embracing change as it happens. Too little was delivered along the way – keeping everyone waiting potentially for years before being able to benefit.
Hence a new approach was needed, and agile filled this gap. The Agile Manifesto was signed in 2001 and defined a set of principles. I would interpret the key aspects as:
- Agile puts the customer firmly in the centre. The driving factor is ensuring whatever is being developed will satisfy customer needs.
- As much as possible, an incremental approach is taken. Value is delivered to the customer early and often.
- Empowered, multi-functional teams ensure that delivered capabilities meet requirements. Although documentation is still important, it does not drive the outcome.
- The emphasis is on delivering those items that add real value and delivering them on time.
- A culture of openness, honesty and transparency is fostered, ensuring that potential issues are surfaced before they become critical.
- Constant feedback is vital to ensure that the final result really meets the needs of the organisation.
- Planning is vital, but plans will change.
Good agile approaches ensure this happens in a controlled way, incorporating just enough planning, governance and design.
These are aspects to which I will return in future blogs.
So what about the future of agile? Whilst the manifesto tended to focus on software development, the true concept of agile is far more. In fact, it is a philosophy that concentrates on empowered people and their interactions and early and constant delivery of value into an enterprise. The best agile approaches are very disciplined and can and should be integrated into corporate procedures such as governance. This enterprise level agile is becoming more and more popular, with even relatively conservative business areas, such as the finance and public sectors adopting it.
It is perhaps not surprising, then, that we are seeing agile starting to permeate all aspects of an organisation, and not just projects and programmes within IT. For instance, small, empowered, cross functional teams are effective in delivering real benefits early and often. This idea can be used throughout an organisation – involving those that will use products and services in their design and implementation but keeping teams small and removing unneeded bureaucracy. When customers are included, the right outcome of the right quality is virtually guaranteed.
So agile has a lot to offer the wider enterprise, and we could perhaps see a time when the whole of an organisation is run on agile principles. Since this will not be about projects or programmes, I believe the emphasis will be on behaviours and structures as opposed to processes and tools. The Agile Enterprise will have adopted a culture that empowers its employees and welcomes feedback and change. It will not be siloed into departments or other business areas but will support the flexible creation of cross functional teams that can quickly develop and implement new products and services.
APM has a vital role to play in this future. The project and programme management community needs to understand how to work within an agile environment, and APM is well placed to provide advice and guidance. It is therefore exciting that DSDM and APM will be working together to produce this. Steered through the APM Planning, Monitoring and Control SIG, the first meeting happens later this month.
I hope you have benefited from this introductory post. In future blogs, I will be giving progress on this joint initiative, and also deep diving into some key areas such as agile governance, leadership and agile throughout the organisation.
Steve is the current Chairman of Agile Business Consortium.
5 comments
Log in to post a comment, or create an account if you don't have one already.
My sense of organisational agility is that is needs to be aligned with the organisational strategy and leadership commitment (a self evident fact I'm sure); however, there are many agile methods (e.g. Kanban, ScrumBan, and Scrum) and even within one method (e.g. Scrum) there are many 'competing' methods for scale (e.g. SAFe). One of the strengths of the APM is our professionalism and I hope any review takes into account and weighs-up/evaluates the evidence-base? My current maxim for agility is "You dont need to be anti-agile for it to fail, you just need to be ambivalent". This reminds me that withour senior leadership determination agile cannot flourish simply as a 'bottom-up' participative change. Governance models (e.g. light: tight) are intimately linked to leadership and culture too it seems to me and my experiences.
Unfortunately this is another ill informed rant on the 'magic of agile' and how it will cure project management ills. I totally agree with Steve that agile is a very useful technique for soft project development and for regular maintenance work. The Agile manifesto also sets out a range of 'good practices'.However, good management and good project management and good project controls have always focused on meeting the needs of the customer, focused on empowering workers (this goes back to Gantt in 1919) and focused on delivering value. Bad management ignores the customer, ignores the people and ignores long term value creation. You can find examples of bad management in 'agile' projects as easily as you can in any other type of project. The vast majority of the Agile Manifesto has roots going back to the 1950s - Drucker and Deming are the primary source of most of the 'people' aspects, iterative development and reusable code modules go back to the 1970s at least. There were many examples of bad management labelled 'waterfall' software development where arrogant IT people though they new best and used major projects to grab power destroying $billions in value. There are nearly as many examples of bad management labelled 'agile' software development where arrogant IT people think they know best and use projects to grab power and ignore critical value retention elements such as delivering maintainable code with sufficient documentation for future maintenance. Agile anarchists hacking code to deliver something that works are every bit as damaging to value as the worst of the 'waterfall' disasters. Its time to separate arguments about bad management from discussions about development methodologies - bad management can abuse any methodology and destroy value,My thoughts on the value of agile (with good management) are at: http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf
A cogent piece by Steve.As he and I have often discussed, organisations must be wary of confusing delivery method and management method. E.g. 1] Scrum is Agile but Agile isn't (just) Scrum2] Waterfall delivery and hybrids of waterfall and time-boxed delivery, can be MANAGED in an Agile way3] Agile project (and programme and portfolio) management is not just for IT. I've seen Agile PM practiced in HR, energy, aviation and even nuclear engineering. APM's big differentiator is its focus on professionalism. A key component of which is adaptability. And Agile is nothing if not about adaptability.I am looking forward to the DSDM Consortium/APM collaboration; and its integration with the work of the authors of the forthcoming APM Guides: Directing Agile Change (about Governance) and Agile Assurance.The persistant, quiet...and not so quiet advocacy of Agile by both individuals and corporate members of APM seems to have found a slightly open door. Push it open please folks!
Steve/AdrianI am currently in the middle of researching Agile as an approach for experienced PMs - whether they be Agile or Tradiional, or both! In my research I have found the 10th 'State of Agile' report for 2015. If you haven't seen it then I recommend a look but the key things that stood out for me are:- 75% of organisations said that they used Scrum or a Scrum hybrid as their main 'methodology' (methodology - that's a whole different conversation!) and only 1% use DSDM/Atern. This will surprise Steve and it surprised me too.- the main reasons that Agile projects fail is because the organisation is not properly prepared to use/embrace Agile, or, there aren't enough skills/experience in Agile available. And that doesn't surprise me in the least. Many large organisations have governance structures that are based on Traditional development life-cycles and so don't really allow Agile to easily fit in and many business stakeholders are sceptical. And judging by the daily rates being offered for Scrum Masters, there's nothing like enough of them!So, Agile is great, but, if it's not wanted or it doesn't fit in - from an organisational point of view - then it's going to make life very hard for the PMs.
Agile Project Management Methodology has emerged as a great alternative to traditional project management methodology, like Waterfall. Agile is predominant in IT and software projects since it allows to adapt to rapidly changing business environments. Unlike traditional project management, Agile calls for producing and delivering work in short bursts, also called sprints. Gathering all the requirements before the development team even starts writing the code puts your software at a great risk of being not in line with current market demands and become a failure. When you decide what your product should be in the very beginning, you tend to ignore important iterations that must be made during the development lifecycle, thereby preventing your final product from being the right fit for the market. A plethora of project management methodologies are available in tech market, however, for the success and timely completion of a project, it’s imperative to choose the one that fits your business requirements and empowers the product development to keep the pace with changing client demands. Key characteristics of Agile Project Management Empowers developers to self-organize the task Enhances learning, knowledge sharing and communications among team members Emergent behavior to deal with uncertainty No detailed documentation and calls for just enough planning Continuous product refinement via regular iterations Constant feedback, research and creativity Faster completion of projects without compromising on the quality of desired product Maximum ROI