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.
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
As it’s been a few weeks since my last post I thought that I’d write about what’s been keeping me busy lately.
A few weeks ago I did a webinar with IAG about the role of a business analyst in an agile environment. We discussed some of the common misconceptions about Agile, why having an analyst on the team is critical in many organizations and then gave some tips and guidance for being successful as an analyst on an Agile team. I’m told over 600 people attended the webinar live.
On the topic of public events, 3 of my recent blog posts on user stories, use cases and requirements have been picked up by the Business Analyst Times. The first was posted on their blog section and was highlighted in their promotional material this week, and the remaining two will be published in the coming weeks.
The third area that has been keeping me occupied is improving my technical skills. I’ve been finishing up a few projects that I started to refresh my knowledge of Java and SQL, as well as learn new (to me) technologies like JQuery, App Engine, Python, Django etc. You can see the results of some of these projects on my site www.nunucat.com. I’ve also been spending a fair amount of time on udacity.com, a Massive Open Online Course site that has some excellent courses in everything from Physics to Interactive Graphics to Psychology to Applied Cryptography to… Needless to say I’m addicted.
I recently took the Scrum Master course and certification. If you work in software development in any capacity and you have the chance, I recommend you take this course, even if you aren’t a proponent of Scrum itself. Approach it with an open mind and you’ll come away thinking a little differently about managing people. I’m not saying you’ll be an Agile convert, but it will make you re-examine lot of the fundamental assumptions of traditional project management.
As a business requirement specialist, I was particularly interested to see how an experienced analyst might fit into Scrum. I had read a couple of books on Scrum, Kanban, and other Agile topics but I found them somewhat vague when it got to Continue reading
Test Driven Development (TDD) turns the process of writing code and designing systems around, having developers create an automated test or tests before making any changes to the system at all. If the system then fails the test, the developer makes only the changes necessary for it to pass the test, including possibly refactoring the code or addressing the design if necessary. Then the developer reruns the test.
There are many benefits to this practice. First, Continue reading
I am often asked this when delivering training on writing requirements. The most obvious difference is semantics. A user story is generally written as a statement of something a user wants to do with a system and for what purpose. For example:
I want to find clothing that is my size.
While a requirement statement is traditionally written in a more formal style, starting with “The system shall” Continue reading
Recently I participated in a series of instructor-led online courses on Scrum/Agile. During the section on Sprint Planning, the instructor mentioned that shorter iterations provide more agility, and organizations should aim to achieve weekly sprints. This prompted one student to ask:
“The business people I need won’t attend my monthly meetings. How can I get them to attend a weekly planning meeting?”
This is one of the most common complaints or questions I receive, so it was no surprise that a student asked it here. However, what did surprise me was the instructor’s response:
“Tell them that if they don’t participate they can expect the software to be buggy and not meet their needs.”
I have witnessed this sort of approach before, but I was shocked at this answer from someone who claimed to be an expert in Agile. It contradicts the fundamental principals described in the Agile Manifesto: Continue reading