We recently completed a small but interesting project at work. The team consisted of Tim Weeks, Lee Walton and I played a supporting role. We shared the lessons learned in an experience report at the Agile Practitioners group. The talk was filmed and can be seen below.
On this project, the developers tried a number of Agile and XP practices. BDD and Pair Programming were tried for the first time, in the video they explain what this was like.
In addition to the Agile aspects, the talk shows what Lean (kanban) principles we followed e.g. making decisions at the last responsible moment.
There is a large section on using code reviews and code metrics to help improve code quality.
I got off to a shaky start, but things seemed to improve as the video goes on.
Overview of the project
Developers discuss how they felt on the project
Discussion on pair programming for the first time
The importance of putting people first
NUMMI case study (GM and Toyota)
Start of project – beginning with the end in mind
Re-writing stories, to remove implementation details
Simplicity – the art of not doing work
Cost of defects
Making decisions at the last responsible moment
Burn down charts
Cumulative flow diagram
Walking skeleton or tracer bullet
Lean thinking – limiting work in process
Dealing with blocked stories
Code Reviews (brief discussion)
Relationship with PO – developers having access to users
Task switching – cost of task switching on projects
It is important to mingle with other members from our industry. This keeps us up to date and stops us getting too caught up in a closed off world. If you would like to have face to face discussions with other professionals you may wish to join us at one of the Agile Practitioners events. This London based group will be meeting at least once a month. We will be discussing a variety of topics. While we don’t plan to replace any of the existing Agile groups, we do intend to be intriguingly different.
Recently we started using avatars on our Kanban board. We are certainly not the first to do this, however I was surprised by how excited and rejuvenated the team became. If you have never tried this I recommend you suggest it to your team and see if they go for it.
Not only is it fun, but it is also practical. With one look at our board we can see exactly who is working on what and who they are working with. Each person has one avatar on the board, therefore they can only work on one task at a time. Occasionally someone will start work without updating the board, but this is very seldom.
We went for the classic South Park characters, each team member got to draw themselves, here is the result:
You may have noticed that my character (Daryn) is a bit stressed out. This is a reminder to myself, that as the ScrumMaster I should not get overly concerned about everything. I need to trust in the team and leave them alone to get the job done. I need to remember that a ScrumMaster is a facilitator and not a manager. For me, not acting like a manager is the most difficult part about being a ScrumMaster.