peterstev's blog

That Was the Year That Was

December 30, 2008 by peterstev

I’ve promised myself I would actually take some vacation this week, and fortunately with small children in the house, it’s actually possible to do so! So, before the kids wake up, a blitz retrospective: High Points, Low Points and Potential for Improvement in 2009.

My First Experience with Business Value Poker

December 17, 2008 by peterstev

Last week, I wrote down a new idea about how to determine business value using a variation of planning poker. At the same time, I tried out the method in a real project. How did Business Value Poker survive its first encounter with the real world?

Previously, the two product managers had come up with a list of functions. The dilemma was that Product Manager #1, the manufacturer of the complete system, valued new hardware sales generated by the software. P-M #2, a user of the system, valued operational savings. At the first attempt to prioritize, each manager was given 1000 points to distribute among the functions. The business value was the sum of each party’s vote. This produced a value but no consensus.

Figuring out Business Value with Planning Poker

December 10, 2008 by peterstev

In a perfect world, there is one product owner who knows the market, knows the application and can assign business value to each function on the backlog. But coming up with a dollar value for a feature can be difficult and in a joint venture the problem is compounded, because stakeholders with complementary interests may have a very different basis for valuing a function. There are two product owners, so the situation can be very delicate. How can the two parties agree on priorities for the next release?

5 tips for Iterating through the holidays

December 3, 2008 by peterstev

As we get closer to the holiday season, external factors threaten to disrupt the sprint rhythm. People go on vacation, sprint meetings fall on or between the holidays, and company events pull the team away from project commitments. At the same time, the pressure rises to get affairs wrapped up by the end of the year. It’s time to get that release out, time to close that deal, time to define the next version.

Here are a couple of tips to help you get the through the holiday season with a minimum of additional (job) stress.

10 Ways to Save a Slipping Project

November 19, 2008 by peterstev

If anyone is looking for proof that agile and waterfall are from different planets, you just need to check out this article by Tom Mochal at TechRepublic, 10 ways to get a slipping project back on track. Overtime was top of this list, even if the deadline is months away! My first reaction was to roll my eyes. But this raises the question, what do you do to save a slipping project, especially if you are trapped in a waterfall?

No time for reflection? Try a 5 minute retrospective

November 12, 2008 by peterstev

I recently started managing a new project. As such projects are by definition “challenged”, I like to start with a retrospective to find out what to focus on and earn some initial respect from the team. In this case, the team is working fervently to get a release out, which should happen in a month, so everybody is under stress and no one wants to take time off for “diversions”. A heartbeat retrospective takes 1 to 2 hours, depending on the size of the team. How do I get the team to do a retrospective under these conditions?

Ken Schwaber applied an interesting technique at his plenum session in Stockholm. At the time, I thought it was just a nice device to help conference attendees get to know one another. Ken would pose a deep, thought provoking question to the audience. Then he would ask everyone to discuss the question for 5 minutes with two or three of their neighbors. Then he would go around the audience and ask the spontaneous teams what answers they came up with.

Finding a Partner to Trust - Using Competitive Sprints to Select an Agile Software Vendor

October 29, 2008 by peterstev

Some people would like to believe that building complex software is like going to the grocery store: pick a candy bar off of the shelf, ask what it costs and decide to buy it. You get no risk and quick gratification. But building custom software is more like building a race car. A special one-off product to meet exactly the needs of its sponsor: win races.

As a customer, what are you really buying when you contract for software development? You may think you are getting a solution. But what you are really getting is an implementation team. And risk is always part of the bargain. So what you really want is a team you can trust to build your product and to minimize the risk of that choice.

In this article, I present a lightweight, lean approach to selecting a software development partner which should dramatically reduce the risk and cost to all parties.

Finding a Partner to Trust - Writing an Agile RFP to Outsource a SW Development Projects

October 22, 2008 by peterstev

My customer wanted to find an external partner to develop their new software product and develop using Scrum. So we needed to evaluate the potential partners, but how? The classical approach is to define the application “exactly”, then ask some potential vendors if they can do it and how much it will cost (and then haggle over the price). This is not very Scrum like, but it represents a starting point which is well understood by customers and vendors alike. What is different about an Agile RFP?

Finding a Partner to Trust - Using Scrum to Create an Agile RFP

October 15, 2008 by peterstev

I just finished helping a customer write an RFP (Request for Proposal) for a software development project. The customer has had some expensive experiences with waterfall style projects, and Scrum had been the key to getting those projects back on course. So it seemed logical to plan Scrum from the beginning. But how do you write an agile, Scrum-Compatible RFP? How do you select a company to implement an agile project? We started with Scrum. Part 1 in the Agile RFP Series; 1. Using Scrum to Create an Agile RFP 2. Contents of the Agile RFP 3. Selecting an Agile Outsourcing Partner Google was remarkably unhelpful with this problem. The top links all pointed to a paper and presentation from 2003 about combining Use Cases and User Stories in the RFP process. A request to the ScrumDevelopment Group produced no responses. So we were on our own.

Prioritizing the Product Backlog

October 8, 2008 by peterstev

Any project plan is a mixture of what the product owner wants and what the team can actually deliver. The product owner naturally wants more than the team can deliver, so s/he has to prioritize in order to get something useful in the desired timeframe.

Once you have a prioritized product backlog, you have the prerequisites for calling the first Sprint Planning Meeting. How do you convert an unordered list of features into a prioritized product backlog which you can give the team to implement? What should you do first?

I’m not sure that there is a correct answer to this question. It will depend on your product, your company and your situation. Let’s take a look at some widely used strategies for prioritizing the product backlog

• Minimum Marketable Feature Set - the first pass to narrow the list of stories
• Business Value First - Focus on High Value Functions
• Bang For the Buck - Go for easy wins
• Technical Risk First - Do the hard things first
• Defer Risk - Do the hard things later (or never)
• Vote - Ask your users