There is a bit of a myth that Agile doesn’t do “process”. I think this myth stems from the first line of the agile manifesto:
Individuals and interactions over processes and tools -Agile Manifesto
And despite the manifesto clearly stating “while there is value in the items on the right, we value the items on the left more” there is sometimes an incorrect sense of rejection of those things on the right. This was deliberately leveraged as a straw argument by early Agile critics who attempted to label Agile as “cowboy coding” .
In fact the exact opposite is true. Agile actively promotes the design and development of process in a game changing way.
“If you can’t describe what you are doing as a process, you don’t know what you’re doing.” - W Edwards Deming
Agile wasn’t a rejection of process but a rejection of the bureaucracy which “plagues our industry”with its “documentation driven, heavyweight software development processes”.
In Deming’s words the heavyweight processes couldn’t describe what projects were doing and were “pushing process for process’ sake versus trying to do the best for the “customer” and deliver something.”. “The failure of the standard “fixed” process mindset” was that it couldn’t describe the relationship between the work being done and the actual delivery of working software which was valuable to customers.
The agile fluency model embraces Deming’s words in the very first level by focusing on “making work visible” through investment in “work process design”. Essentially teams begin by describing their process for connecting their work to deliverable customer value.
One of the great innovations that Agile adopted to achieve this is the “story wall”. The story wall makes the work visible. It also makes the process visible. Cards move from left to right, through the activities of the software delivery process. Each activity has a definition of complete (accurate and correct) before it can move to the next stage. The overall goal of the team is to keep cards moving.
The genius of the story wall is that it solves the primary challenges of knowledge work: you can’t see it. Unlike factories or construction sites, there isn’t anything physical to monitor as it mutates from raw materials to finished goods the customer is willing to pay for. The result is much knowledge work lacks process and falls into Deming’s trap. The story wall fixes this by bringing the illusion of movement and transformation to knowledge work. As cards physically move across the wall they are transformed by each activity until finally they are finished goods deployed to the end customers. Just like a car going down a production line, when cards get stuck on one activity for too long, teams can see and respond. When cards move backwards due to ‘defects’ it creates the same psychological response of physically moving a car back up the production line to fix it. Stories batch up, features don’t get deployed, things already ‘finished’ have to be reworked. For the first time teams are able to observe and measure waste and see and feel its implications.
And it’s not just lo-fidelity models like story walls. We have also embraced and promoted repeatable, reliable and robust delivery processes which significantly outperform their heavier weight command and control counterparts. Continuous Integration, Delivery and Deployment emphasise automation and appropriate standardization in order to reduce variability and dramatically increase team performance. Just like a story wall, the build pipeline takes materials and through stages in the pipeline, transforms them into finished goods delivered to the end customer. And like the story wall, builds make it visible when a stage fails, or takes too long, or batches up. Continuous Delivery is the automated description of what you are doing.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” -Agile Manifesto
Making the process visible is a significant step. The next thing is that the people who do the work have to be in control of improving that process. If “95% of variation in the performance of a system (organization) is caused by the system itself” [Deming] then teams need the power to tune and adjust the system based on the knowledge they acquire. As the agile fluency model states “managers must shift from managing the contributions of individuals to managing the work system—guiding team processes, work habits, skills, and context such that the team makes correct decisions without explicit management involvement.”. This is why agile teams have retrospectives. This is why we should measure our delivery and Four Key Metrics. By using these data sources, teams are able to reflect on the performance of their part of the system and agree to implement changes to improve it. Continuously. And without ‘management approval’.
Hopefully I’ve convinced you that the Agile way of working is actually all about a strong understanding of process. It’s just the process and its improvements are made transparent and visible and placed in control of the team for the team (individuals and interactions), not managers and bureaucracies.
Now, what about my claim that Agile is changing the game in this? Look at its rich history of challenging ineffective processes and actively displacing them with better ones. Whether that’s story cards over requirements documents, shifting left over change management boards, pairing over code reviews, trunk based development over long lived branches, build quality/security in over inspection, product over project teams, hypothesis driven development over big upfront change programmes. We’ve innovated ways to increase visibility and empower teams to improve their processes, from Continuous Delivery to methodologies like XP and Kanban.
So next time someone incorrectly assumes that Agile doesn’t do process, perhaps this will help convince them otherwise?