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…)

19452897313_0dd46dd8fa_k

While there is agreement that you should use DoD at scale, how to apply it is less clear.

The Definition of Done (DoD) is an important technique for increasing the operational effectiveness of team-level Agile. The DoD provides a team with a set of criteria that they can use to plan and bound their work. As Agile is scaled up to deliver larger, more integrated solutions the question that is often asked is whether the concept of the DoD can be applied. And if it is applied, does the application require another layer of done (more complexity)?

The answer to the first question is simple and straightforward. If the question is whether the Definition of Done technique can be used as Agile projects are scaled, then the answer is an unequivocal ‘yes’. In preparation for this essay I surveyed a few dozen practitioners and coaches on the topic to ensure that my use of the technique at scale wasn’t extraordinary. To a person, they all used the technique in some form. Mario Lucero, an Agile Coach in Chile, (interviewed on SPaMCAST 334) said it succinctly, “No, the use of Definition of Done doesn’t depend on how large is the project.”

While everyone agreed that the DoD makes sense in a scaled Agile environment, there is far less consensus on how to apply the technique. The divergence of opinion and practice centered on whether or not the teams working together continually integrated their code as part of their build management process. There are two different camps. The first camp typically finds themselves in organizations that integrated functions either as a final step in a sprint, performed integration as a separate function outside of development or as a separate hardening sprint. This camp generally feels that to apply the Definition of Done requires a separate DoD specifically for integration. This DoD would include requirements for integrating functions, testing integration and architectural requirements that span teams. The second camp of respondent finds themselves in environments where continuous integration is performed. In this scenario each respondent either added integration criteria in the team DoD or did nothing at all. The primary difference boiled down to whether the team members were responsible for making sure their code integrated with the overall system or whether someone else (real or perceived) was responsible.

In practice the way that DoD is practiced includes a bit of the infamous “it depends” magic. During our discussion on the topic, Luc Bourgault from Wolters Kluwer stated, “in a perfect world the definition should be same, but I think we should be accept differences when it makes sense.” Pradeep Chennavajhula, Senior Global VP at QAI, made three points:

  1. Principles/characteristics of Definition of done do not change by size of the project.
  2. However, the considerations and detail will be certainly impacted.
  3. This may however, create a perception that Definition of Done varies by size of project.

The Definition of Done is useful for all Agile work whether a single team or a large scaled effort. However, how you have organized your Agile effort will have more of a potential impact on your approach.

Heads up!

Heads up!

A Scum of Scrums (SoS) is a mechanism to coordinate a group of teams so that they act as a team of teams.  SoS is a powerful tool. As with any powerful tool, if you use it wrong, problems will ensue. Six problematic implementations, called anti-patterns, are fairly common. We’ll discuss three in part 1 and finish the rest in part 2. (more…)

Pick a direction?

Pick a direction?

A Scum of Scrums (SoS) is a mechanism that has been adopted to coordinate a group of teams so that they act as a team of teams.  Historically the concept of a SoS was not part of the original Scrum framework and is considered an add-on to the framework.  In other words a Scrum of Scrums is an optional technique that can be added to more canonical Scrum framework if useful however because the technique is optional the amount of guidance is patchy.  For example, when an organization adopts a SoS who should participate is often hotly debated.  The participation debate popped up after we published Scrum of Scrums, The Basics. I had a number of conversations with readers to discuss the topic. Consolidating the discussions suggest the type of membership the person supports depends on what they want to get from using the SoS. All of the readers felt that the SoS should always be focused on coordination however there can be two flavors; one focused on activities and the second on technical questions.

Coordination of Activities:  Those that believe the SoS is primarily a tool for coordinating team activities support the idea that Scrum Masters should be chosen for SoS membership.  The rationale put forward focuses on the idea that the Scrum Master is uniquely positioned to gather and communicate information related to the coordination of teams. Readers in this group view feel that since Scrum Masters interact with all team members as a facilitator rather than a technical leader they are better coordinators. The alternate view held by many Agilistas believe that Scrum Masters acting in this role violate Scrum principles and represent a prima facie reinstitution of the role of the project manager. Further the Agilista view suggests that when technical issues need to be dealt with in SoS meetings populated with Scrum Masters they can’t make decisions rather often need to act as a conduit between technical team members. When SoS become a conduit, a version of the classic telephone game, decision making effectiveness is reduced..

Technical Coordination:  Fred Brooks in his essay Tar Pit (foreshadowing the next installment of Re-Read Saturday) suggests that software development increases in complexity as it progresses past development of an individual program. Integrating work with the work of other requires sharing technical information and making technical decisions that often can impact more than a single person or team. Scrum of scrums that are being used for technical coordination require participants with relevant technical acumen.  Participants with technical acumen generally come from the technical part of the team (developers, architects or testers).

Pushing aside the noise of whether the coordination of activities is less Agile than using the SoS for technical coordination, a more pragmatic approach is to recognize the needs of the team of teams is context driven.  The type of decision the team of team needs to make will change across a sprint or a SAFe Program Increment therefore who should attend a SoS needs to vary. The downside to varying membership is ensuring the right people are in attendance to address the SoS’s current need. One solution I have observed is to develop a cadence for topics.  For example tackle coordination every fourth SoS gathering with other more technical topics being focused on in-between.  Predictability makes it easy to plan who should attend.  Regardless of approach I suggest that any SoS should agree upon a mechanism to decide on the type of to hold. Flexibility to identify the type of SoS will ensure the team does not fall prey to meeting schedule paralysis or the equally evil telephone game.