I was talking to Pedro Santos on the train the other day. Pedro is my technical lead, an expert in his field and a keen advocate of automated testing and software craftsmanship in general. We were talking about Gherkin and Pedro was saying he doesn’t see Gherkin tests adding value because it doesn’t help him as a developer. Of course I disagree. The way I look at it is the Gherkin tests are not for the developers. The Gherkin tests are for the organisation – they are for everybody.
Continue reading
It is ALL Number One Priority / It is ALL Must Have. Not true!
If the customer claims everything on the product backlog is top priority, and by implication must have, then you’ve a bit of an education job ahead of you. You have to get the customer to the point where only one thing is top priority and even “must haves” are sorted into a priority order. There is a good chance some of those “must haves” turn into “would like to have” and in time disappear.
Continue reading
Solution Convergence: Marrying Business, User Experience and Technical Input
My product owner was upset when I told her she couldn’t have the widget that she had agreed with the User Experience (UX) Designer. The problem was the design was not technically feasible. To get a great solution to meet the business requirements three parties – business, user experience and technical – must agree on the approach. That negotiation is what I call “Solution Convergence”.
Continue reading
My four days of silence surrounded by developers
Developers are different from other folk. Introverted is an understatement. My four days of silence really highlighted this.
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
PMs Need a Technical Ally When Introducing Automated Testing
I need a technical ally when introducing Specification by Example and BDD. Actually I need a technical ally when introducing automated testing of any kind. Somebody to coach / mentor / encourage / explain / enthuse about the technology and how it helps.
Continue reading
Nine Things to do When Nobody on Your New Team Knows Lean-Agile
Last month I looked at what to do when everybody on the team says they know Lean-Agile. This month I look at what to do when nobody on your new team knows Lean-Agile.
Continue reading
Four Reasons to Book Regular One-to-One Meetings
Rich and Rachel were a bit surprised when they noticed I had a regular weekly one-to-one meeting booked with Michael. I had worked with them closely for over a year, relied on them heavily, but a relative new comer with less responsibility got a dedicated slot from me. How come?
Continue reading
Two Heads are Better Than One
My problem was how to transport my hot black Americano to work in a bumpy taxi without the coffee slopping out of the cup, making a mess in the taxi and burning me. Generally I believe in sharing. When I’ve got an insoluble problem I’ve found it even more important to share. Somebody (else) has the answer. And in this case a quick brainstorm with a colleague gave me a simple solution.
Continue reading
Specification by Example helps even with no Automation
I’m keen on Specification by Example particularly with a tool like Cucumber to automate tests. However this style of specification is also useful without the automation. I introduced my current team to Specification by Example and, with some help from me, the customer is now using the same disciplines to define requirements to hand to a 3rd party development shop. The experiment has been very successful.
Continue reading