Pre-requisite(s): Agile Definition
In this section we will learn about the twelve principles behind Agile manifesto
Why review principles before manifesto?
Over the years I have had the opportunity to coach executives, PMs and teams. At each organization the agile transformation journey taught me a lot about what works and what doesn’t work. I have learned that diving deep into the agile principles behind the manifesto before reviewing the four value statements leads to fewer mis-steps in agile practice.
The Agile Manifesto has four statements that condense a lot of wisdom into few words. These statements can guide the culture change in the organization.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software¶
Agile methodolgy recommends breaking down large requirements into thin vertical slices and get it done. By delivering early the team can get feedback from the customer and make changes to better align with the needs of the customer. Sometimes the customer has just a general idea of what they need, by having access to the product increment it helps the customers understand their needs better or make changes if the market conditions have changed.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage¶
Agile teams take advantage of every opportunity to better align with customer needs. The incremental planning and just-in-time backlog building approach makes it easier to adapt to changing priorities.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale¶
Delivering software frequently and early is a skill Agile teams have to build. Shorter cycles provide more opportunities to deliver value and align with the customer goals. A shorter timeframe requires the team to become comfortable with breaking up work into slices that can be delivered within a cycle and have a build/release pipeline that supports faster delivery. The team should adjust the timeframe based on ability rather than because it looks better on paper.
Business people and developers must work together daily throughout the project¶
For organizations tranistioning to Agile, making business people available to the team daily is very challenging. There are organizations who do this right, however may organizations ignore this and teams are left struggling to get clarity on requirements or getting requirements on time. Sometimes it is seen as a waste of resources to allocate a dedicated business person or product owner for each team. Each team must have access to the customer or customer representative when the team needs them in order to be effective.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done¶
When you have a group of individuals that take ownership of work they do and have an Agile mindset, they will generate tremendous value. A team centric approach will keep the best team togther and provide them the support needed.
I have seen organizations move individuals in/out of teams casually. Every time a high performing team is dispersed, the company loses value. I have come across many instances of teams broken up just as they had stabilized and were working well together to deliver outstanding value. This is where leadership can have a big impact on outcomes by adopting a team centric approach.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation¶
When working on complex and challenging problems there is no better way to move faster than face to face communication. Email, chat, documents, wiki are slow and less effective communication channels that drag down team velocity.
Working software is the primary measure of progress¶
In traditional approach the progress is measured in phases, for example: requirements phase, design phase, development phase, integration testing phase and deployment phase. The customer sees no value until all phases are complete.
Agile teams deliver early and frequently. The progress is measured in terms of work that is done. The customer receives working software from early in the project and in increments that add more value.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely¶
Agile organizations value individuals and work to build a healthy work environment. There are many ways to promote sustainable development including
- Create a safe working environment
- Decision making should be done by those who have the best information
- Use agile metrics to learn, don’t use it for performance appraisal
- Simplify communication paths
- Change hiring practices to focus on growth mindset
- Appropriate rest & recharge cycles
- Investing in tools and training
- Rewards & recognition
Continuous attention to technical excellence and good design enhances agility¶
Most engineers i talk to agree 100% with this principle, however they also point out that they are often asked to take shortcuts and discouraged from pursuing technical excellence. Engineers want to invest time in creating a good design and doing the best possible work.
From several years of talking with engineers, PMs and leadership i have come to a conclusion that “technical excellence” has different meaning for each group. Moreover the ROI calculation is done differently by each group. A clear definition of what technical excellence means for the team / project should be in place and at regular intervals key participants should have conversations that may lead to concrete backlog items.
Simplicity–the art of maximizing the amount of work not done–is essential¶
This is my favorite principle. It has helped me get unstuck in many situations. This principle can be applied in a wide variety of situations and results in better outcomes when aligned with Agile values.
The best architectures, requirements, and designs emerge from self-organizing teams¶
Self-organizing is often undervalued by teams new to Agile. This is often because self-organizing requires change in culture. A healthy working environment where people feel safe to learn from mistakes, empowers teams to take ownership and results in delivering the grestest value.
Self-organizing teams choose how to best accomplish their work and take bold actions to make it happen.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly¶
A team that does not learn & adapt is not Agile. When a team reflects regularly on how to become more effective, a world of possibilities open up.
A few years ago, i was having a conversation with an executive and the topic of agile mindset came up. He wanted to know the one question to ask a team that will reveal if the team has an Agile mindset. My answer was “Ask the team about tasks in the current cycle based on inspect & adapt feedback”.