In my previous post, 15 Steps to Agile Project Planning Success, I focused on the Inception workshop aspect of Agile project planning. Here I’d like to step back a bit and look at the steps and events that occur before the Inception workshop in a little more detail.
As Scrummaster or Agile Project Manager, you want your Scrum team to be successful and you’re probably willing to do most anything to see that it happens. One way to help the team be successful, and let the organization know what they can expect, is to do high level upfront planning.
The Scrum Guide gives lots of guidance on planning for Sprints, talks about Backlog Refinement in a side reference to planning, but doesn’t say anything about high level planning for the project. This isn’t the way it always was. Back in the 2010 version of the Scrum Guide you would have seen both Release Planning and Release Burndown charts. This was removed to highlight the fact that Release Planning isn’t necessary to do Scrum. It may not be necessary to do Scrum but hardly a business exists that doesn’t want some predictive means of future outcomes. This is where the Scrummaster or Agile Project Manager steps in and help make the Scrum team be heroes.
Any software project starts with a business need or goal. This might be playing catch-up with the competition’s latest release, customer feedback for product improvements, an innovative idea, a business’es desire to grow, or simply someone’s idea of what to do next. Some of these project ideas might be successful, some might be failures but all of them can benefit from planning.
Below are 6 simple steps to initiate your Agile project.
- Validate the problem and the solution
- Validate the feasibility of the solution
- Identify the Scrum team(s)
- Identify your key stakeholders
- Identify your key customers
- Create the measures for the project
1. Validate the problem and the solution
The first thing that should happen is validation of the problem your product has, and the solution. This part of preparing for your Agile project is the first instance where you hope to fail fast. Through validation you could easily discover your insanely great product idea is merely insane.
The problem is tied to the business goal the company wishes to achieve. For example, the business goal is to signup more subscribers. You theorize customers aren’t signing up because it’s slow and hard. Fixing this will result in more customers signing up because we’ll make it faster and easier to sign up.
This is also where you hope to fail. Failing here costs practically nothing compared to the cost of building an unwanted product. This step would generally be initiated by the Product Manager but involves development and the Scrummaster or Agile project manager. It may also involve other departments in the business like Sales and Marketing.
The easiest way to validate problems and solutions is through conversations with customers and users. Does your hypothetical problem and solution resonate with customers? If 2 out of 10 potential customers like your idea, that’s an interesting statistic. If 8 out of 10 potential customers love the idea, this is very meaningful and you are much more likely to have something worth pursuing.
2. Validate the feasibility of the solution
The problem and solutions have now been validated with customers and users. You now need to confirm if the company has the knowledge and resources to fulfill what the customers need. The development team validates that technically, the solutions can be done. The development team also confirms if they possess the required skills to solve it. This step will require some initial estimates made by the development team to check that the costs don’t exceed the potential benefits. Ideally, the Scrummaster and Product Manager have brought in at least one member of each team that could potentially work the project to provide these rough estimates.
This step is done as a research and prototyping exercise but needs to answer these questions:
- Can the work be done?
- How many teams will be necessary?
- What skills are currently available?
- What skills need to be learned?
- How long would it take to do the work?
- What does the high level architecture look like?
- What will I get at the end of the project?
If this is a massively large project requiring 100’s of Agile teams, the Product Manager, with the help of the most experienced developers, break down the work into something like “10 team” increments. For example, creating a product like Microsoft Office might require this to be broken down into smaller, more manageable chunks. These might be, Common Infrastructure, Word, Powerpoint, Excel, Outlook, etc. The goal of breaking down the work is so a small pod of teams (e.g. 10 teams) can work independently of any other pods if possible. Identifying independent streams of work will likely influence release planning later during the Inception workshop.
A note of caution on the estimates. If the estimate is 60 person months, that doesn’t mean 60 people can do the work in a month. The group working the feasibility of the solution should consider the maximum number of people who can work concurrently on the project. This means that special attention be given to any dependencies. In the group’s thumbnail architectural sketch they will need to factor in both serial and parallel development efforts before giving high level estimates.
3. Identify the Scrum teams necessary
Following on from step 2 above and assuming you haven’t failed the project based on step 2’s answers, the Scrummaster and Product Manager, along with development team leads, determine specifically which Agile teams are needed. This will take into account availability and skills but may also identify any necessary training. Although a project may not start with a full complement of teams, it is important that all teams be brought on-board for project visioning and the Inception workshop events.
4. Identify your key stakeholders
Successful projects depend upon a variety of people. The Scrummaster and Product Manager need to actively determine who their key stakeholders are and what their influence and interest in the project is. These stakeholders, usually part of the business hierarchy, have goals that they hope the project fulfills. You need to know this and actively demonstrate progress toward achieving their goals. You also need to identify any contradictory goals between stakeholders and resolve them now. These can’t be left to fester because they could eventually derail the project.
To resolve any conflict you’ll need to reestablish the business goal(s) the project is meant to meet. This will require the stakeholders and you to review the business goals, and how the project intends to meet them. A frank and open discussion will bring out the conflicts. Ask the stakeholders to outline what they feel the goals are or should be. Compare those two opposing sentiments, and then explain how elements of each contribute to the business goals. Facilitate this meeting to achieve a lasting compromise of the details necessary to achieve the higher goals.
5. Identify your key customers
Identify your key customers or customer segments. You will need to figure out how to involve your customers in the project and keep them involved over the lifetime of the project. Put together plans to get customers to your sprint reviews, set up A/B testing strategies, or conduct user testing. Getting and keeping your customers and potential customers engaged will be a large factor in the projects success.
The Scrummaster and Product Manager will need a comprehensive plan to involve your customers. Some ideas could be:
- Create a project/product blog where status information can be radiated
- Get out of the building and meet potential customers at lunch. Show them your evolving product or website and gather their feedback.
- Invite customers to your sprint reviews.
- Conduct product reviews at a customer’s office if possible.
- Offer trial periods or beta products with opt-outs.
6. Create the measures for the project
The Scrummaster and Product Manager will need to know what success means for all stakeholders, customers, and other business entities including development. This is a project level definition of done and key tracking measures for each. This starts with the business goals and business requirements. A possible definition of done for a project could be:
- Business goal of “increase males aged 25-40 sales by 35%” has been achieved
- Customer feedback indicates the landing page is now appealing to both men and women shoppers
- Business goal of a “12% increase of revenue” has been achieved.
- Customer Net Promoter Score is above 73
- Project team engagement score maintains a 90% or greater score
The definition of done should be as specific as possible to goals and customer problems but should not be so specific that developers and innovation are stifled. Your company should be encouraged to keep to higher level goals and outcomes and trust the teams to achieve these goals in the best way possible.
Once the business has arrived at a definition of done, this does not change. Changing the definition of done for the project might become very tempting to management as the end date nears. It should not be impossible to change this, just very, very hard.
Using the definition of done for the project as a guide, begin creating specific measures to track progress. You can start with the business goals. Take each business goal is break these down to the constituent components. Each component needs to be weighed for importance and prioritized. This is accomplished with select key stakeholders, customers, developers and anyone else who can help. The reality will be that people will find components of a goal that aren’t really necessary to achieving the goal. It becomes import to segregate the “wants” from the “needs”. You can use MoSCoW as a prioritization technique.
The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. Source: Wikipedia
Any details may be revisited & revised during the Inception workshop. What you don’t want to redefine is the project’s definition of done unless business goals become obsolete.
As an example, the high level measure for converting the landing page might be “how often male customers aged 25-40 click through from the landing page.” However, you’ll also need to include measures of all your other customer segments to check that you’re not losing their business in the process.
Plan and conduct the inception workshop
At this point, the Scrummaster (or Agile Project Manager) and Product Manager should be ready to run the Inception workshop. Be prepared to inspect the findings and adapt as needed. The best planning is flexible and welcoming of new found information, even if it reverses your thinking.
See, 15 Steps to Agile Project Planning Success, for more on running an Inception workshop.
Planning is important for project success but planning can’t guarantee success. One advantage to Agile planning will be a certain looseness and openness that can allow plans to change as more is learned. The more ridged the plan the more likely you will be to follow it even when good sense tells you not to. The point of the above steps is not to guarantee success but to find failure points faster.
A good plan is about removing or mitigating risks. Following these steps can help reduce risk.