peterstev's blog

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

Filling the Product Backlog: Go For Excitement

October 1, 2008 by peterstev

Once you know who you are building the product for, the next step is to create a list of features which will excite your customers and get them to use and buy one of your products. Which functions should you put into the system, and why? The user story workshop creates the initial product backlog.

This workshop is similar to the last workshop where you identified the users and buyers of your systems. This workshop needs the same people, except that the importance of the development team rises as you get closer to implementation. It is also desirable to have some real users represented. The workshop structure structure is simple:

1. Review the format of User Stories and the Kano Model.
2. For each Role,
1. Identify the main goals
2. Identify the functions which that person wants the system to perform to achieve those goals
3. Decide on next steps: Homework or Implementation

Creating the Scrum Product Backlog: Start with the Users!

September 24, 2008 by peterstev

When defining a product, it’s easy to write down list of features and call it the product backlog. It’s much harder to build a product which so deeply and profoundly meets the needs of its users that they just have to buy it. An agile team can use a three workshop process to create the Scrum product backlog. Workshop 1: Identify the users. Workshop 2: Figure out what they want. Workshop 3: define the feature mix which will get you to a product that the customers want as quickly as possible. Let’s start with Workshop 1, the Users.

How to get your agile project approved

September 17, 2008 by peterstev

There are three prerequisites for starting a project under Scrum: a product owner, a product backlog and a team to implement the features. Is that enough to get a project approved for development? Probably even an agile company will want some basic questions answered: What are we building, and why? How much will it cost? How long will it take? Here's a way to move forward.

The Big Development Project: How much should it cost?

September 3, 2008 by peterstev

Some people think that agile and budgeting are incompatible. The product is ready when the product owner says it is. But before starting a project, most managers want at a least budget. So the product owner puts together his wish list and asks the ScrumMaster what it will cost to build. The answer comes back – usually a long time and whole lot of money! Then the customer turns pale as he tries to decide what it will really cost, whether he can afford it and whether it’s worth it.

But there is a better way: the product owner can perform a double worst case analysis. This quick and easy tool uses the project’s business value to determine a reasonable price for the software investment.