As more and more people turn to Agile frameworks over traditional project management methodologies to help enhance project capabilities and deliver outputs, it’s important to highlight that Agile is not a panacea for poor project management. At this point, let's distinguish between Agile (a delivery framework for iterative and incremental product and service delivery) versus agile (a mindset and organizational culture framework). While Agile is not a binary condition, there are some warning signs to tell you how well you're doing Agile. To address some of the misconceptions of Agile, this article takes a closer look at the Agile Manifesto, particularly each individual value that defines the Agile way of working. The Agile Manifesto begins by stating that:
through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
However, this should not be interpreted as being at the exclusion of the opposing value. Given that being agile is a matter of degree rather than a dichotomy, what's often misunderstood is that the relationship between each opposing Agile value is one of balance, dependent upon the maturity level of the delivery team and, to a greater extent, the supporting organization.
Having said that, let's now look at each value statement separately to gain a better understanding of the intention of the Agile Manifesto.
How do you tell if you're doing Agile right?
Individuals and interactions over processes and tools
In Agile, individuals and interactions do require processes and tools to get things done but the process and tools should be the minimum needed for a given situation. An agile environment is typically people-centric and participatory and can be readily adapted to new ideas and innovations. So, start with the people and then decide which processes and tools should be adopted rather than vice versa. Ideally the emphasis here should be on individuals and interactions with a focus on people, their energy and their ability to solve problems dynamically.
What this means is that an empowered, self-organizing team can achieve more than a team that is directed using a traditional hierarchical, command and control management style. In this context, self-organizing and empowered does not mean that an undisciplined and relaxed approach is adopted but rather the accountability to succeed and fail remains with the team, especially one that is cross-functional.
Working software over comprehensive documentation
No doubt the major strength of Agile is its focus on product delivery and much of the Agile practices and techniques ensure that the minimal viable product is fit for purpose. But there is still a need to document business justification to ensure what is being delivered is viable, desirable and achievable.
This common misconception, particularly by those inexperienced with Agile, leads to people choosing Agile in the belief that their project can be delivered quicker and more easily by avoiding documentation. But Agile is not an excuse for omitting documentation and if we look closely at the Agile Manifesto, it actually says “working software over comprehensive documentation”. That is, documentation is just as important in agile projects even though it is typically more focused and condensed.
This need for project documentation during the project lifecycle remains and is vital to show continued business justification. However, the level of documentation or, more importantly, the information, decisions and evidence needs to be appropriate to the particular project you are working on and the level of maturity of the delivery team.
Underpinning this important Agile value are the Agile behaviours and ubiquitous to all the Agile product delivery frameworks is transparency. The more information that is out in the open, i.e. information radiators and burn charts, the better this is for the agile way of working. It enables speed, clarity and engagement, even if the news is not so good. Essential to understanding this behaviour is to realize that there is more to transparency than just visibility and documentation. The most important elements of this principle come in the form of the common Agile values of honesty, trust, integrity and respect. This openness is an essential ingredient for an agile way of working that enables everyone to know the situation at any given time, potentially eliminating any surprises.
Customer collaboration over contract negotiations
Contracts are important and useful, and time spent negotiating them can be a good investment, however what gets in the way of effective collaboration is changing customer requirements; especially when more information becomes known about what functionality or feature is actually needed. In Agile, although trust plays an important part, the challenge with creating contracts is to ensure the contract supports collaborative ways of working by containing incentives rather than penalty clauses.
What's important to remember here is that any contract, new or existing, can define a framework to encourage collaborative practices and frequent feedback loops that support the customer's goal of agility and innovation.
When using Agile, the customer and vendor relationship is optimized when both parties are working together to co-design business requirements with a focus on outcomes rather than outputs or deliverables. The key to a successful partnering procurement approach is to provide the vendor with prioritized, high level business requirements rather than detailed business requirements used in a more traditional procurement approach.
If a commitment to partnership is achieved, then determine on the basis of joint consultation what both parties want from the partnership and decide on the common objectives and the performance criteria for measuring progress. So, to create a minimal viable contract, start with as few clauses as possible and then add clauses as needed to enable customer collaboration.
Responding to change over following a plan
For those new to Agile, planning is often misunderstood to be simply a "just do it" approach but if we look closely, there are actually five levels of planning in Agile. At the highest level, it begins with the product vision, product road map, release planning, iteration planning and, lastly but most importantly, the daily stand-up used by the delivery team to actually plan for the day.
No doubt planning is valuable in itself because plans help us recognize when things have changed; it helps us understand the implications of change, how we need to adjust and the likely cost. The important thing is that, as we make plans, we understand that the plan may have to change depending on the velocity of the delivery team.
In Agile, planning is an ongoing, time-boxed, empirical activity where plans are developed to the horizon. Like all other methodologies, the aim here is to do the right amount of planning at the right time. Release or iteration planning begins as a collaborative effort involving the iteration manager, who facilitates the meeting. A product owner, who clarifies the details of the product backlog items and their respective acceptance criteria, and the delivery team, who define the work and effort necessary to meet the release or iteration commitment. At the beginning of each iteration we agree on which features the delivery team think they can complete based on prior experience. These features are broken down into user stories, which are prioritized in the product backlog. By working incrementally and in iterations, the delivery team is able to deliver a working product to the customer and better able to respond to changes through frequent feedback loops.
When responding to change, it’s important to remember that collaboration and communication with your stakeholders is vital. The only way to properly communicate the progress of a project in the face of inevitable change is through transparency and honesty. By being transparent and educating your stakeholders in the ebbs and flows of a project, you will give them solid reason to trust your judgement. In turn, you progressively earn the freedom to continue on a leaner, increasingly more agile path.
In summation, the interesting thing about these value statements is there is usually something that almost everyone will instantly agree to, yet will rarely adhere to in practice. When adopting and applying the values of the Agile Manifesto, it’s pertinent to remember that probably the most important Agile principle is "Simplicity: the art of maximizing the amount of work not done”. There are huge benefits that can be gained from adopting an agile approach and, providing you understand the potential pitfalls, it can be a highly rewarding experience.
Read more AXELOS Blog Posts from Milvio DiBartolomeo
The fine art of tailoring to suit the project environment
Selecting a good senior responsible owner
What is good P3O® governance?
The value of gated assurance