Specialists are very useful. They are also a pain. It is great to have the experts around when we need them. But specialists are also add painful management overhead. I accept I have to do it but I wish I didn’t.
I’m going to look at three situations where I’ve had to deal with specialists and explain what I did:
Headphones. I hate them. If I wore headphones at work I would be cut off from a lot of vital information about what is really going. It would hamper Management on the Ground. So I never wear them.
Continue reading
I’m often in the situation where I’ve got both business representatives and product managers in my programme team. The big question is: who is the Product Owner?
Continue reading
You start the Sprint confidently but the burn down chart starts going up. Things are a lot harder than expected! Your velocity is lower than you expected. What to do?
Continue reading
My programme’s Sponsoring Group asked me to send a weekly status report. This was to compensate for the fact they were at a remote site and hence couldn’t see the walls of our informative workspace. They were paying the bills so who was I to argue.
Luckily they don’t want a lot of detail. They want to know three things:
Common wisdom, and self help books, says that anyone who completes 10,000 hours (10 years) in their chosen discipline will excel. This is part of the rationale for Code Kata and Coding Dojos from the Software Craftsmanship movement. But the 10 years equals expert formula isn’t true.
Continue reading
I value project managers and see an on-going need for them within a Lean-Agile context. Admittedly the role of the project manager changes when using an Lean-Agile approach, becoming more of a shepherd and less a military officer. In this, the first post of a new series, I thought I’d revisit my definition of the Agile Project Manager.
Continue reading
So you are up and running with Lean-Agile but your team is still growing or there is some churn in the team. Either way new people arrive, often without an effective Lean-Agile background. What to do?
Continue reading
Everybody has pet requirements and product owners, being human, are no different. Unfortunately pet requirements are a real risk to software projects. We should all resist these pet requirements and do everything possible to kill them off ASAP and avoid building them. So how do you spot pet requirements
Continue reading
David shambles up to the Kanban board. He moves a card from “Dev In Progress” to “Dev Done”. No emotion cracks his blank facade. There is no celebration of a job well done. No acknowledgement from others in the room. David glances briefly to his left and then pulls another card from “Ready for Dev” into “Dev In Progress” before shambling back to this desk. Another burst of coding begins. This little scene has occurred four times already this week, 19 times this month, and 271 times since David joined the project 15 months earlier. Is David just a machine in the Lean-Agile software factory? A mindless development automaton?
Continue reading