The discussion started with someone asking for XP Myths and to test or not to test popped up and hijacked the thread. If you are really interested in the gory details of the thread, see http://tinyurl.com/yes8b2u for details. The discussion then stemmed into something like, "well, if it's OK to not test when you are exploring what people will pay for, it might be OK to not do XP". But what does "not do XP" mean?
That got me thinking about "Lean Thinking" by Womak and Jones because I've never looked at XP as a set of practices, well, I did early on but grew out of it. I look at XP and any Agile methodology as a system with certain core values and principles. I prefer to build my XP process based on the same principles expressed in "Lean Thinking:" value, value stream, flow, and perfection. If you want a more detailed list of principles on which to base your agile methodology, see "Lean Software Development" which has, if I recall correctly, 7.
Value
From a lean perspective, value is what you sell to make money. In software that means, well, software. It's why the customer pays you. The customer pays you because the software saves or makes her money. So the main principle is everything you do in your process must create value or it's muda or 'waste'. Whenever you decide to implement a practice ask yourself, "Will this practice help the team create value?" Alternately, whenever you decide to skip a practice, ask yourself, "How will skipping this practice affect the teams ability to create value?"Value Stream
The value stream is the entire production process. Often it is helpful to map your value stream to see how the value gets produced. In manufacturing it could start at the mine where the raw materials are extracted from the Earth and end where the shiny new product rolls off the assembly line.In software, your value stream could start with the customer asking for a new feature and flow all the way to delivery back to the customer. To map your value stream, write down every step the team takes while delivering that new feature. Once you have a complete value stream map, you can start looking for muda. Things you do that do not directly contribute to the creation of the desired feature - the value. Also look at all activities the team does that are not in the value stream map. Those activities are primary muda. Secondary muda are activities that contribute in a secondary way but do not directly produce value. An example of secondary muda is source control activities. Using a source control system is a vital component to software development. It keeps track of file changes, enables sharing of code, and allows branching for tracking software versions. All key to developing good software, but none add directly to the value. In other words, a customer will not pay you more money whether you use an SCM or not. In secondary muda cases, the goal is to minimize the time and effort spent on the activity. If the team spends 2 hours a day mucking about with SCM activities, find out why and reduce that time, so the team can spend more time on valuable activities.
Flow
The current buzzword of the agile industry. In manufacturing, flow is how well the value moves through the value stream. It addresses things like inventory and production backlog. For example, if a certain station on the assembly line always has a huge inventory of product stacked up in front of it, and the station down line is always waiting, then there is a flow issue. This is where the Toyota Production System concept of pull comes in to play. Traditional assembly lines thought the plant was most efficient when run at full capacity, but that often produces flow problems. Pull allows each station to pull product from the previous station, so each station can work at its full capacity. Less waste.The current Kanban movement in software development is based on the concepts of flow and pull. The swimlanes on a Kanban board often map to the value stream map with each swimlane able to pull from the previous swimlane. All of your activities should allow the value to flow through the value stream. Once you have your value stream map, you analyze how the value flows through the system and address bottlenecks.
Perfection
Perfection addresses how the Toyota Production System constantly strove to improve itself. Kaizen is the constant little improvements each team tries to do everyday thinking that small continuous improvements eventually add up to big gains in effectiveness.In software, retrospectives are often used to identify and address any issues that came up during the previous iteration or sprint. Encourage your team to constantly identify any issues with flow. As the team gets better and better, different problems pop up. Perhaps the team as become very proficient with the new technology and is producing faster than test can verify. Certainly a good problem to have, but a flow problem none the less. According to Theory of Constraints thinking, you move the constraining part ahead of the part that's overwhelming it. Moving test ahead of development, writing automated tests that are executed as the release criteria, now frees test from getting swamped and sets valuable limits on development.
Posts
