Avoid Failure to Launch: Kick/Start Your Next Initiative

Guest post from two Davisbase consultants:  Adam Mattis and Leslie Morse The Challenge It’s a great day:  you wake up, the sun is shining, there is no traffic on the way to work, and when you get to the office… there it is. A shiny, new, fully sanctioned project. It’s GO TIME! Easy there, killer. Before you dive in head first, let’s take a step back and get our proverbial ducks in a row. All too often with agile/run initiatives or projects, we skip the foundational efforts that set the team up for success. In business environments where teams are constantly challenged to do more, faster, and with less, these foundational efforts are often overlooked. However, this quick/to/launch mentality ends up costing us much more, further on down the line. What are these foundational efforts that we speak of? Let’s take a step back to bootcamp and remember the importance of:

• Product Vision
• Product Roadmap
• User Roles
• Initial Backlog Population
• The Architectural and UX Runway

Three Preconditions for Starting Work No one embarks on a new effort, initiative, project, or body of work with the intent to fail. However, agile development is often used as an excuse to make it up as you go along. Let’s frame up the goal of foundational work for agile workstreams by creating a user story.   1.  Business Readiness:  The degree to which business stakeholders are in alignment on what the vision is, who it is intended to benefit, and how much money should be investing in realizing the value. 2.  Architectural Readiness:  Ensuring that key IT stakeholders understand the vision and target scope for the effort as well as the definition of a high/level architectural approach to delivering value. 3.  Team Readiness:  Critical collaboration activities and workshops necessary to prepare the team for an incremental delivery cadence. BUSINESS READINESS The business defines the ‘what’ for an agile team; therefore, readiness on behalf of the business is of paramount importance before engaging the technology group. But what does business readiness look like? Business Case: Defining the Need The business case provides justification for funding a new initiative. Depending on your organization, this could be something as simple as an elevator pitch, or a much more detailed document outlining market opportunities, value propositions, return structures, etc. Regardless of the level of detailed that is needed, having a clearly documented business case helps build a shared understanding of value among executives, sponsors, and key stakeholders. Continued support from these individuals is as key to the product launch as is the technical solution.  See Figure 1 for an example of the Elevator Pitch Structure. FIGURE 1: Elevator Pitch Structure Product Vision With the business case crafted, the next task is to develop a cornerstone for the team to focus on. This cornerstone, or product vision, serves as the high/level focus from which every epic, every feature, and every user story is created. All work done by the agile team should be focused on satisfying the product vision. The vision should be comprised of the product name, a value statement, and a few key features that differentiate the product. The vision may also outline some basic technical requirements such as OS compatibility or platform such as “web/based.” FIGURE 2 – Design the Box   While it is important for the product owner and key stakeholders to understand and align on the vision when preparing to kick/start the initiative, keep in mind that it will be necessary to have a vision workshop with the cross/functional agile team in order to ensure a shared understanding of the product they are building. Once created, the product vision should be posted in a common team area to serve as an information radiator. The vision will help keep the team focused throughout the work cycle. Product Roadmap The product roadmap helps link the product vision to the work which agile teams do every day. The roadmap is not intended to be a commitment or project plan, but simply a guide that the agile team uses to plan their work during release planning sessions. Without a roadmap, teams are left without a clear strategic vision. It is a common misconception that agile teams do not strategize. The reality is that agile teams are highly strategic and nimble enough to shift focus with rapidly changing market conditions. FIGURE 3 – Product Roadmap   The roadmap focuses on high/level themes, epics, or features – and, like the backlog, remains fluid throughout the course of the initiative. To be effective, the artifact should be highly visible and referred to often. As market conditions and priorities change, so should the roadmap and other downstream artifacts. Again, aligning on the roadmap before engaging the agile team is critical in order to avoid swirl and confusion when getting the team started. It is important to ensure that business stakeholders understand that the roadmap will most certainly evolve as the team begins work. User Roles With the ‘what’ defined in the business case, product vision, and product roadmap, it is now time to consider the ‘who.’ The definition of user roles seems like a fairly straightforward task, but once the discussion begins, teams are often surprised at how difficult the task can be. Consider Facebook. On first thought it may seem simple: New User, Existing User, Administrator. Not so fast. Really think about all of the different interactions that take place on Facebook.

New User	Existing User	Business User	Group Administrator
Advertiser	Photo Poster	Marketplace User	Under 13

And that’s not even scratching the surface! Now consider any system within your organization and imagine how challenging it would be to identify all of the different paths and user types within the system. Consider the importance of evaluating the individual needs of each of these users in creating a solution. Remember, one of the key benefits of an agile culture is the delivery of high/quality, customer/focused software. If the team is not sure who they are solutioning for, it is likely that the product will not sufficiently satisfy the needs of anyone. Baseline User Stories & The Backlog With the product and users now defined, it is time to elicit basic needs from our business partners. Remember, the business product owner (BPO) is the tip/of/the/spear for all things business. The BPO serves as the single voice for the customer, product management, sales, marketing, legal, finance, and all of the other organizations that make up the business function. The BPO and supporting team need to elicit baseline user stories from each of these groups and place them on the backlog for prioritization. As the program progresses, the BPO will be accountable for making sure any inputs from the business team are ready for the agile  team at the appropriate time. A few examples of these items may include legally approved verbiage, approved graphics from the marketing team, and any special promotional offers from the sales team. The BPO, with full control over the prioritization of the backlog, must maintain awareness of upcoming user stories and their dependency of these inputs. ARCHITECTURAL READINESS Now that we understand the ‘what,’ it is time to engage the technology group! HOLD ON… let’s tap those brakes! You’re only partially right. With the ‘what’ defined, we still have not begun to explore the solution. To begin framing up the ‘how,’ we need to engage the solutions architect. Developing Shared Understanding The solutions architect is in a unique position to begin bridging the gap between business need and technology execution. This individual has a broad view of all technology groups, infrastructure types, and data locations. In bringing the architect in early, the business will be able to get an accurate gauge of the technical feasibility of their ask, as well as the level of effort involved to deliver. Identify IT Impacts Once the feasibility study is complete, the solutions architect will start to map out the solution. This sketch will include the identification of new infrastructure, data flow mapping, and systems impacts. With this analysis complete, leaders can determine the right skill sets and organizational units that need to be involved in forming the agile team(s) who will work on the initiative. TEAM READINESS Let’s assume you’ve followed a good plan for initiating this new body of work. Your product owner is firing on all cylinders, business stakeholders are in alignment and engaged, the architects have a vision for the solution needed to deliver value, and the cross/functional set of agile team members are locked and loaded.  Please, please, please // don’t make the assumption that those folks are clairvoyant and have a shared understanding of what the organization is looking to achieve! Agile teams need to practice the full Five Levels of Agile Planning [See Figure 4]. It doesn’t mean the product owner and business stakeholders do Levels 1/3 and the team only engages in Levels 4/5.  The entire agile team plus key stakeholders need to collaborate in order to prepare for the first sprint planning event. Highly effective agile teams engage in Levels 1/3 of planning during a timeboxed period often called Sprint Zero. When well/facilitated, it could take only a week, but spending more than four weeks on these activities would likely lead to analysis paralysis. Key preconditions, activities, and outcomes of Sprint Zero are outlined in Figure 5. FIGURE 4 – Five Levels of Agile Planning   FIGURE 5 – Sprint Zero Summary Start Small & Improve Incrementally Feeling overwhelmed?  If you’ve got a gap in your pre/planning processes or you’re currently feeling the pain associated with a lack of readiness in one of these three areas, consider one of these three techniques in order to improve. After that, make a backlog of all of the opportunities to improve your pre/planning processes, prioritize the list, and affect change incrementally over time. 1.  The Stakeholder Engagement Cadence Product owners are intended to be the single source of truth around ‘what’ the agile team needs to deliver. In order to effectively do this, product owners need to fully understand their stakeholders and proactively engage them so that priorities and acceptance criteria are the best quality possible.Figure 6 outlines a framework for a stakeholder engagement cadence where stakeholders are classified into one of three groupings (Advisors, Supporters, or Sponsors) and then, based on the classification, are brought together once a month, twice a month, or weekly, based on their level of involvement in the workstream. To learn more about this technique, check out Proactive Stakeholder Engagement, a post on Davisbase’s #BecomingAgile blog. FIGURE 6 – Stakeholder Engagement Cadence   2.  The Backlog Refinement Cadence It is essential that teams keep a product backlog deep enough to sustain incremental delivery. While pure Scrum doesn’t call for teams maintaining a runway of “ready” stories or a projection of the backlog items they will be completing in which sprint, in practice – it is a useful planning approach for keeping flow within the system and aligning the dependencies and coordination points that often exist within organizations of scale and complexity. Figure 7 outlines a backlog refinement approach that creates focus for agile teams and helps build the discipline to keep one sprint’s worth of stories in a “ready” state, as well as get the details and specifications just enough in advance of the sprint where they will commit to the work.  When paired with the Stakeholder Engagement Cadence, this information radiator can also be useful for creating context on topics for collaboration. To learn more about the cadence for backlog refinement, check out the #BecomingAgile Webinar recording Strategies for Grooming Your Backlog. FIGURE 7 – Refinement Cadence   3.  The Architectural Feedback Loop In a similar manner to how feedback is generated often in software demonstrations, it is equally as important for feedback to be passed on the to architect. On an agile team, the solutions architect is working six to eight weeks ahead of the development team laying down the architectural runway. If the development team finds that some elements of the architecture are either missing or not working, it is important to pass that information along to the architect on a regular basis in order to correct the issues in upcoming iterations. As a result of this feedback loop, many technical and architectural user stories will begin to appear on the backlog. These elements can appear either on a product backlog in the case of tactical changes, or as the Scaled Agile Framework® (SAFe™) tells us, enterprise changes may appear on the program backlog. FIGURE 8 – Architectural Epics

    Please comment on this post and keep the conversation going. We’re constantly looking for better ways of doing things and get excited by helping others with #BecomingAgile. Learn more by checking out these additional resources:

• Scrum Process Overview & Guide to the Five Levels of Planning
• The #BecomingAgile Webinar Series Archive (each worth 1 PDU)
• An Online Agile Glossary of Key Terms & Definitions

About the Authors Adam Mattis and Leslie Morse are colleagues at Davisbase Consulting and, combined, have over 29 years of experience delivering value with software and information systems. Adam is a program manager by trade residing in Nashville, TN. He spends most of his time working with new teams adopting agile practices. You can reach him at adam.mattis@davisbase.com or on Twitter @AgitatedAgilist. Leslie is a business analyst by trade and resides in Columbia, SC. Most often she engages with organizations initiating agile transformations. You can reach her at leslie.morse@davisbase.com or on Twitter @lesliejdotnet.