”Agile/Lean is the best known way to create software”
Bent Jensen is director and consultant at the Danish Agile Consulting firm BestBrains, a company that is primarily helping software companies implement faster and more effective ways to do software, with a Lean and Agile foundation.
What do you see as the benefits of Agile/Lean?
Agile/Lean is in my view currently the best known way to create software. There may be more or less (to a certain level) rigidity and ceremony depending on the organization and the product they are creating. But the overall principle of building the software in increments, having early feedback and continuous integration will help any software project. The people aspects, as exemplified by a Scrum process, common workplace, and common code-ownership, are powerful practices that will also help any organization getting more done, keep focus and continuously improve. For us (se p. 21) using these techniques meant greater productivity and being less sensitive to variation, whether from within the group (someone being out sick, or leaving for a new job) or from outside our group (changes in dates and priorities). On top of that we managed to have a much better quality than any other group. We had around 10 % of the number of defects other departments had. The main sources for this were a very well-integrated testing team, a rigid standard for unit-test and our continuous strive for better results. Any serious problem was seen as an opportunity for reflection and improvement of our processes.
Are there any drawbacks to Agile/Lean?
It takes determination and serious work to get there. Agile without discipline is just sloppy and will get you nowhere. So unless you are dedicated to quality and serious about getting better results, you should not try to do it.
What aspects need to be watched closely to ensure successful implementation?
That a few basic rules are followed.That daily stand-up meetings are kept on track, and are short, energetic and productive. That problems are dealt with as they occur, and that visibility is high in terms of burndown charts and visible user stories. It is important to create visual signs of progress as well as of problems. For distributed teams this can be a problem. In my experience there is no real substitute for a colocated team, but several measures can be taken to make the problems of being distributed less of a problem. Jeff Sutherland has a great article on distributed Scrums that lays out a good model for dealing with a group of remote developers.
Do you have any preference for a particular method or a set of practices?
It depends a lot on the organization and their culture. Practices should be picked so they support what is good now and solves the most immediate problems. Having said that, I believe that XP core engineering practices, combined with a Scrum approach to project management is a very powerful, wellproven combination. Adding Lean techniques as root cause analysis and continuous improvement makes it better and better over time.
Are there methods that are easier to introduce (for organizations which want some quick wins)?
Yes. Start from within. Introduce short iterations, daily meetings and plan ahead in one iteration. Have plans visible on a whiteboard or for geographically separated teams in some kind of collaboration tool everything can see at the same time, mimicking the task whiteboard.
Do you have any other words of advice for organizations about introducing Agile/Lean?
Always be willing to change and adjust, but stick to the basic practices for a while. Scrum is a good framework and easy to start with. But don’t be fooled by the simplicity – there will be problems and they should be dealt with, in a way that preserves the basic structure of the method – at least in a 3–6 month period.
Bent Jensen’s recommendation for introducing Agile/Lean in an organization.
1. Make sure there is buy-in around the table.
Developers are generally very motivated by Agile, but even managers and QA need to see that an Agile/Lean process will help them in their work. Involve QA early and do not let them be the bad guys that keep software from shipping. Assist managers to realize that a true Agile team is more self-managing, thus freeing the manager to become more of a leader and a coach than a traditional command and control manager.
2. Pick a winnable project.
No method can save a death-march project. Also be aware that there is some overhead in the beginning.
3. Make sure that the needed infrastructure is in place.
At least some of it – or make sure it can be created early in the project. Most important is continuous integration servers, test frameworks etc.