There are various processes and philosophies around to manage project, especially software projects, successfully. Managers can choose from a set of traditional approaches, such as Waterfall, or following some kind of agile methodology such as XP, Scrum or Kanban.
The past
Extreme Programming (aka XP) has been very popular around the year 2000. It’s focus lies on describing engineering practices for software engineers like pair programming or test driven development. As they are limited to the software engineering department and were technical details on internal processes there was a big ideological gap to management or the customer. Outsiders understood pair programming as waste and test driven development as a strange approach.
Now
Scrum was mainly introduced to prevent the disconnect between technical people and business owners or customers. Scum does therefore not focus on any technical details, but rather the process. It’s core is set around standardizing communication with the business owner, setting expectations right for all involved people and increasing motivation of developers.
Following the Scrum ideology does not prevent to use ideas from XP. It must rather be seen as an addition. Poeple often refer to this as Scrum-but. Meaning: “I’m doing Scrum, but…”.
The future
XP and Scrum are a great combination to prevent common shortcomings of more traditional project management approaches. However, Scrum has a very fixed process definition, but does not include optimization of the process itself, as the process is taken as a fixed constant.
This is where Kanban comes into place. Kanban is not new, it’s idea is well established in manufacturing processes for years already and part of the Lean Thinking philosophy.
Kanban is about visualization. And it’s about changing the process. Visualization is taken as core instrument to see the current process and it’s bottlenecks. Those bottlenecks (and therefore problems of the process) trigger a constant refinement and improvement of the process itself.
In software development a good way to start with Kanban is visualizing the current work in progress. The team shares one common board, which is split into parts. Each part refers to a status (e.g. awaiting requirements, development, test, rollout) and each status has a limit of work items assigned at any given time. Each work item gets a sticky note, which is placed on the board at it’s current status. If one stage gets too many work items, the team must work in order to resolve the conflict.
Initial thoughts might be, that this process prevents developers to work on many items at the same time and brings down productivity. But it’s not about productivity, it’s about delivery and creating value for the customer. Creating value is usually achieved in constant delivery and a short throughput time. Which itself is achieved by bringing down the total amount of work in progress.
Agile software development
The general recommendation of being agile is… to be agile:
- Change your process whenever you think it can be improved.
- Visualize current status to reveal problems.
- Measure changes to see impact of improvements.
- Limit work in progress and focus on delivering value instead of increasing productivity.
- Use a mix of agile methods from XP, Scrum and Kanban and adapt them to match your and your teams needs.
References
The following links should give a good start into agile software development and lean philosophy: