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 →
The big buzzword these days seems to be MVP, meaning Minimum Viable Product. It’s a reference to the approach to product development described by Eric Ries in his book The Lean Startup. However, while I’ve been hearing and seeing the term MVP a lot, I’ve almost never seen anyone executing the process that Eric Ries describes.
More often than not, what is called MVP is what I call MPP, or Maximum Possible Product. The word Possible has a double meaning: 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.
A hammer is good for nails, not so good for fixing televisions. A scooter is the best way to get around town, unless you’re in Montreal in January. Choosing one method to describe the customer’s need across projects, teams and environments actually hinders good analysts, architects and developers as much as it helps. What is much more valuable is having an analyst who understands and has the ability to use all of the tools, and relying on her to work with her team to decide whether to hammer the nail or take the subway.
Use Cases, IEEE 830 style “The system shall…” requirement statements, and User Stories each have advantages and disadvantages. A good analyst, or project manager, should know the advantages and have the ability to choose which is most appropriate for the project. Continue reading →
Lack of stakeholder and user involvement is often cited as a primary reason for project failure and the greatest source of project risk. Unfortunately, whether you adhere to an Agile, traditional, hybrid or mixed methology, getting and keeping customers involved in the development process is always a challenge. I explained previously that the most common reasons customers state for not being involved are that they are too busy, they don’t trust the technical team’s ability to deliver, and that they don’t see the meetings as productive.
The first reason is generally beyond a project manager’s control, and the second is a lack of trust between stakeholders and IT that is often Continue reading →
In my last post I described 3 reasons customers cite for not participating in development. One of the reasons, and one that a project manager or business analyst can impact directly, is the customers feel that the meetings are not a productive use of their time. They feel the meetings don’t accomplish anything, take too long, or that they were unable to contribute and their presence wasn’t necessary.
I’ve witnessed many meetings with customers that I would describe as dysfunctional, and I’ve worked in many organizations where meetings with no agenda, no direction and unclear outcomes are the accepted norm. The focus Continue reading →