Why the MVP method is hard – Technical

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

Postpone technical details as long as possible, despite what your PM tells you

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

When to use User Stories, Use Cases and IEEE 830 – Part 2: Use Cases

I find use cases extremely valuable for eliciting requirements. Focusing the discussion on the business process with an informal use case, where each step is simply a bullet point and we don’t worry about using correct use case terminology, makes it much easier to keep conversation on track and productive and helps clarify and avoid misunderstandings that often occur between stakeholders and development staff in requirements discussions. Continue reading

Scrum, Agile, Complexity and Ants

(Originally posted here December 2, 2011)

I started re-reading Agile Project Management with Scrum by Ken Schwaber a few days ago, after not having looked at it in far too long. I was struck by the similarities between Schwaber’s view on the complexities of software development and the concepts of Complex Systems Theory I recently read while helping someone do research for a paper. I have to think that Schwaber and the other founders of Scrum were at least partly inspired by it.

Complex Systems Theory is, not surprisingly, difficult to describe in a nutshell. Continue reading

Flattened Requirements Management

 (Originally posted here January 13th, 2012)

In 2003, Thomas Friedman wrote in The World is Flat how ten factors, which he called ‘Flatteners,’ have converged to create a more level playing field in terms of doing business, making it much easier for organizations in developing countries to compete with developed world companies in a number of industries. One of the flatteners is supply-chaining, which he describes as “a method of collaborating horizontally – among suppliers, retailers and customers – to create value.”

He predicted that in order for organizations to succeed in this flattened world, they need to learn to work closer and more collaboratively with their suppliers. Continue reading