5 Levels of Agile Planning


Within Agile, planning is done continuously. Planning is about working out what to do, and that must come before working out how long it will take.

In this post I would like to present a process that will allow team members to understand the whole sequence of planning from vision to user story.

5 Levels of Agile Planning

Level 1, Vision:

Every product needs a vision, a destination postcard that will guide the team towards the goal. The vision also helps to have a keen eye for opportunities, to focus on value (to the user and business) and return on investment (ROI). Every decision is taken with the product vision in mind. This ensures clarity for the development team and increases the chances of success.

Level 2, Roadmap:

This is a long-term product strategic roadmap (from 3 to 6 months max), this can also be explained by de-composing the vision into phases in a logical order. The roadmap will help to see how the product would evolve.

Note that it does not usually make sense to make a plan based on user stories that go further out than three months. Beyond this point, use a road map based on story themes.

Level 3, Plan Releases:

If the roadmap gives the phases, the release plan de-composes each phase into sprints. These sprints are conditioned by the roadmap; market conditions the status of the product. The product backlog consists on more than only features, for example: technical requirements, bugs, defects, spikes, non-functional requirements that should be taken into account.

Backlog refinement is very important, this must be granular and well understood by the whole team.

Level 4, Sprint Planning:

During the sprint planning the team plan and agrees the prioritised product backlog stories they are confident they can complete during the sprint and help them to achieve the sprint goal.

Here are 3 basic steps to create a plan:

  1. Understand priorities: Start with the team a conversation about the user stories the product owner would like to get in the next iteration to release.
  2. Size the work: 
When the stories are understood, help the team work out what needs to be done to deliver the stories.
  3. Agree on the plan: 
Wrap the meeting up by getting agreement on what can realistically be delivered.

Level 5, User Story:

If the team members want to deliver valuable software, they need to go the extra mile to understand both user and business benefits, and user stories help them do that. User stories underpin all the work an Agile team does, they are the basis of plans, development and testing.

The whole point of user stories is to ask questions to better understand what users need and to find ways of breaking requirements down. Break the tasks into smaller pieces so that everyone has a deliverable every day.

User stories are a simple technique that a team can use for understanding their customer through talking about what users need.

The main point is that Vision must drive decisions and User Stories are the means to achieve that vision.

Scaling Up and Rolling Out Change


Kaiser Permanent (KP) is the largest integrated healthcare system in United States, the facts as of 2014 are over 10 million members, 177,000 employees and with annual reporting revenue of $56.4 billion.

doctors

KP undertook few years ago a scaling journey to develop and implement electronic health record systems with the goal to make life better for patients and employees.

KP suffered a string of failed attempts to develop. The turning point came when its leaders realised that to scale up the record systems to all KP hospitals  needed to do things very differently.

Before the scaling effort, KP had endured a decade of failed efforts to implement electronic health records.

Between 2004 and 2010, KP scaled up KP HeatlhConnect. The scale up journey started by first being implemented in one of the smallest regions, Hawaii between 2004 and 2006, then rolled out the largest region, Southern California in 2008 and it deployed to LIVE in every region by 2010.

The leader of this initiative was Dr. Louise Liang and their team took a different approach to make this a success. They understood that the biggest obstacles to spreading the mindset across KP and rolling out the system was that hospitals operated under a paradigm of siloed regions with a weak relationship to shred functions. To succeed, KP required a lot more collaboration among regions.

However, understanding the history and culture of the local autonomy, the delivery team couldn’t insist that the exact same system be implemented in the exact way in each region, the team had to balance 3 constraints: commitment, creativity and customisation.

KP HealthConnect required local leaders to learn from and imitate other regions; Hawaii’s early success created challenges because, in the past, large regions like Southern California dictate and set the tone for changes across the entire organisation.

Starting in Hawaii was a great option, they were hungry for change, serve a smaller patience and medical audience and took less time; when the rollout was complete, initial fears and resistance vanished, and local doctors, nurses and patients reported that the system was making their lives easier.

Another reason why Hawaii succeeded was that in contrast to many other KP failures in the past, they didn’t implemented alone. The delivery team along with leaders from all other regions travelled to Hawaii to observe and help out, providing lessons and hands-on experience that guided and accelerated the roll out process.

The delivery team master a balance between standardisation and customisation, by specifying few critical constrains “non negotiables” for each region, this helped to ensure that each roll out was efficient, regions could learn from each other experience and users could learn faster to use a common system.

The non-negotaibles:

  1. the name: KP HealthConnect this reinforced the “one” solution mantra across all regions
  2. interoperability: no modifications could be made to the system that reduced the KP’s ability to maintain a single and integrated system, any software developed as a result of a customisation by a region, hospital or function had to work well with the rest of the system
  3. common data mode:  every local system had to use uniform data and definitions. This enable each region to generate consistent and comparable data so performance differences could be identified, problems spotted, improvements made and comprehensible reports generated.
  4. configuration no customisation: when Dr. Liang took charge, more than 300 contractor were working on customisations, this increased risk and maintenance costs. The delivery team understanding the need to provide fit to purpose solutions, allowed regions to select their own configuration, but they say no to programs that were built or designed differently from the system.

The operational model was also different, for instance when a new region went LIVE, teams from other regions that had already completed the implementation and deployment were “on loan” ready to support, guide and learn.

The learning in this case is:

Risk goes down and efficiency goes up when leaders and team complete a template that they can see and touch. It’s easier, faster and cheaper to imitate solutions that work elsewhere rather than to invent something from scratch every time.

Read more: Hayagreeva Rao and Robert I. Sutton. “Scaling up Excellence“. Random House Business.

Better Performing IT Results in Better Business Value


IT performance and well-know DevOps practices, such as those that enable continuous delivery, are predictive of organisational and business performance.

DevOps

How IT performance is measured? the most used criteria is measured in terms of throughput and stability. The individual measures that make up IT performance are:

  1. Deployment frequency
  2. Lead time for changes
  3. Mean time to recover from failure

Bear in mind DevOps has always been about culture, not just about tools and processes. Healthy cultural practices and norms that characterise high-trust organisations are required for the successful implementation of agile methodologies, these are: good information flow, cross-functional collaboration, shared responsibilities, learning from failures and encouragement of new ideas.

Practices Leading to Increased Deployment Frequency

  1. Continuous delivery ensures that your software is always in a releasable state that can be performed on demand.
  2. Capability for easily recreate environments for testing and troubleshooting.

Practices Leading to Reduced Lead Time for Changes

  1. Version control as the ability to get changes into production repeatedly in a reliable, low risk way.
  2. Reliable and comprehensive set of automated tests, so code is releasable without lengthy integration and manual regression testing cycles.

Practices Better Mean Time to Recover

  1. Version control, when an error is identified in production, devs can quickly either redeploy the last good state or fix the problem and roll forward.
  2. Monitoring system and application health so is easy to detect failures and identify the events that contributed to them.

Implementing continuous delivery means creating multiple feedback loops to ensure that high-quality software gets delivered to users more quickly. Continuous delivery requires that developers, testers, designers and UX, product and operations people collaborate effectively throughout the delivery process.

Continuous integration is a development practice whereby developers routinely merge their code into build servers with version control systems. Each change triggers a set of quick tests to discover serious regression, which developers must fix immediately.

Six Recommendations to Apply when working with DevOps:

  1. work with other teams and build empathy, build bridges, understand challenges and put yourself in the shoes of the others
  2. build trust between teams, trust is built on kept promises, open communication, and behaving predictably even in stressful situations
  3. actively seek, encourage and reward work that facilitates collaboration, make sure success is reproducible
  4. learn by sharing knowledge & create opportunities and spaces to share information
  5. create a training budget, and advocate for it internally
  6. make it safe to fail

Read more: Puppet Labs. “2014 State of DevOps Report“. PDF report.

What is Digital Disruption and How Companies can Embrace it?


Today the only source of competitive advantage and value delivering comes from seeing what customers need and delivering it.

Digital disruptors are changing complete industries, delivering value at a lower costs, with faster development times and with greater impact on customer experience.

Digital disruption

Digital disruption is simply a mindset that leads to a way of behaving; a mindset that bypasses traditional off-line obstacles, eliminating the gaps and boundaries that prevent people and companies from giving customers what they need in the moment that they want it.

Digital disruptors are obsessed with measuring results and rapid innovation cycles in which failure and mistakes are viewed as feedback.

Always evaluate your customer, benefits, business and product

  1. Customer: isolate the core target customers and make some smart guesses about what makes them tick. Ask yourself what your target customer really needs
  2. Benefits: what is the next thing that customer needs?, express the need in terms of what the customer will get out of the deal if you succeed.
  3. Business: what will we get out of it if we innovate?
  4. Product: the art of harmonising Customer, Benefits, Business and Product into a single approach

In other words, you need to focus on creating innovations that are most likely to give the consumers you want to reach the benefits they really desire while achieving strategic outcomes that are meaningful to the organisation.

How to deal with digital disruption inside a large company?

  • Create small innovation teams
  • Identify silos and break down the boundaries between them
  • Get senior executives to commit their support
  • Insist on short development time frames

Digital disruptors constantly seek for the adjacent possible:

  • Asking a simple question “what is the next thing my customer needs?
  • Iterating so quickly from one adjacent to the next
  • Giving the customer the next logical thing, or things

Digital disruptors keep the scope of their innovations small. Rather than creating a five-year innovation plan, digital disruptors proceed from adjacent possibility to adjacent possibility, occasionally failing, but failing so quickly and so cheaply that recovery can be nearly immediate.

Read more: James McQuivey. “Digital Disruption: Unleashing the Next Wave of Innovation“. Amazon Publishing.

Program Management Governance in Few Words


The first thing the program must do is establish program governance by planning how it will monitor and control the constituent projects.

Program Governance

Effective governance ensures strategic alignment, the realisation of promised service and benefits, stakeholders are communicated with and kept aware of progress and issues; appropriate tools and processes are used in the program; decisions are made rationally and with justification; and the responsibilities and accountabilities are clearly defined and applied. All of this is done within the policies and standards of the partner organisations and is measured to ensure compliance. Program Governance is intended to provide:

  1. A framework for efficient and effective decision-making
  2. Consistent delivery management with a focus on achieving program goals
  3. An appropriate mechanism to address risks and stakeholder requirements

Governance is about structured decision-making on investments in projects as has been summarised as the four areas:

  1. Are we doing the right projects?
  2. Are we doing them the right way?
  3. Are we getting them done well?
  4. Are we getting the benefits?

What criteria to use to select the right programs?

There are 5 selection criteria for organisations to evaluate what programs to start, being the strategic fit and benefits analysis the most important ones.

  1. Strategic fit: how well the program fits with the business strategy of the organisation
  2. Benefits analysis: what the benefits to the business are and how they will be achieved
  3. Budget: the preliminary budget estimate for the program
  4. Resources: the human and other resources required for the program and their availability
  5. Risks: analysis of the potential risks to the program

What is a Program?


A program consists of a group of related projects and activities, managed in a coordinated way, in order to deliver outcomes and benefits related to the organisation’s strategic objectives that would not be available by managing each project individually.

Programs are the link between the business strategy and the individual projects that will implement the solutions required to deliver it.

Program Management

Programs usually span several years and therefore the scope, time and cost are likely to change during the life of a program.

Program management is not about managing the details of each individual project, but rather about managing the big picture, in order to achieve the strategic objectives and realise the benefits for which the program is designed.

Benefits of Program Management:

  1. Optimisation of human and other resources over multiple projects in the overall program
  2. Coordinated management and reduction of risks
  3. Consolidation and management of the benefits

Why a to create a Program?

  1. The program is too large to be treated as a project and the component projects are too interdependent to be treated as separate unrelated projects.
  1. To optimise the use of scarce resources by sharing them across several related projects in the program.
  1. To keep the projects aligned with strategic goals and benefits.

Phases of a Program

Program Definition: involves understanding the strategic value of the program, defining the program objectives, identifying the key stakeholders and decision makers, developing a high level business case for the program, obtaining approval for the program and appointing the program manager.

Benefits Delivery: represents the main ongoing program management activity and for each of the constituent projects this will entail planning, execution and benefits realisation. For the program as a whole it also involves managing the inter-project dependencies, risks and issues.

Program Closure: performs a controlled close down of the program, together with the shutdown of the program infrastructure and transition of benefits monitoring to an operational group.

What are the Responsibilities of a Project Manager?


As defined in What is a Project post; “the role of the project manager is to deliver the project on time, within budget and with the needs of the business fully met”.

Project Manager

8 Key Tasks of a Project Manager

  1. Clarify the Objectives: it is very important for the project success to have clear objectives, the project will be judge on how well these objectives are delivered
  2. Develop the Plan: this is a route that will help the team to achieve the project objective
  3. Manage and Motivate the Team: making sure all team members know what needs to be done, by whom and in what order; motivation plays an important part as the team spirit must be positive and focus on the task
  4. Manage the Risks: every project has risks, the longer the project the more risks. These can be related to resources, technology, changes in scope, competitive moves, etc.
  5. Deal with Problems: the faster a problem is managed the less riskier it becomes; the majority of problems have simple solutions but if the project manager takes time to detect these or act on it then problems can become major risks
  6. Measure Progress: the only way to know if progress is going as planned, is to know the difference between forecast and actuals; this can be done by measuring scope completion vs timeline, actual cost vs budgeted
  7. Communicate: one of the most important skills for any project manager is communication. The only way to tell whether a communication has worked is by what the recipients do as a result
  8. Steer the Project to Completion: is the responsibility of the project manager to guide the team members through the project completion and deliver the objectives stablished by the organisation

Management Skills of a Project Manager:

  1. Leadership style: they tend to focus on getting team focus on completing their allocated work
  2. Management style: they are team players who need to use their skills and knowledge to motivate the team
  3. People management: they usually have no direct authority over the team and need to use influencing skills
  4. How are they measured: by whether the project is completed on time, to budget and to scope

What is a Project?


A project can be described as a temporary organisation that will focus on the:

  1. creation of a group of business deliverables as defined by the project scope
  2. within an agreed time frame (usually of a year or less)
  3. within cost budget and quality parameters

A project is the implementation of a change, with a beginning, middle and an end. It will also have a finite time frame, it will be unique (every project is different in some way), people are involved and it will usually have finite resources.

project-management

There is a direct correlation between the size of a project and its risk of failure. The duration of a project should be preferably of no more than one year.

A project its justified by its business case and will deliver some form of new product, service, system or business process.

3 Characteristics of a Project:

  1. it must have a goal
  2. it must be initiated, as projects do not usually happen spontaneously
  3. it needs someone (project manager) to run it and steer it through to achievement of the goal

Every Project Should:

  1. have documented objectives (which have been agreed by management) and adequate resources allocated to carry out the project
  2. be managed by a project manager
  3. defined project life cycle and outline project plan
  4. any changes to project objectives or requirements (scope) should have been recognised and documented
  5. be reviewed by senior management on a periodic basis
  6. submit regular progress reports, with some measure of their planned and actual performance on budget and timescale

The role of the project manager is to deliver the project on time, within budget and with the needs of the business fully met.

In Agile, What to do if Team Velocity is not as you Planned?


If after three or four sprints you notice your velocity is not where you had hoped it would be, do not panic. This might happen, this is why you need to set expectations accordingly and told your client not to trust your initial plans. The good news is that by the time you know about it, you can adjust course as necessary.

Team velocity

Being flexible about scope is the preferred method for restoring balance.

The important thing is to have the conversation and give your client some options. Yes, this may make you uncomfortable, but you can’t hide this stuff. Bad news early is the agile way.

There is one strategy for ensuring that when you do have the “too much to do, not enough time” conversation:

If you can’t deliver a minimalist version of the application with the time and resources you have got, then the plan is clearly wrong and needs to change.

It works like this:

  1. take one or two really important features for your project (something core that goes from end to end through your entire architecture) and
  2. measure how long it takes to build a minimalistic version of those features

Then use that against your remaining relatively sized stories to see whether a minimalistic version of the application is even possible with the time and resources you have.

If your dates are looking good, right on, if your dates are looking bad, great, at least you know about it now.

When you need to change the plan conversation from, It is not based on wishful thinking. There is no need to get emotional, it is just the facts. It is better to know this now than later.

In Agile, How to Handle New Client Requirements?


When your customer discovers what they really want in their project, ask them how they would like to handle it. You can push out the release date or add more resources (which is like saying we are going to need more money), or you can drop some of the less important stories from the to-do list (preferred).

Managing change requests

Don’t get emotional when you have this conversation. It is not your call to make. You are simply communicating.

Your responsibility is to:

  1. make them aware of the impact of their decisions and
  2. give them the information they need to make an informed decision.

If your client really wants it all, create a nice-to-have list and tell them that if there is time at the end of the project, these are the first stories you will do.

But make it clear, the nice-to-haves are currently off the table and are not going to be part of the core plan.