Agile Release Planning - Aligning with Executive Management

Executive Summary:

For longer-term technology projects, a quarterly planning Kanban board will not only help with release planning, but is also a great way to align program management with executive management on releases, resource capacity planning, costing, and ongoing project status reporting.

Quarterly Planning Kanban Board. 

In a previous article, I discussed methods to break down your product epics and features that were understandable to both executive management and product stakeholders, along with how to use the SAFe weighted shortest job first (WSJF) method to prioritize these features. In this article, I'd like to discuss a clear and simple way to present your agile release plans to executive management.

As part of agile release planning, you will need to identify epics and features that will be implemented over longer periods of time.  It's said that a picture is worth a thousand words, but with the advent of many new agile tools,  too many pictures can sometimes be overwhelming and information can get buried, especially when trying to communicate plans to executive management. This often results in miscommunications and many long unnecessary status meetings. As a program and/or product manager, it's critical you find a communication approach for both you, your teams, and more importantly, you executive management, that clearly, and accurately, depicts your initiative's plan and status.

Let’s look at the previous initiative example I presented for integrating a cloud-based HR system into your existing environment to replace a legacy HR system.

A simplified set of phases of the project identified were as follows:

Integrate new cloud-based HR System

·                  Environment Setup

·                  Integrate vended application with existing legacy systems

·                  Migrate existing employee & contractor data into vended application

These phases are what I would call super-epics.

After further analysis we came up with the following sub-epics and features for the Integrate phase:

Here is an example of expanding the Employee Update epics within the Integrate phase into features.

(Super) Epic	Sub Epic	Feature	Team A	Team B	Team C	Vendor A
. . .
HR Cloud Integration	Employee Update	HR Cloud Core Data Update		X		X
HR Cloud Integration	Employee Update	Facilities Location Update	X	X		X
HR Cloud Integration	Employee Update	Telecom Update			X	X
. . .

Example Epic and Feature Analysis by Team.

Note that we are expressing our epics and features from a business standpoint and not from a technical standpoint. We know which systems are impacted by identifying which teams need to be involved to execute specific features.  So Team A might represent the Facilities system, Team B might represent the new HR system, Team C might represent the Telecom system, and Vendor A might represent the HR System's vendor.

If these were architectural epics, of course we would reference specific tools, systems etc., because from an enterprise architecture standpoint, these systems, tools, and middleware are their business. Make sense?

• From executive management’s standpoint, they are primarily interested in when the main project phases (super-epics) will be completed and how much it’s going to cost them.

• From a program manager’s standpoint, they are primarily interested in when the epics (super-epics and sub-epics) will be completed and are they on or over budget. 

Note that you can call these levels whatever you want, but the point is that what management likes to see is generally at a much higher level than what execution/implementation teams like to see, and that you just need to be conscious of this. Some tools like Jira Portfolio can help you align these differences.

Here's another way to think about it.

Keeping in-line with Dean Leffingwell’s scaled agile framework (SAFe) concepts of implementing interconnected Kanban and SCRUM boards to manage a company’s portfolio initiatives, programs, and associated projects, we get this hierarchy of epics, features and user stories where epics represent executive strategy, features represent program management, and stories represent the tactical execution of programs.

Image Source: adapted from http://versionone.com Enterprise Agile presentation. 

 To help align both program/product management and executive management for longer-term planning, and to ease management into concepts of lean and agile such as Kanban boards, epics, and features, I recommend starting off with a Kanban board based on quarters. 

Here’s the basic approach.

At its simplest, each column on the Kanban board represents one quarter and an epic is placed in the quarter that it is scheduled to be completed.  Within each epic you can include the features that are planned to be released within that epic. It’s up to you to define your definition of done for each item on the board, and everyone should be very clear about what this means. i.e. is it just user acceptance tested, or does it mean it’s been rolled out to the field.

You can include as many quarters as you want, but I’d recommend making no more than 6 – 8 quarters at a time. You can reuse previous quarters on the board about every 6 – 9 months.  This view shows only the current year, but you can include quarters from the previous year and next year as well.

Quarterly Planning Kanban Board. 

I encourage program management to maintain this as a physical board in a place where executive management will see it as well as the entire team.  For remote teams, you can also maintain this in tools like Jira and VersionOne, but just be sure that you incorporate a process to ensure this has constant visibility.

Note that an epic may appear in multiple quarters because features within an epic will likely be incorporated into different releases. You can further refine this board by using color post-its or indicators on the post-it, to indicate whether something is on-schedule, delayed, or has a major blocker, and/or you might consider adding traditional "To-Do", "In-Process", and "Done" Kanban columns within each quarter.

Additionally, horizontal columns can be used to indicate which team is primarily responsible for which feature. You might even indicate specific release trains on the timeline as well.

Quarterly Planning Kanban Board with Team Columns. 

And yes, it's not that much different than a traditional calendar, but it's familiarity and bridge into agile concepts is it's key benefit, not to mention it can easily be incorporated as a Kanban board in just about any agile tool.

Another valuable dimension that can be represented here are the points and/or hours for each feature as well as the total points or hours for the quarter and for each team over a period of time. This allows you to plan and identify team commitments, constraints, and availability, along with a rough idea of both team and quarterly estimated costs. After a quarter has completed, you might even show planned versus actual hours to help with the next period of planning.

Quarterly Planning Kanban Board with team and quarterly hourly totals.

Deciding what to include and how to manage the quarterly Kanban board is something that will evolve over time and will be determined by your project and organizational needs.

If you focus on information that maximizes the value provided to your management teams and minimizes the effort to manage the board itself and you will find that implementing a big visible quarterly Kanban board will help bridge the gap between executive management and program management and help reduce unnecessary project status meetings saving everyone's time.

I would greatly welcome your feedback and experiences regarding agile release planning and management.

Blog header Image Source: theflowcentre.com

Waterfall Development is Not a Bad Word - or When to use Waterfall in an Agile Environment.

Over the past decade, agile software development has grown exponentially across all types of organizations and industries. During this time period, having been involved in several small and large scale agile and waterfall projects involving custom development as well as third party implementations, I found that there are some cases when the traditional waterfall methodology of requirements analysis, design, build and test, is a better choice over an agile methodology like SCRUM or XP.

Implementation with a waterfall methodology doesn't necessarily mean we throw out our agile mindset (now might be a good time to refresh yourself with the agile manifesto), rather it means we still embrace these things by choosing the right development approach, based on the particular job and team.

WATERFALL DEVELOPMENT

AGILE DEVELOPMENT - SCRUM  

So, when is the best time to implement something using a waterfall methodology?

A core approach within agile methodologies like Scrum and XP, is to break effort down into small work iterations, or sprints. These sprints can range anywhere from a few days to a month, but commonly are implemented in 2 week iterations.  The purpose of iterations, is to deal with the ever changing environment and conditions that happen over the course of a project. This enables us to reassess user requirements frequently, preventing situations where a change in our environment resulted in a substantial change to our requirements after spending  months on a design.  But what if there wasn't much change happening?  What, no change?!

One of the primary examples of something that tends not to change, is when the product being implemented is something of a known quantity. This usually occurs in package applications or applications within an organization that have been implemented over and over again with regularity.

Generally in the case of locally installed package or cloud applications, the vendor tends to do some initial planning & analysis with the client to determine the core configuration of the product and it’s necessary infrastructure, and can tell the client how long the implementation & testing should take. In many cases, the vendor can even provide test cases along with test data to validate everything is working.  In cases like these, the teams that implement these kinds of products, generally should not have a need to create a backlog of user stories have daily scrum meetings, and plan things in development iterations as this would likely generate a lot of waste.

In cases where a product may need some significant customization and/or integration, cases where there are a lot of UNKNOWNS, an agile methodology tends to works best, but in cases where the vendor or internal team, has implemented them over and over, most of the variables needed to install or configure a product are well known a simple waterfall methodology should be acceptable. 

In these situations, consider following the vendor’s methodology or internal team's methodology, versus trying to squeeze in an agile methodology you normally use for custom development.

This doesn't mean your infrastructure or architecture teams should only use one methodology, what it means is that you need to match the approach to the job. So it might be possible that in one instance, a team uses scrum or Kanban, and in another uses waterfall.  The key is to determine what's best for the team so that the product can be delivered in minimal time with the most value to the organization.  For example, it's fairly common that large package implementations go awry, but this is primarily the result of treating the core package (known) and customizations AND integrations(unknown) the same. If we implement and test the package's core functionality first using standard waterfall and then treat the customizations and integrations with an agile methodology (stories, backlogs, iterations, etc.), we get the best of both worlds.

Remember, the first tenant of the agile manifesto is: Individuals and interactions over processes and tools. Don't get hung up on the need to apply an agile methodology to everything, apply an agile mindset to everything.

It would be great to hear about your experiences, success and not so successes too.