Rawpixel - Fotolia
Will Evans, chief design officer at Praxis Flow, will be speaking at QCon in New York City about Agile teams and the benefits of a lean business model. SearchSoftwareQuality editor Valerie Silverthorne caught up with Evans to get a preview of his seminar.
When it comes to Agile, what is the problem we need to solve with lean thinking?
Will Evans: When I talk to managers within large organizations, many start with: "We don't have enough people resources," as if people were interchangeable cogs in a machine. When you're thinking about that, you need to find a way to flip that around. Maybe you are overburdened with too many things that are non-value added, and if you look at some of the data, it supports that belief. When 85% of the features in an application go unused by customers and 99% of apps downloaded from the iTunes Store are opened once and never opened again, it is not a lack of people. Too many of them are building crap that nobody cares about. That is the problem.
Starting from some of the problems we face, we need to look at how we fit into a larger value space when it comes to design, testing, QA and the larger ecosystems. That needs to hopefully be driven by a purpose and some value. We solve some problem for the customer because he gives you money and that is how our economy works. Understanding that can help people understand the inputs and outputs and where they fit.
In lean there are eight types of overburdening, including things like building to specs the customer never wanted or work that's unfinished or left in queues. Here's an interesting thing: [Agile thought leader] Hakan Forss studied thousands of different companies from the point customers asked [for an application] to the point they delivered the solution six months later. In the six months from ask to delivery, fully 95% of the time there was unfinished work sitting in a queue. If it's not worked on there is no value added. The principles of lean are about how to reduce that time and how to identify the constraints in the system that prevent delivery and value and how to manage those constraints.
How did DevOps come about?
Evans: It used be, 20 or 25 years ago, that we'd spend three to nine months writing massive specs and fire those docs across the wall to the engineers who'd build the spec to the best of their ability and eventually shoot it across to testing and then to the release engineers. By the time of release, the whole world had changed and new competitors had emerged.
Things had changed. There was a bottleneck in software development that was engineering. So 17 white men made a peace treaty between competing methods [the Agile manifesto] and after that, as more organizations developed an Agile mindset or methods, the engineers got better and better and created smaller increments of value faster.
This still created a problem -- the bottleneck moved from engineering, and this caused release engineers to think [developers] are totally [messing with] us here sending all this code to us with no time to prepare or get it ready to release to product management and operations. This caused the emergence of the DevOps community.
What do organizations need to understand about a lean business model?
Evans: There are three real principles that come back to fundamental lean ideas, one of which is optimize the whole system and not any particular part of it. It's lead time versus touch time. Most of the waste in the system is between team design and engineering, and engineering and test release and operations.
In a great system, you'd have more time to collaborate than waiting to receive the next instruction via email. The other two [lean] ways are to continuously look for opportunities for improvement -- by both learning and running experiments -- and getting better at delivering value.
Tactically, companies need to map their value streams and understand how to create opportunities to remove handoffs and queues from the system. The other thing to do is one of the really five lean principles, which is visualize your work. It is very difficult to manage and prioritize what you're doing, and that's where the Kanban way comes in to help manage the flow of work through the system and modulate how much work is happening. At any one point, you want to be focused on value creating activities and resource efficiency. If a person is spending 99% of her time doing something lean, say: "I don't care if she is spending 60% of her time if it's doing the right thing." That's more advantageous than starting a new task with no value for the system.
We need to learn how to decompose large chunks to smaller chunks, and how to visualize and prioritize. We need to manage people and organizations around value creation as opposed to just looking busy.
Taking the Agile pulse