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
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.
A common cause for consternation in development projects is when requirements or features are missed in the early stages. Missing requirements in traditional development can be very painful, as the gaps are often discovered either in Quality Assurance or in UAT, or later, which means the majority of the development budget and schedule has already been spent and addressing these new requirements will set the project back a significant amount of time. When using an iterative and incremental method, such as Scrum or Kanban, missed requirements are less problematic because development is usually still ongoing and the requirements can be added to a backlog and re-prioritized. However, this can have adverse effects on the release plan and overall budget, and there is still the risk of learning of the gap too late.
The topic of writing user stories has come up so frequently that I felt a burning need to write something on the subject.
I’ve seen posts on newsgroups and I’ve received questions from clients about the “correct” writing of user stories. Do we use “Shall” or “Will” or “Must?” Do we start with “As a <type of user>?” or should we start with “In order to <achieve some value>?”
In short, these people want to know how to write user stories effectively, which is a valid question. However, usually with some probing what I uncover is that they’re expecting to use the written user story to communicate the need, which is not a recommended practice. Continue reading
I’ve been working at refreshing my technical skills lately, primarily by experimenting with Google’s Appengine in Java and learning Python through some online courses. This has lead to a number of realizations, but perhaps the most important was the one I had today. 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