I’ve recently commented on a conversation in the Agile Coaching group on LinkedIn. I’m reproducing my comment here because it relates with a misconception that I see often.
The question it started from was, in my words, “Is a training enough to change the way a department works?”. My answer is below.
Continue reading “How to Change An Organization”
Back in the 1980s a few developers realized that common patterns appear in the code everybody was writing. They documented them in 1995 a famous book called “Design Patterns: Elements of Reusable Object-Oriented Software”. Today, many software teams have a guideline stating they must use design patterns.
In early 1990s, one former US AirForce pilot became Chief Engineer of a software company. The teams he was working with had many troubles while developing a product. Trying to fix the issues, he decided to fundamentally change their workflow. In 1995 he introduced his new method to the world under the name of Scrum. Today, software teams adopting it often focus on one thing: how to do Scrum by the book.
I can only imagine how the world would have evolved if we treated hammers in the same way. Someone needed to bind two pieces of wood together, thought of nails and used a piece of metal to drive them. He shows his method to other people, they all use it and they call it “hammer”. The 3rd annual convention on the topic focuses on making hammers too light to drive nails anymore.
It doesn’t mean that design patterns are bad, Scrum is useless and hammers aren’t helpful. Just that we tend to forget the purpose and focus on the method.
Continue reading “When The Hammer Becomes More Important Than Driving Nails”
Romanians have a class of jokes called “Radio Yerevan” jokes. My favourite one is:
Is it true that Ivan Ivanovich Ivanov from Moscow won a car in a lottery?
A: In principle yes, but:
- it wasn’t Ivan Ivanovich Ivanov but Aleksander Aleksandrovich Aleksandrov;
- he is not from Moscow but from Odessa;
- it was not a car but a bicycle;
- he didn’t win it, but it was stolen from him.
I realized that the same happens with the rule of 5 whys.
Continue reading “5 Whys Shouldn’t Be 5 And Shouldn’t Be Whys”
The general rule for prioritizing the backlog is that you do it based on business value. From the business perspective, this makes a lot of sense: you maximize the ROI by doing first the things that create the most value in the context of your product, be it monetary or non-monetary (e.g. number of visitors on the website, number of registered users etc). You define the goals during the release planning and then you make sure that you’re going in the right direction.
The second level of prioritizing happens during the sprint planning meeting. The team looks at each story and tries to see if the story is ready-ready, meaning if the Product Owner says it’s ready for the team and if the team thinks it’s ready to start. So actually the highest business value is not useful at this point anymore; instead, there’s something else.
It’s about information.
Continue reading “Information based backlog prioritizing”
Some of my readers may already know that I like to challenge every practice that is accepted as norm in software development. I always ask a few questions:
- What is the value of the norm?
- How can we get the same value in other ways?
- Is one of the above ways better (or at least worth mentioning)?
I’ve recently realized that one of these norms in agile software development is user stories, and I will especially discuss the way we write user stories.
Continue reading “Better User Stories”