Process and Product Delivery

It's a common complaint that process interferes with getting work done, and if you ask a developer, they're likely to equate process with meetings. A quick scan of articles about agile written by developers will reveal a whole host of complaints, but everyone will uniformly complain about process and meeting as the core reason agile fails.

This is really terrible because good process should enhance delivery. After all agile, and many of the processes around it like Kanban, are outgrowths from manufacturing innovation and the Toyota Production System in particular. The explicit goal of these manufacturing process improvements was to produce more, faster, with better quality.

In the late 80's these manufacturing concepts were consolidated into the five principles of Lean manufacturing:

1. Precisely specify value by specific product
2. Identify the value stream for each product
3. Make value flow without interruptions
4. Let customer pull value from the producer
5. Pursue perfection

Meetings are not listed here. And if you dig into the Agile Manifesto, that was about delivering software more efficiently with higher quality, and you won't find meetings there either. In both cases, Lean and Agile, the goal is to start building something and refine the product and process on an ongoing basis pursuing more efficiency and higher quality.

So, why all the meetings?

Meetings actually result from a lack of process. A process is defined and repeatable; it's an IRL algorithm. So, if you have a process, you don't need a meeting.

One of the first meetings that gets on everyone's nerves is stand up, which is often discussed as the foundation of Agile. Ask someone, "Are you Agile?" The response is almost always, "Yes, we have stand up meetings daily and sprint planning every two weeks."

Facepalm.

Stand up meetings exist because there's no process for developer feedback on their progress. Ask someone why do you have to have a stand up meeting every day, and they will likely respond with a question about developers getting blocked. They think that having a stand up meeting is the process to resolve developers getting blocked, but it isn't. The process is all the things that happen after the team is aware that the developer is blocked, which are not tied to the stand up meeting. A defined process would handle the developer's needs when they are blocked at the time they become blocked.

And the same goes for sprint planning. Why do teams have sprint planning meetings? Because there is no process for prioritizing, scoping, and assigning work. Again, if there were, you wouldn't need a sprint planning meeting. Maybe a periodic retrospective to continually improve the process, but not some stab-me-in-the-eye-with-a-pencil meeting where everyone reads through cards together event called sprint planning.

So, if you want to really be agile, push for process and dismiss with meetings.