Where are we going?

Where are we going?

As we noted earlier in this theme, coordinating and synchronizing goals across multiple teams is not a new problem. Solving the problem at scale requires integrating specific steps into how work is being delivered.  Building coordination and synchronizing steps work best if they are part of activities that are naturally designed to consolidate and disseminate information, while also avoiding the construction-related steps. Identifying the steps to coordinate and synchronize goals is a first step in scaling Agile.  The size and complexity of the effort will contribute to the selection process.  For example, delivering functionality from two collocated teams will need less overt goal coordination than an effort with twenty teams spread across the globe.  Because adding coordination and synchronization steps into the workflow may feel like overhead to individual teams, care should be taken. However, well-executed coordination will provide a significant payback both for the team and to the overall effort. The Agile planning mechanisms that are excellent tools for coordinating and synchronizing goals include: (more…)

Greater scale, more problems?

Greater scale, more problems?

In 2016, scaling Agile is a contentious topic.  Frameworks and techniques for scaling are often lambasted as semi-Agile or perhaps even backdoor waterfall techniques. Occasionally you still hear that if a piece of work is too big for one team to complete in a reasonable period of time, it should be broken down or just not done. Rather than throw the baby out with the bathwater, many organizations have taken a more pragmatic approach and adopted techniques to scale Agile. These techniques reflect the differences between a single-team Agile project and a scaled project.  Careful observation can trace most of these perceptions back to a single difference. (more…)

little boy building a block tower

The bigger the project, the more complicated the role of the product owner gets.

The Product Owner (PO) role in organizations that are scaling up Agile projects requires not only nuances how the role is applied but also requires refocusing the typical activities in the role (however this does not mean that they don’t they get out of buying pizza or other relevant food occasional).  The primary responsibilities of a scaled product owner are: (more…)

ornate astronomical clock

The greater the scale, the more complex the connections.

The product owner plays a pivotal role in an Agile project. That role is more complex as Agile projects are scaled and applied to new scenarios. Exploring three classic project types that most software organizations have, is a useful approach to exposing the potential nuances in the role of the scaled product owner (PO). (more…)

Envision your climb to the top of the mountain.

Envision your climb to the top of the mountain.

Agile charters typically address topics that can be classified into four basic categories. Each category addresses different concepts that are important to help a team or a team-of-teams in a scaled effort to act in coordinated manner.  The four categories are:

  1. Envisioning Success
  2. Behavior
  3. Constraints
  4. Timing

There are any number of ways to address the concepts in each of the categories, and often a few teams and organizations use multiple components to address a specific concept.  For example, many organizations define success by stating mission, visions and success criteria.  How each team addresses a concept like envisioning success is driven by historical behavior patterns, such as the classic waterfall project charters of late last century. Summarized below are the most common components used to address the concept of envisioning success.  A quick definition is included for each component and a recommendation whether the component should be used for either a team or scaled Agile charter.  Yes means the component should typically be used, meh is an unenthusiastic maybe (biased towards fewer words) and no means don’t.

Envisioning Success

In an Agile charter, it is important to answer the question of why an effort is being done by outlining a common understanding of the project mission, vision and goal. Components often include:

  1. Mission is a statement of a goal or purpose of the effort. Project mission statements are a reflection of the purpose of the organization in terms of the business problem the effort is trying to solve.
    1. Scaled Charter Recommendation:  Meh – For an ongoing product level-organization, a specific mission statement might have value; however, since the overall mission is typically a reflection of the higher-level organization, a mission statement makes less sense for projects or teams.
    2. Team Charter Recommendation:  MehMost teams rarely refer to mission after they spend the time to craftthe statement
  2. Vision is a statement that describes a future state in which the business problem is solved. The vision provides direction to the participants in the effort by providing a goal for the team to progress toward.  The vision does not describe how the problem will be solved but rather a goal that the team or teams can rally around.
    1. Scaled Charter Recommendation:  Yes.
    2. Team Charter Recommendation:  Yes The vision provides team members with an understanding of how their product fits into the bigger deliverable.
  3. Elevator Speech is a crisp definition of the effort that everyone on the team can remember and share.
    1. Scaled Charter Recommendation:  Yes.
    2. Team Charter Recommendation:  Yes/No A vision can be used as a substitute for an elevator speech. Do one or the other at the team level.
  4. Product Box is a tool to help the team to develop a specific project metaphor that helps everyone involved translate the goal or vision into something that is more tangible. The product box is valuable for visual communicators.
    1. Scaled Charter Recommendation:  Yes.
    2. Team Charter Recommendation:  Yes.
  5. Success Criteria describe how success will be determined. Success criteria are the basis for measuring and testing, and is the core of the Agile definition of done for the project.
    1. Scaled Charter Recommendation:  Yes.
    2. Team Charter Recommendation:  Yes.
  6. Context provides pertinent information about the rationale, the technical and business environment for the effort. Context provides background to help the team or team of teams understand the other components in the Envisioning Success category.  Context often addresses why the participants in the effort are being asked to address this problem at this time.
    1. Scaled Charter Recommendation:  Yes.
    2. Team Charter Recommendation:  Yes.
  7. Proposed Solution specifies how the business problem will be solved.  The inclusion of the proposed solution harkens back to projects in which the analysis had been done before the project.  The vision and the product box are more directional and less constraining.  
    1. Scaled Charter Recommendation:  No.
    2. Team Charter Recommendation:  No.

Each component in ‘Envisioning Success’ addresses a different information need, depending on the framework an organization is using for development and their historical chartering process some components will be more or less useful.  Chartering for teams or scaled  approaches should be biased towards leaner charters so that teams can begin tackling the business problem sooner and generating feedback based on functional software rather than on the words in a charter.  

From the Princess Bride

A verbal charter? From Princess Bride (Best Movie Ever!)

Team charters are a way to ensure that a team is focused. The team charter works best when it is an anchor with a clear statement of the problem to be solved, a vision for the solution and a commitment to team norms. At the team level the charter can be a single piece of paper or a few flip charts. As efforts scale up to require multiple teams working together over multiple sprints and releases, things often drift back towards an omnibus charter so large that it rivals Stephen King novels. Cooler heads should prevail. Simple charters for scaled efforts (products or projects) still require only a few components.

All components of an Agile charter need to meet the three attributes we established for the components of a team charter. They should be:

  • Concise – Agile charters are time boxed and constrained. Examples of constraints that I have used include one typed page or four handwritten flip charts (my favorite). Time and size constraints force the teams to be very concise.
  • Organic – Whenever possible, use a flip chart and hand write the charter documents rather than PowerPoint (or the presentation software du jour). Flips charts and other organic mechanisms for completing the charter generate engagement, which increases the charters value to the team.
  • Understandable – Use language that the whole team can understand. Do not use legal mumbo jumbo. Reducing the amount of legal mumbo jumbo reduces the time spent on wordsmithing.

Based on my experience with scaled Agile projects and conversations with colleagues, readers of the blog and podcast listeners, we have identified four categories of components that make up a scaled Agile charter. Each category answers core questions about the effort that everyone needs to understand AND remember.

  1. Envisioning Success: Components in this category answer the question of why an effort is being done by providing an understanding of what needs to be accomplished. The components that help those involved in the project to envision success are a common understanding of the project mission, vision and goal.
  2. Defining Behavior: Explicitly identifying and agreeing on a set of expectations for how groups will behave and interact will reduce the potential for conflict while promoting positive behavior.
  3. Identifying Constraints: Components in this category identify resources, tools, people, money and other assets available to the effort and the boundaries on the use of these items. The definition of assets and the limitations of those assets are inextricably linked. One of my favorite movies of all times is the Princess Bride. One of the great dialogs in the movies revolves around the constraints the three heroes are facing just before they storm the castle to rescue Princess Buttercup. When they discover that the giant has the holocaust cloak, Wesley states, “Why didn’t you list that among our assets in the first place?Understanding the true constraints a team faces makes planning and delivering easier!
  4. Timing Data: Timing components provide everyone with an understanding of the planned release schedule and strategy, sprint cadence, common event timing and any outside date constraints. Timing could be considered a type of constraint; however, it is important to call timing information out separately so that it can’t be overlooked.

A scaled Agile charter is as important as a team charter. But, importance should not be measured by file size or a page count. Nor should a charter, because it is construed to be important, be dictated to the teams involved in an Agile effort. An Agile charter must be concise, organic and understandable in order to maximize the value of the charter.

We explore the types of information that might be useful in each section/component here, here and here.

Ready, Set, Go!

Ready, Set, Go!

At the beginning of most races the starter will say something like, “ready, set, go.” At the team-level the concept of ready to develop acts as a filter to determine whether a user story is ready to be passed to the team and taken into a sprint. Ready to develop is often considered as a bookend to the definition of done. As a comparison, the definition of done is applicable both at the team level and at scale when multiple teams are pursuing a common goal. In practice, ready does not scale as easily as done. Ready often requires two sets of unique criteria for scaled Agile projects, Ready to Develop and Ready to Go. (more…)