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
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 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
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.
I recently took the Scrum Master course and certification. If you work in software development in any capacity and you have the chance, I recommend you take this course, even if you aren’t a proponent of Scrum itself. Approach it with an open mind and you’ll come away thinking a little differently about managing people. I’m not saying you’ll be an Agile convert, but it will make you re-examine lot of the fundamental assumptions of traditional project management.
As a business requirement specialist, I was particularly interested to see how an experienced analyst might fit into Scrum. I had read a couple of books on Scrum, Kanban, and other Agile topics but I found them somewhat vague when it got to Continue reading
Recently I participated in a series of instructor-led online courses on Scrum/Agile. During the section on Sprint Planning, the instructor mentioned that shorter iterations provide more agility, and organizations should aim to achieve weekly sprints. This prompted one student to ask:
“The business people I need won’t attend my monthly meetings. How can I get them to attend a weekly planning meeting?”
This is one of the most common complaints or questions I receive, so it was no surprise that a student asked it here. However, what did surprise me was the instructor’s response:
“Tell them that if they don’t participate they can expect the software to be buggy and not meet their needs.”
I have witnessed this sort of approach before, but I was shocked at this answer from someone who claimed to be an expert in Agile. It contradicts the fundamental principals described in the Agile Manifesto: Continue reading