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.
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’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.