Managing Large Lean Software Projects
This post based on my reading of Henrik Kniberg’s book Lean from the Trenches. I am not going to write a detailed review on the book but rather I provide my own interpretations.
Maturity in using the tool
Either Scrum, Kanban or XP we should avoid getting obsessed by any one. Instead use them according to the situation. They can be helpful in providing guidelines but they can be tweaked wisely to the environment. Our approach for managing development or project should be composite rather biased to specific method or technique.
For large projects, it is not unusual to have 50+ people. Structuring into feature teams is key while maintaining an overall understanding through project Kanban board. Each team by itself can implement Scrum. Though the team has all the needed skills, there should be forums for testers to meet together daily.
They should happen at Feature team level for every team and for the specific skills level. In addition they should happen at the overall project Kanban board with representatives covering whole scope of work. Most of the people should attend only one stand-up meeting but some of them will attend more than one.
End users’ involvement
End users are involved from the beginning. Requirement analysts form a team but they are not substitute of direct interaction of the team to end users. End users perform user acceptance test on periodic basis to provide fast feedback loops.
Process improvement comes from people through team-wise retrospectives and overall project reviews. The essence of Agile or Lean is to provide a set-up which allows the project team members to collaborate for problem solving and performance improvement through process changes. Use visualization to bring all team members on same page, improve communication through retrospectives and use simple metrics for objective understanding of our performance.
WIP should be set at the feature level encouraging new behavior. When people has nothing to do but they can’t accept new work because of reaching the WIP, they can help the busy stages to speed them up. This is the heart of Lean to encourage people to finish existing work before accepting new work.
If we decompose the epic in the Inbox to more or less equal size features, using T-shirt size, we might not need to estimate the story-points per feature. Backlog grooming is breaking epics to almost equal sized features.
The following events should happen at regular cadences:
- Retrospectives at team level and project level
- Prioritization to choose the top ten features as input to the development team
- Release for user acceptance testing
Each of the above can happen at different cycle. For System testing, it should happen continuously based on creating system test branch from the code trunk.
Definition of ready
Two key definitions are:
1. Definition of Ready for Development, means the feature is ready for prioritization meeting.
2. Definition of Ready for System Test. This is the criteria for checking into the code trunk.
It is important for the team to have shared vision with target date. Team members self-organize to figure improvements and changes which can help in realizing that goal. The goal should be assessed by requesting team members feedback.
We should set a finite limit to the bug tracking sheet. The sheet has only non mandatory bugs prioritized and form part of the input to the development team. We should set expectation with the user that we will not address all non mandatory bug. Any mandatory bug should be immediately communicated to the developer without tracking.
Fast and continuous releases
Apart from whether you deliver for government, regulatory agency, or Internet agile company, we must learn to release fast with quality.
CM is at the heart for allowing multiple Agile teams to work on same code. CM is required for:
- Proper deployment to the code trunk, for system testing.
- Team members deploy to their team branch.
- Trunk is used to create system test branch.
- Fixes for bugs discovered during acceptance test are merged into trunk and team branches.
- Daily merging of trunk to team branch and team branch to developers workstations.
Automating unit tests and regression tests is mandatory to implement Agile development. It is critical for Configuration Management because we check-in frequently with the need to execute regression every time. A key requirement is to figure how to build the automated test suites while we incrementally building the product.
No replacement to gut feeling, however, metrics provide objective understanding on process performance and therefore can support planning. Two simple metrics are Lead Time and Throughput. Metrics should be normalized at the feature level.
I enjoyed reading this book and I hope to be able to put its ideas into practice.