How many times have you sat in a meeting where the final answer to why something is being done a particular way is ‘That’s how we’ve always done it’? Every time I hear this statement I’m reminded of a story that was related to me some time ago.
A number of monkeys are put in an enclosure by a group of scientists. In the centre of the cage, attached to the roof by a rope, hangs a banana. Looking ripe and delicious, it’s too much for the monkeys to resist. As soon as the first monkey reaches for it, all five are sprayed with freezing cold water causing them to rapidly retreat. Each time one of them approaches the banana, all five are subjected to the same drenching. Very quickly the group learns not to reach for the banana.
After some time, the scientists replace one of the monkeys with a new monkey. The new entrant, unaware of the consequences starts to move towards the banana. It is immediately attacked by the other four, and continues to be attacked until it two no longer approaches the banana.
Over time, the scientists continue to replace the monkeys one at a time until eventually all of the monkeys have been replaced. Each new monkey coming into the enclosure sees the banana, each time they make a move towards it, each time the other monkeys attack until it too learns not to approach the banana.
Whilst the attacks continue for every new monkey, none of the original monkeys remain in the enclosure; none of the current group have ever been hosed down and none actually know why they need to attack when the banana is approached.
Continue reading “How we’ve always done it”
One particularly large client I recently dealt with was struggling to get their teams to meet their delivery commitments. It appeared that in every sprint they lost significant time to blockers, in some cases causing them to miss a commitment by as much as 50%.
This was a large project spanning multiple teams, of the order of about 800 people in total across development, test, product owners etc., with an estimated duration of more than two years. The impact of a consistent 50% delivery rate would literally break the budget, the customer, my client and probably the project.
A little analysis identified the problem to be rooted in the silos into which the teams were organised. In this instance, the silos were pretty rigid with poor communications between the teams. That lack of communication fostered an environment where blockers could emerge and live for extended periods of time.
Continue reading “Blockers and Priority”
If managed not to slumber through Part 1 on estimation, then you find yourself waiting with bated breath for the dramatic climax of our tale of estimation and fixed bid projects.
For the sake of this discussion, a fixed bid project is a project that has a fixed price based on a defined timeline. Of the fixed bid projects that I’ve seen, the timeline often has a 10%-15% leeway on the timeline. The cost almost never does – so you can be late, but you’re going to swallow the cost. Also common, just to twist the knife a little bit more, is the penalty clause. If you miss the date, not only are you going to pay for the additional time and resources, but you’re also going to have to pay the customer for the privilege.
Continue reading “Fixed Bid Projects and Estimation – Part 2”
I make no secret of the fact that I’m a strong agile advocate; I don’t believe software can be developed any other way. In the interests of full disclosure, I should highlight that I said agile, not Scrum, not Kanban, not Crystal Clear in fact not any single process. For true agility in your development process prêt-à-porter is not your friend, you must go bespoke (to use a fashion simile). You build your process based on your business context, and you make sure that it meets your specific business needs and aligns to your business goals.
Continue reading “Effective Scrum Masters”