Purpose Finding: Only solve problems you need to

Brian Williamson has commented that although “problem-solving is important and good when you are stuck. I’m convinced we are in need of some more purpose finding.” I agree and finding purpose manifests in several places in my approach.
Continue reading →

Product at the end of its life cycle? Try the Scream Test

One of my teams was responsible for maintaining over 3,000 applications, utilities and audience facing services. We didn’t know who owned or cared about the majority of these. This mysterious majority had been commissioned in the mists of time by people who’d moved on. 3,000 was too many and we needed to cut. Our only recourse was the “Scream Test”.
Continue reading →

Help! Looking for Topics for “What to do when . . . ?”

I need help. Every month for the last 18 months I’ve been posting something to answer the question What do I do When … ?. People seem to like the format but I’m running out of ideas. I’d appreciate some help finding topics for a new batch of posts in this series. Please drop me a line or add a comment if you’ve got a question you’d like answered or just a suggestion for a topic.

No space to co-locate team – think again

I knew I had a big problem when I walked into the new programme space and found 18 desks. 18 wasn’t enough. I predicted I would have about 35 people on the team and I wanted them together. Co-location is so important to me that I will always challenge the assumption of “there is no space”. And I have found there are lots of things I can do to get my team together.
Continue reading →

Avoid the Refactoring Branch of Doom

Sometimes I make mistakes. One of them was when I commissioned what I now affectionately call the Refactoring Branch of Doom. Doomed because it was never ending. The refactor was too big and, because it was done in a branch away from the main code base, the refactoring guys never caught up with the main development team. So I canned the doomed refactoring initiative and we did it a different way. One that worked.
Continue reading →

Cucumber: Who writes the Gherkin Scenarios

Gherkin, the language used in Cucumber to write tests, is meant to be understandable by folk from the business. I haven’t encountered product owners able to write their own scenarios. And I don’t trust either developers or testers to do it on their behalf. The only people I trust are business analysts trained to write and think Gherkin.
Continue reading →

What to do when Scope is Fixed

Sally was a prospective customer of mine. She worked for a high profile but rather old school company and wanted a fixed price contract. Sally genuinely thought her business analysts had nailed down the scope and was confident nothing would change. From her perspective all I had to do was price the work and deliver the product. Sounds perfect except Sally was wrong. My experience is that, fixed price or not, scope is never fixed. Pretending nothing is going to change is a form of self-delusion. Sally was deluded. What should I have done?
Continue reading →