So Agile is dead?
I started to write this post a couple months ago. For some reason I never finished it and as I went back I realized my perspective had even changed in that relatively short amount of time. Much of the context comes from trying to work the flow of the engineering team during what was probably our production peak. Below is the original posting followed by a bit of new learning:
The rally cry has gone up, “Long live agility”, whatever that means. One of these links is happy to explain it.
https://pragdave.me/blog/2014/03/04/time-to-kill-agile/
https://www.linkedin.com/pulse/agile-dead-matthew-kern
https://gradle.org/blog/agile-is-dead/
At Movement we also murdered the sprint. Its cold twitching dismembered appendages litter our office now.
A few months ago one of our leaders brought up the idea of flow from the book The Goal. A great demonstrational video shows the idea in physical form. Sprints very much follow the first bottle. Lots of starting and stopping, many meetings at the beginning and the end. I always felt like I was just hitting my stride when things needed to be wrapped up, revisited and started again.
We’ve been trying to figure out the best path to get to the swirling vortex of productivity. Right now we are trying a Kanban style pull flow. Much like the manufacturing process Toyota pioneered. Work is pulled down the line, not pushed, when the next person in line is ready to take more.
In The Goal the idea of dependent events and statistical variation come up as key problems in why work can take longer than expected to complete. I don’t think it’s common to look at the work of software development in how it flows from one department to the next. If you deconstruct a project it starts out as a simple idea. That idea gets flushed out by your product team. They mix in user demands and feedback. They talk to design and architecture to find out what is possible and what is pleasurable. Then it’s prioritized and pulled through engineering, on to QA and hopefully delivery.
In every one of those steps, what if a key member is sick, on vacation, just having a rough day? What if at any point complexity comes up that wasn’t predicted? That creates a little bubble of time that can’t be made up. It pushes off the next phase of the process where another anomaly may crop up. These variations combined with the dependency of the flow can cause significant delays when all added together.
In the spring our product team went to Moab to talk about these ideas. At one point we simulated working on a project. We decided to practice on something already on our todo list, doing native app install links on our offer system. We worked this through the validation and definition steps. We would “pass” the project from one area to the next and back if needed. Everything was going along fantastically and then it came to engineering. Suddenly everything exploded. It was the most wonderfully horrific social experiment I’d ever participated in. One of the engineers says “shouldn’t we only show the right button on that particular device?” the project gets tossed back up the chain to the product manager to try to answer the question, soon people are yelling and things devolved to pure chaos. It was delicious to see in a matter of 30 minutes what usually happens over the course of days during a real project. We were able to deconstruct this and see how easy it was for something to spiral out of control and delay delivery.
The problem I am still trying to work out from that experiment is that it’s impossible for the product manager to document all the things the project isn’t. If you have a pedantic engineering department that isn’t devoted to delivery these things will continue to happen. Conversely it’s very important that each step along the way someone can say “stop, this isn’t ready for me” and return it back up the process for further clarification. I saw a quote on twitter the other day that I loved “Weeks of programming can save you hours of planning.”
Back to the present day. As things evolved from this point we began to see another problem. Even though we said we were a pull organization, it was just another variation on the ever present waterfall approach. We were considering a tweak to the system but were never able to implement it into practice due to the downsizing of the company within days of that discussion. The approach we were considering was bringing in the person that would most likely be responsible for implementation much earlier with the product team. This person could respond to data questions and help the product team come up with the possible solution scenarios and give general t-shirt sizing of those options. The quality team would also be pulled in quite early to help with definition and understand what it is they would be asked to test. From there they would pull in design and architecture as needed to answer questions that would come up. This sort of made a nucleic approach where engineering would reach out and pull on the resources it needed to do its job the best. I wish we would have had the time to test this out and see if it helped projects flow faster through to delivery, alas, I’ll be left wondering.
