I recently had a chat with a developer who has a very negative perspective on Agile and Scrum. This isn’t surprising; many people do. One thing he said inspired me to write this blog post.
We were talking about Scrum, and I mentioned that I hate the word “sprint.” It implies that the team must run at full speed. The principles of the Manifesto for Agile Software Development state “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Even Olympic marathon runners can’t sprint indefinitely. I’d prefer a term that doesn’t bring to mind people collapsing on the ground gasping for air at the finish line.
He said, and I’m paraphrasing here, that one of the reasons that Agile is popular is that it’s used to get developers to work more and to work harder. He’s not wrong. The use, and abuse, of story points is part of the issue. Continue reading
In the third part in my series on user stories (Part 1 here, Part 2 here) will briefly cover some points on estimating user stories.
“How big should a user story be?” “What’s the difference between an epic and a story?” “How do I estimate the size of a user story?” “How do I know when a story should be split?” “How do I split stories?” When I first started working with user stories, I had these questions and Continue reading
Using stories effectively is a topic regularly asked about and discussed in forums, training and when coaching. It’s a big topic, however, that I can’t really cover in detail in a blog. Instead, I’ll provide my top 5 tips with some explanation for each. Continue reading
I’ve written previously about user stories, and I have compared them to other requirements techniques. Since then I’ve used them and seen them used in many new ways, some successful and some less so. I also often see people asking how to best use them, create them, develop them, size them and so on. I decided to dedicate a short series of blog posts to user stories.
The first, this one, will discuss common misunderstandings. Please at least skim it before reading the rest! After this post, I will provide some guidance on how to get the most out of user stories. The last in the series will discuss a very common question – how big is a user story?
But first, lets get some very common misconceptions about user stories out of the way.
Myth: If you’re doing Agile/Scrum/Insert framework here, you must use user stories
This is 100% false. Continue reading
I recently read a brilliant article on the myth that Scrum is faster and cheaper than traditional development. I highly recommend reading it, and no, I’m not affiliated with the writer or Scrum.org!
The article articulated something I feel is poorly understood. Following the ceremonies, roles and artifacts of Scrum is not a faster way of developing software. In fact, I am fairly certain that if you had two similar teams, gave them the same large specification and had one team develop to that specification using two week increments and the other using a waterfall approach, the second team would finish earlier. Why? (I’ll explain the underlining below) Continue reading
This is the 4th and last post in the series about why the MVP method, as described by Eric Ries in The Lean Startup, is more challenging than it first appears. Many organisations, large and small, refer to it. In fact it’s sometimes hard to find product road maps or project plans that don’t make reference to an “MVP.” However, few are able to apply even the most basic tenets of the MVP method, and instead fall back on traditional development paradigms which results in what I call the MPP.
Previous posts discussed the organisational and personal obstacles to applying the method. Let’s look at the technical challenges. I find this is something that is often glossed over, Continue reading
Over the last few posts, I’ve discussed how the MVP method is very frequently referenced but rarely used, and there is a good reason for this. It’s not easy. There are many tall obstacles to applying it successfully. My previous post described how the organisational structure can challenge the process. This post is about an obstacle that may be easier to change, but sometimes more difficult to recognise: You.
You want to be a visionary
I was recently asked what to do when a stakeholder or client asks for a feature or user story that either doesn’t make sense or is based on flawed logic or on a lack of technology or domain knowledge. Sometimes stakeholders’ pet projects, wacky ideas and whims and fancies can be the nemesis of a product owner and her team. They waste valuable time and resources and in some cases they can affect team morale, as the team feels that they are on a fruitless errand.
I have two solutions to this problem: Nip it in the bud or meet them halfway.
I’m going to make a bit of a radical proposal here. I propose that we add the following to the Agile Manifesto:
We value interpersonal skills over technical knowledge
I’m not really proposing that we change the manifesto. I’m also not stating that technical knowledge is not extremely important. Remember that the Agile Manifesto states that we value the things on the left more than the right, but we still value the things on the right. I’m just making a point that I think a lot of organizations miss that affects their ability to really get the most out of Agile and Scrum.
One of the most common myths about Agile and Scrum is that it’s something that only affects the developers. People, in particular executives and directors, believe that undertaking an Agile transformation means project teams change the way they work together and the rest of the organization just reaps the benefits. While this may be true in the short term, it’s often leadership and management that have to make the biggest changes for Scrum to be successful.
I was inspired to write this post after a chat with a friend who works in an organization that has been using Scrum for a few years. He told me that it didn’t take long for the weaker leaders to struggle as the organization adopted Scrum. He also said that the changes to how teams worked and were led created natural leaders who stepped forward and took the reins, sometimes even people no one expected.
I’m going to explain this with a rather facile example. Continue reading