A side note on Agile

Scaled Agile (SAFe) talks a lot about Lean-Agile teams. It seems to have in mind a 'Scrum' type of agile. This makes sense given Dean Leffingwell and other influential Scrum thinkers are also behind SAFe.

The original Agile Manifesto reads:

We are uncovering better ways of developing software by doing it and helping others do it.

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.

There is quite a bit to unpick there:

• Individuals and interactions over process and tools. The process is a means to an end. Tools, processes, and rituals are there to assist communication, they don't replace it. If they aren't working go back to basics. Make sure individuals are talking to each other and change the process and tools to support that.

• Working software over comprehensive documentation. This says there is still documentation, but figure out what documentation is necessary and useful. Limit the effort spent creating it or keeping it up to date. Big upfront documentation and no software would be useless. Software with no documentation would be a nightmare to understand, support or use. This is about not spending effort on creating documents no one will read. Be cautious of tying the code to a fixed solution and set of requirements that are likely to change over time.

• Responding to change over following a plan. Plans adapt as new facts are learned. Don't measure success by conformity. It is a really bad idea to keep following a wrong plan. Being able to change and adapt is a competitive advantage.

The Agile Manifesto is supported by a number of agile principles

As a brief summary:

1. Satisfy the customer through the early and continuous delivery of high-quality software
2. Welcome changing requirements, even late in development - harness change for competitive advantage
3. Deliver working software frequently - every two weeks to every two months
4. Business people and agile people work together daily throughout the project
5. Build around motivated individuals. Give them the environment support and trust they need to get the job done.
6. The most efficient way to transfer information is face to face
7. Working software is the primary measure of success
8. Agile principles promote sustainable delivery (maintainable pace)
9. Continuous attention to technical excellence and good design
10. Simplicity maximize the amount of work not done
11. The best architecture requirements and designs result from self-organizing teams
12. At regular intervals, the team reflects on how to become more effective and adjusts accordingly

Reading about Agile it feels as though there are some common expectations of what an agile team is like

• The team have the skills they need to be able to deliver the work.
• The customer (or someone who has a good understanding of the customer needs) is a core part of the team.
• The team are self-managing and autonomous. They can divide up and prioritize their own work.
• The team can make decisions and change conditions to allow them to deliver more effectively.
• They don't rely on help (from other teams or parts of the organization) to deliver.
• The team track and communicate their own progress
• They solve problems together and continuously improve the process.
• The team can align their effort with the current management and business need.
• The team is small and co-located enough that face to face communication is an effective way to share knowledge. The team can meet as a small group near daily, and individuals work together on a 1:1 basis

This is my biased and very personal list. I found it helpful to try and understand the pain points that SAFe tries to address for larger teams and more complex projects.

• Making late modifications to complex systems is not always possible. SAFe suggests that changes to scope only happen at planning boundaries. These would be either at the end of an iteration (1-2 weeks) or a Program Increment (2-3 months).

• SAFe acknowledges that having the customer as part of the team isn't always possible. Instead, each team has a 'Business Owner' who represents the customer. The 'Business Owner' sets the value of the stories the team is working on. SAFe also describes regular system demos. These happen at the end of each iteration and at the end of each Program Increment. These demos help ensure that the team gets regular and consistent feedback to allow them to plan.

• Face to face communication becomes more difficult as the number of people increases. SAFe describes a team of teams approach for managing this.

• On big projects there is a tension between architectural autonomy for each team and the best architecture for the whole project. SAFe describes an Agile Release Train (ART). This is a long-lived team of teams that focus on delivering the solution. The ART sets the common technological direction.

This feels like a lot of preamble, that touches on what SAFe sets out to do but without yet describing it. This is going to take more posts than I realized!