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
In my previous post I talked about how the MVP method is very frequently referenced but rarely used. Organizations usually use the word Minimum Viable Product when they develop what I refer to as the Maximum Possible Product, where the features for the product are defined up front and then as many of those features as possible are delivered before a deadline or within a budget. They do this because the MVP method that Eric Ries describes is not as easy as it sounds.
Probably the most difficult obstacle to the MVP method is the structure, values and history of the organization itself. Certain very common characteristics can make it next to impossible to execute a project that emphasizes testing, learning and changing direction based on feedback. Let’s talk about three of these characteristics.
The most common organizational barrier I see is focusing on avoiding project failure, sometimes referred to as “front loading.” For example 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.
I’ve always been a firm believer that whether you’re Agile or Traditional, it’s important to postpone describing technical details as long as possible. It’s very tempting to start to solve problems ASAP, because there is something very satisfying about solving puzzles. Also, many project managers and others who are being held to deadlines will push to start design and coding as soon as possible. However, I believe in, as someone I met recently described it to me, a “back to basics” approach.
One challenge I often face is when a client pushes for me to start technical discussions with the users. Their argument Continue reading
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.
December, January and February are often very busy times for consultants. I apologize for the long delay between posts.
I’ve been working on a few things, including some videos for Business Analysts trying to adapt to Agile, and to establish myself as an independent consultant for Requirements and User Story development. However, the topic of writing user stories has come up so frequently for me lately 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 lately 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 what they’re expecting to use the written user story to communicate the need. Continue reading
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