Agile / Product Management / Requirements / Requirements gathering / Software development

The Agile Dragon

Posted on:

When Alan Cooper and Kent Beck debated the benefits of eXtreme Programming versus Interaction Design, they disagreed on a lot of things. One thing they agreed on is that Agile processes are designed to minimize the impact of changing requirements. Cooper believes that it makes more sense to minimize future change by understanding the requirements better up front. Beck believes that the requirements can not be understood by the team until something is delivered. Beck’s point is that the customer doesn’t understand the requirements until he has something in his hands. We’ve shown how this is both a strength and a weakness for Agile in the real world. In The Hobbit, the dragon Smaug was missing a scale on his belly, that made him vulnerable. Agile processes have a similar weak spot.

Agile / Product Management / Project Management / Software development

Agile’s Biggest Strength is Agile’s Biggest Weakness

Posted on:

Agile works because it is designed to help teams adapt to changes in direction. Agile is designed to minimize the pain of changing requirements. Agile proponents believe the premise that requirements will change and no amount of upfront planning will impact that. They believe that the requirements simply do not exist until after something has been built. Agile processes save a lot of time by not doing big upfront requirements gathering or design work. They also don’t involve big up-front planning. They do small planning work. And they do it again and again, throughout the project. This works because they minimize wasted planning effort.

Product Management / Requirements / Requirements gathering / Use Cases

Challenging Requirements

Posted on:

The hardest long term challenge in eliciting requirements is improving our ability to do it. The hardest short term challenge in gathering requirements is getting all of them. We have a lot of techniques for gathering requirements, from interviewing to brainstorming to researching. How do we know we defined all of the requirements? Everyone who manages requirements knows the value of validating requirements. But validation leaves a blind spot as it looks backwards instead of forwards. We propose to do exactly the opposite.

Communication / Consulting / Product Management / Requirements / Software development / Testing / Use Cases

Communicate Relevant Quality Metrics

Posted on:

Most teams think about testing in terms of code coverage – what % of the lines of code are covered? What matters to our stakeholders is how well the software works. More precisely, how well does the software let the users work? We should be targeting our quality message in terms of use cases, because that matches their perspective and context.

Agile / Interaction design / Process Improvement / Product Management / Requirements / Requirements management software / Software development / Use Cases / UX

Gartner research on Agile Requirements Definition and Management (RDM)

Posted on:

Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.

Product Management / Requirements / Software development

Goldilocks and the Three Products

Posted on:

Michael on High-Tech Product Management and Marketing has a fantastic “wish I wrote that” post about the importance of having the right number of features. He has several references, the best of which is Kathy Sierra’s Featuritis vs. the Happy User Peak post from June 2005. The two posts combined provide great insight into why having too many features is bad, while acknowledging that too few is just as bad. In this post we will look at what we can do to apply these insights and also change the rules some, making our software more desireable than our competition.

Consulting / Process Improvement / Product Management / Project Management / Requirements / Software development

How To Use Timeboxes for Scheduling Software Delivery

Posted on:

Roger had a great suggestion in the comments to our previous two-part post on scheduling requirements changes based on complexity. Roger pointed out that we had not explained what timeboxing is, but implicitly used the principles of timeboxing in our proposed process. In this post, we explain timeboxes and how they are used.

Product Management / Requirements / Requirements gathering

Product Manager Role Definition

Posted on:

Michael has posted a great definition of the product manager role on his blog, Product Management and Product Marketing – A Definition. He covers a whole host of activities in six seperate areas. Some of the responsibilities, while not product management, are often the responsibility of the product manager. It’s a good real-world assessment of what product managers are often asked to do.

Prioritization / Product Management / Requirements

Epicenter software design – 37signals applies Kano

Posted on:

Jason at 37signals has started a discussion about feature prioritization with his recent post. He describes the epicenter of software as the most important, must-have feature. He argues that this feature should always be the one that is built first, since without it you don’t have an application. This is the same approach we reccommended in our recent post about prioritizing requirements with Kano analysis. The epicenter, while critically important, isn’t sufficient to drive success for the software.