Scrum and XP from the trenches
Scrum and XP from the trench describes how Scrum has been used to apply some Agile project team management methods on real life projects. Henrik Kniberg modestly describes this as a paper while it actually happens to be, well, an excellent practical guide.
The specific jargon may make it a bit slightly difficult to dive into, though. Sprint, scrum master, stories, when iteration, project leader or use cases could have done the trick. This could result in having the author sounding like some kind of sectarian, at least for the first 10 or 20 pages.
However, regardless of the actual Scrum radical approach, the project and people management tips in this book make it a definite must read to whoever is interested in these area of professional software development .
10 lessons in Project Management
The first half of the book mostly describes a Sprint (iteration). 10 brilliant project management tips bubble up from this description :
- Complete transparency on the projet. All people in the team have clear tasks assigned to them, and everybody knows who is doing what, what are the objectives and dependencies.
- Cost estimates are carried out by developers. I’m sure you fellow developers know how terrible that is to meet estimates and deadlines a manager (a technical one if you’re lucky) commited to. Having developers estimating their work (as long as you can challenge them) makes everybody comfortable.
- Never ever compromise on quality to add more stories in a sprint. Rather have less stories.
- Seat the whole team together
- 15 mins daily status meeting. Hard time for procrastinators ahead …
- Always end up the Sprint with a demo. So many reasons : it motivates the team, you can communicate more easily on what you’ve been doing, and hey ! you have to have something working !
- My favorite one : the large taskboard to track the Sprint progress. No fancy colorful excel sheet that no one bar the managers can understand or even bother go through : just a board with colorful stickers for tasks and the Burndown graph. Instant view of the progress, daily updated, always accessible.
- Keep the managers at bay
- Post Sprint retrospective. This helps finding out what could have be done better, validate the initial estimates, the velocity, have the team to talk to provide feedback, etc …
- All meetings are time boxed.
Applying XP with relunctant people
An interesting section of the paper talks more about how Scrum (team organisation) fits nicely with XP (programming methodology), going with the following main eXtreme Programming features.
These are : Pair programming, Test Driven Development, Incremental design (no need to over design at the early stages of the project), Continuous integration, collective code ownership, fighting overtime which eventually happens to be counterproductive, etc …
This is another story to apply these. In particular Pair Programming.
Here comes the other main quality of this book : suggesting different ways of dealing with people to put in place such controversial practices, especially when the most relunctanct people are the ones that never actually experienced those practices.
Each time Henrik describes different situations with different type of oppositions from the developers and suggest an appropriate way of dealing with it. This smooth, clever, thoughtful and yet assertive approach definitely are (from my experience) the most efficient and the less frustrating ones, from both perspectives.
It’s free
And that’s not the only reason why it’s worth having : this is an excellent book, fun and easy to read : strongly recommended if you’re interested in project management methodologies, even if you dont plan to apply such radical technique as Scrum.
Related posts:
- Moneyball: win the national league with the lowest budget
- Software engineering: from the traditional V cycle to eXtreme programming
- Book Review – Project Team Rewards: Rewarding and Motivating your Project Team
- Software marketing management dept. – timing matters!
- Towards a "project managementization" of organizations
Excellent review, Cecil.
[...] Read a more in depth review of this book on Tech IT [...]
Great review, I’ve been interested in Scrum for a while now as I really would like to believe in its philosophy. In my opinion its admission that “things change” is something that many methods try to ignore.
This “adapt to constantly evolving requirements” is really one of the main principle of Agile methodologies .
Scrum being itself an Agile approach fully supports that. Actually the book address that very issue a couple of times.
Another issue is to make sure dev team fully understands the scope of a story and the expected outputs. Henrik gives a couple of examples where during sprint planning just asking a few questions save dev team to develop needless features.
I like that daily status meeting thing. Some people don’t appreciate being monitored so thoroughly though. I experienced it myself, when a few years ago I kept asking everyday to someone I was working with (in a non hierarchical environment since we were talking of non-for-profit volunteer work) what she was doing. After a few day of work together, she answered shouting: “will you stop thinking I’m not able to achieve anything?” Then I switched to a more passive more, giving her mini-projects and checking every 3 days rather than everyday. We eventually became friends…
When working in a startup in Israel, we used to hold daily status meetings. Very often, one of the 3 developers wouldn’t show up: “too busy”, “focused”, “concentrated on an issue”, etc. So we found the solution: hold very quick status meetings 1) when walking to the restaurant for lunch; 2) when we moved to a building that had a restaurant on floor 1 (US floors), we held brief, seamless meetings while waiting for the food. VERY USEFUL.
Although I believe agile methodologies provide some fresh air to rusty V cycles, it isn’t a “one method fits all projects” format. XP, or eXtreme Programming, in my opinion only applies to very specific projects. As far as I see it, it’s very hard to match the conditions for developing in XP organizations. I should write a post some day on the conditions that should make the project team go for XP. What do you think?
I think that the main things with agile (TDD, continuous integration, short iteration etc …) really help in having a very tight control on risks.
From my experience : this is just common sense and it really helped a lot in delivering quality products on time, rather quickly.
In my mainframe years I was using the waterfall approach and I am not a big fan of this. Besides, it just does not cope easily with requirements changes.
To be honest Jeremy, I cant really see type of projects where these basic principles are not appropriate.
Which makes this an excellent topic to debate. Go nuts, guys!
[...] have just posted my first contribution : this is about the Henrik Kniberg e-book : Scrum and XP from the Trenches. I was kinda [...]
Guys, we’re using Wrike project management tool for Scrum now. It works excellent! Though it was hard to believe at first. Take a look at this post http://www.wrike.com/blog/8/12/2007/Scrum_in_Wrike__making_software_development_more_agile
[...] It kind of follows the paradigm that the famous Harvard Business Review article called “The Knowledge-Creating Company” introduces, where experts possess a lot of tacit knowledge, which they use to do their job (Incidentally, the HBR-article is authored by Ikujiro Nonaka and Hirotaka Takeuchi, who are the original protagonists of the Scrum approach). [...]