I was asked recently “How do I summarise the Agile Values as defined in the manifesto?”
My feeling about this and why do we have these values is because software is about people, not things.
It is about We, not ME. For example
We are uncovering better ways of developing software by doing it and helping others do it.
Software is a team activity and as we learn more we should also be teaching more. One day you are a student and the next you are a mentor. Good software is about people working together.
Individuals and interactions over processes and tools
The Team and the network can deliver because they collaborate and behave like a team. While tools and processes can be useful, they can also lead to the belief that as long as I do what the tool/process asks, all is good. Collaboration can be lost. Good software is about people working together.
Working software over comprehensive documentation
But who reads such documentation. Working software is in the eyes of our customer. We Demo it and we release it to them. There is a conversation inspired by the demo, and this starts another conversation. Documentation may be needed to record these conversations. Good software is about people working together.
Customer collaboration over contract negotiation
This is clear, contracts are used between legal people and warring factions. If things are going well we care about value delivery, not para 4 subsection 3 line 12 or whatever. We need to collaborate and network. Good software is about people working together.
Responding to change over following a plan
How do we learn about change and how do we react to the change our stakeholders experience? Recall planning is valuable, but plans are out of date the moment they are written down. Good software is about people working together.
As teams develop ways of working together they improve, and team members also improve. Modern leadership focuses on developing people.
The person, the person, the person, everything depends on the quality of the person
From Doshin So, Founder of Shorinji Kempo
So the person is the key to teams and everything depends on the quality of the person. The Agile values also require people to contribute. And like the martial arts agile teams and people are always looking for ways to improve, never satisfied with today’s version of themself.
All of this is great and indeed even self evident. So what has gone wrong with Agile? If it is so completely wonderful why isn’t everyone not only using it but succeeding wildly with it? If it is about cross functional teams, have our teams become silos themselves? Is DevOps “Agile Sans Frontières”, and is this the natural evolution from where agile started from and has now moved to?
Recall lean and agile thinking is about the FULL value stream, not just the development or operational ones!
Is it true that there is nothing wrong with agile just with the way we implement it as partial rather than complete value streams?
The early Agile observations identified that the silos organisations were made of, were very functional. Reaching across these silos was a slow and imperfect process. The agile team broke down these silos and brought them all together in a single team in software engineering. For example we combined requirements, architecture, design, development and testing to provide operations with a release. So early agile left us with development, operations and support as the remaining silos, and DevOps as a principle addressed this.
Figure 1: The early silos as encountered by agile
The problem is that much of this is academic. The reality is often more of the ScrumFall approach. We have scrum teams that are fed stories from the business and hand “completed” stories to test. This would look like this in a silo view
Figure 2: Typical and Ideal team scope
We also know from experience that the silos can be different depending on the way agile is implemented in an organisation. Consider that many organisations have used ScrumFall keeping the agile initiative within a carefully bounded development silo with some test and design. This has not removed handovers and in some way is worse than the previous waterfall approach. People believe that the code is potentially shippable, because that is what agile says it is. However the code is not fully tested and is clearly not shippable in this case. NFR testing is rarely done in this situation. So good that we have a team that is working together, bad that they are tightly constrained.
Let’s move this forward and imagine that we have achieved a reasonable degree of agile success. We are operating in a more ideal manner. The team has things under their control. They can have discussions with the end user and can deliver their software to the operational environment and are responsible for running it.
All silos removed? All impedances to delivery of value in the hands of the team?
This agile team still lives in a corporate world. This is without any talk of scaling, we are still a single agile team. Now what. Consider the next diagram and the silos within. In fact, think of the areas of your company that I haven’t mentioned. HR, Admin, APMO or training for instance.
We can ask if the budgeting approach is being a hindrance with an annual cycle that can impose a six month delay for new ideas to be funded. Why isn’t the team funded and the accountability based on the delivery of value?
How do sales and the team keep synchronized.? Does sales sell things that are not on the backlog yet? Do we have to wait for a marketing campaign before we can release our latest creations? Silos have yet to disappear, but they have moved. As is often the case, when you remove a barrier, a different one appears.
Figure 3: The next set of silos
We know that at the team level silos stop progress and they slow down the progress we are working so hard to achieve. At the corporate level these structures exist because they are believed to deliver economies of scale. SAFe 5.0 discusses the need to establish a network which exists without boundaries, but then recognises the presence of the corporate structure. This is referred to as the Dual Operating System and is designed to maximise the delivery of value for the team and optimise the delivery of corporate administrative services.
We know that silos impose handoffs and cause batching to occur. While we wish to minimise batch sizes we would like to remove them completely and achieve a continuous flow. How to achieve this is an ongoing exploration. It may be that holographic or teal coloured organisations can help remove some of the more persistent silos, but only time will tell. In the meantime, keep learning.
Leave a Reply