If no one is pissed off with you then you are dead but just haven’t figured it out yet!
Tom Peters (2004)
Author Archives: Steven Thomas
Bucking Bronco: Software Projects that Kick
Leading software development often reminds me of what it must be like to ride a bucking bronco … with the added problem you have to go somewhere at the same time.
Continue reading
Declarative vs Imperative Gherkin Scenarios for Cucumber
Everybody I’ve met that is new to Gherkin starts with an Imperative style of scenarios. The Imperative approach is simple and intuitive and reflects what manual testers do. But I hate the Imperative style with a passion. I favour a Declarative style of scenarios not least because a declarative style means I can test business rules. The UI is prone to change but the business rules tend to be more stable.
Continue reading
Developers don’t have time for code reviews and unit tests
The ticket moves to “Dev Done” but there are no unit tests and the code hasn’t been reviewed. When challenged the developer says “That’s because I don’t have time for that stuff”. If I hear that I want to know why they feel they don’t have time, then I give them the time.
Continue reading
Fluid Planning and Execution Creates Agility
Thought leaders in the US military are challenging traditional approaches to command and control. These military innovators are proposing a more fluid approach that allows simultaneous planning and execution. It is good to see they are catching up but as an Agile practitioner I already do fluid planning and execution.
Continue reading
Whose responsibility is testing anyway?
I have a painfully small manual test team, sometimes 1 tester per 15 developers. The answer to the obvious question “who tests?” is “mostly the developers”. Of course this only works if you’re doing extensive automated testing including Specification by Example with a tool such as Cucumber.
Continue reading
Cake Driven Development
I don’t know whether it is me or whether it is just people, but my teams tend to obsess about food. Particularly cake. Food entwines itself in the team culture. And that is why I think it is worth a blog post.
Continue reading
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
When Buckets Go Bad
I use the term Bucket Planning for Release Planning. The metaphor works because buckets overflow if overfilled. There are risks associated with Release buckets corresponding to Minimum Viable Products (MVP). A large MVP bucket has gone bad and a MVP Bucket that continues to grow is a Bucket gone really bad.
Continue reading