Skip to main content

Agile Chartering – Beginning with the End in Mind

What is Chartering?

In a traditional project management sense, it’s a Process and Artifacts that:

• Establishes the vision state for the projectGalen FeatureArticle Jan30
• Defines key goals and requirements
• Captures and sets customer expectations
• Defines project participants and their roles
• Defines limits and constraints
• Establishes all resource needs and overall cost targets
• Creates a high level view to the WBS and schedule
• Initiates negotiation and tradeoffs
• Ultimately defines success

Another view…

A charter is a central document or a set of supporting documents that defines the purpose, nature and characteristics of an about to be undertaken software project.

It is typically constructed early in the project lifecycle, hopefully before the project is staffed and the business is pushing for a delivery date. It is usually created collaboratively as a team and shared with stakeholders upon completion.

It is intended to clearly set the stage for the project—aligning the team and stakeholders by setting goals and expectations.

It’s often the case that a charter leads to an early project approval ‘gate’ as part of an organizational project approval life-cycle phase. Usually the keys to the approval involve cost, schedule, and scope definitions and restrictions—so very much of a contractual view.

Components of an Effective Project Charter

Galen img2 Jan30Notion of Agile Chartering

Now let’s move on from traditional chartering views to agile chartering. The essence is the same, to establish a baseline understanding and connection between the team and stakeholders. However, the dynamics and artifacts are often quite different.

First, it’s not contractual in nature; resisting fixing cost, time, and scope. An agile charter clearly realizes that scope is the variable within agile projects and that team’s converge towards their customers’ needs and project goals. There’s also the implication that business stakeholders are engaged along the way in decision-making surrounding requisite trade-offs.

The key chartering activities, from an agile perspective, revolve around the following:

  1. Establishing a view to Vision & Mission
  2. Establishing a view towards a Minimum Viable Product (MVP) or Minimal Marketable Product (MMP)
  3. Running Sprint #0’s as needed; when your project and/or your team needs “directional alignment”
  4. Establishing effective release plans that align the Product Backlog with the Mission & Vision or Goals and with the team

I’m going to assume that everyone is comfortable with the notions of mission and vision setting within projects, so we won’t explore those here. I’ve written a sister-article in BA Times on MMF/MMP definition and I’m deferring release planning for a future set of articles. Here I’d like to explore the nuance of Iteration or Sprint #0’s.

Chartering via Sprint #0

In his book on Agile Project Management , Jim Highsmith introduced the concept of running an Iteration #0.The same notion has been referenced within Scrum as a Sprint #0.

It’s somewhat of a debated practice in the Scrum community. Some think that for all project work, you should “dive into” your first sprint and immediately begin delivering customer value. If that’s truly possible, then I couldn’t agree more. By customer value, I’m assuming we mean feature value. In that case, you must have a clear backlog, a team formed and equipped, and a clear charter. So, why not dive in and start sprinting? 

But what if things aren’t so clear? 

What if you have a new, never-been-together before team? Or, have moved members together into a new space and need to setup equipment? Or, they are embarking on a new project with no backlog requirements or context? Or, you are being told to use a highly distributed team to get the work done? Or, your team doesn’t have much Scrum experience among them, and you’ve just hired a brand new Scrum Master? Or, the list goes on…

I can think of many contexts where beginning a sprint without sufficient definition can lead to nothing productive or even agile. It’s just moving without a direction in mind, which can lead to chaos and churn.

In these cases, wouldn’t it be useful to take a sprint, or even two, to figure things out? At least, to get enough definition and clarity so you can begin to sprint effectively; getting your feet underneath you? Well, that’s exactly the point behind a Sprint #0.

You’ll want it to behave with as closely to the same dynamics as a normal, development-driven Sprint; the primary compromise usually being on delivering working software in the end. You might even want to keep the sprint shorter to keep it more focused, and not run the risk of it turning into a crutch for waterfall analysis paralysis. 

Typical activities that I’ve seen within a Sprint #0 include:

  • Chartering; and connecting it to your stakeholders.
  • Defining your high-level architecture or connections to a pre-existing Enterprise level or other architectures.
  • Do a bit of prototyping; perhaps paper at first.
  • Running story writing workshop(s) and other meetings / activities to establish your initial Product Backlog.
  • Running backlog grooming meeting(s) to provide initial PBI estimates and perform release planning.
  • Forming your team: introductions, establishing roles, assessing skills, etc.
  • Establishing a working environment for your team: Scrum room, cubes, workstations, development and test tool servers, connections to existing tools, etc.
  • Running various training sessions for your team; both technical, Scrum, and team related.
  • Perhaps conducting a project kick-off of sorts.
  • Planning for, then kicking off your first sprint; then off you go…

One of the dangers associated with the Sprint #0, and I’ve already alluded to it, is that teams who are uncomfortable with ambiguity, can begin using it as an excuse for analysis paralysis. They may even want the false comfort of too much early definition. Therefore, you’ll want to be careful that you schedule them when they are truly needed, and only continue them as long as that strong need exists. 

For example, I’ve never seen a large-scale or Enterprise level project that needed more than 2 – 2-week Sprint #0’s to get their feet underneath them before actively sprinting. 

Re-running Your Sprint #0

I view a Sprint #0 as the “iterative wrapper” for chartering. You typically think of it as occurring at the beginning of a project, but that’s not the only appropriate time. Many agile teams get into a state of what I refer to as “directional confusion” in alignment towards feasibly meeting their goals. Re-chartering can help those teams realign themselves with their business stakeholders.

Another factor influencing this is design ambiguity. Agile teams attempt to balance architecture and design allowing them to emerge as teams iterate their solutions. But that shouldn’t imply there isn’t in-advance design and architectural activity within a release sequence. When a team runs out of their design runway and starts to realize more and more rework, it might be time to run another Sprint #0 to gain some design look-ahead or runway for subsequent sprints.

Point being; don’t be reluctant to re-run a Sprint #0 when you find the teams encountering too much ambiguity or churn in their direction. It might only take a day or two, to regain your directional certainty and then continue with your adjusted release plans.

Wrapping Up

There’s nothing wrong with: Beginning with the End in Mind as Steven Covey would say…

Way too many teams “dive into” their agile projects before they know where they’re going. I guess it’s a danger inherent in the methods. You’ll want to be wary of that trap and, if you sense that sprinting might be premature because you’re not ‘ready’, then plan a Sprint #0 to get yourself ready. 

There’s a wonderful book that’s new to the market called Liftoff that is focused on agile chartering. If you like the focus of this article, then I’d highly recommend reading Liftoff!

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

Footnotes:

  • Agile Project Management is a wonderful book by Jim Highsmith that speaks to the general practices surrounding Agile PM without strong ties to any specific Agile Methodology. I’ve found his guidance surrounding Chartering, Agile Iterative Planning, and Iteration Types to be quite useful.
  • http://en.wikipedia.org/wiki/The_Seven_Habits_of_Highly_Effective_People
  • Liftoff – Launching Agile Teams & Projects was published in 2012 by Diana Larson and Ainsley Nies. In my opinion, it’s a wonderful book that compliments this article quite nicely.

Comments (34)