Category: agile project planning
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.
Bookmark/Search this post with:
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?
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
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
Bookmark/Search this post with:
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:
- Review the format of User Stories and the Kano Model.
- For each Role,
- Identify the main goals
- Identify the functions which that person wants the system to perform to achieve those goals
- Decide on next steps: Homework or Implementation
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
RSS feed