The Two Principles (and Ten Practices) Behind the Agile Manifesto
Over the past couple of weeks, I have been working on a succinct definition of ‘agility’ – what it means for an organization to be ‘agile’. It seems apparent to me now that this has little to do with what Agile methodology you are using – whether it be Scrum, Kanban or anything (or indeed nothing). My current, best working definition of agile [tweetherder text=”#agile #agilepmo #lean Agility (small ‘a’) is the ‘serial delivery of value at the pace of demand'”]Agility (small ‘a’) is the ‘serial delivery of value at the pace of demand’[/tweetherder]. From this, we can see that the highest priority is to satisfy the customer through early and continuous delivery of valuable software.
I have also been doing a fair amount of thinking recently on teamwork, management, and what it means to be “self-organized”. This has been part of the research for my upcoming book “Succeeding with Agile Teams”. I originally thought that self-organization was simply a rebellion against authority. A declaration of independence by highly educated, motivated software engineers from the managers that have held tyranny over them for all these years. The more research I do though, it is becoming more apparent to me that self-organization is a functional necessity given the type of work being done. Software development is complex (in the Cynefin definition of the work). As such, it cannot be known (except by the workers – “only in doing the work do we know what the work is”, or to put it another way, the best architectures, requirements, and designs emerge from self-organizing teams.
Pulling these two higher level principles from the Agile Manifesto’s twelve Principles puts the other ten principles in a new light. The other ten principles can now be seen as being supported practices to the two higher level principles.
1. Serial Delivery
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Working software is the primary measure of progress. It should be delivered frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Simplicity–the art of maximizing the amount of work not done–is essential, as is the continuous attention to technical excellence and good design enhances agility, allowing us to harness changing requirements for the customer’s competitive advantage, even late in development.
2. Self-Organization
The best architectures, requirements, and designs emerge from self-organizing teams.
Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
As an Agile PMO looking to continually interpret Agile and agility within the context of the organization that I work, I find value in being able to extract these two higher principles from the other practices. This is not to say that there is no value in the other ten principles – far from it – just that they should be more open to interpretation and elaboration than the two primary principles of serial delivery and self-organization.
