Great Big Agile

As the prolific and popular SPaMCAST podcaster Tom Cagley proclaimed during his keynote at the 2017 Agile Leadership Camp, “Values aren’t really what matters; behavior matters.” Cagley, who has interviewed more than five hundred technology leaders on his podcast series, hit the nail squarely on the head. Culture is usually derived from organizational values.

There is a reason the Leading Performance Circle comes first and is the largest circle in the Agile Performance Holarchy. Above all else, agile organizations must be led by agile leaders. Strong leadership is essential for successful self-organization – it’s just not the kind of leadership you’re used to.

The Providing performance circle (Figure 3-1) describes the actions, roles, and outcomes related to providing an agile infrastructure. The organic nature of agile adoption has led some to believe that the leader has little responsibility to provide an infrastructure, but this has proven to be unrealistic at scale. The infrastructure might be different than what leaders have experienced thus far, but it is required nonetheless. Experienced leaders have learned that providing a solid infrastructure is essential to scaling agile across the enterprise.

The Envisioning performance circle describes actions and ceremonies that address the architecture required to define high-quality products and services (Figure 4-1). Behaviors demonstrated in the Envisioning performance circle include:

The Crafting performance circle describes objectives, actions, and ceremonies that address the capability lift and craftsmanship required to consistently deliver high-quality products and services (Figure 5-1).

The Affirming performance circle describes actions, ceremonies, and roles that address the observation of team performance (Figure 6-1). The Affirming performance circle is about confirming that all team members, including management, are walking the walk," and the products that are built are meeting the needs of the business customers.

The Teaming performance circle describes actions, roles, and outcomes that address agile teaming (Figure 7-1). Agile leaders have an opportunity to model the successes of agile teams throughout the organization through observation and adoption of common agile ceremonies that may be foreign to team members within the technology, marketing, operations, finance, infrastructure, and purchasing organizations.

Acceptance testing, also known as User Acceptance Testing (UAT), provides the customer with an opportunity to validate that the product increment or released system is able to handle real-life scenarios and transactions. Some of this can be addressed in Sprint Demos/Reviews, but often systems become so complicated that more formal acceptance testing is required. To get the most valuable feedback, testing should be performed by an actual end user, or qualified designate, and should be conducted on the production system in the actual or simulated production environment. The goals of UAT include gaining the customer’s approval of the system or product and clearly identifying any defects or issues, and capturing changes to existing use cases or user stories.

An agile agreement is a contract that exists between an agile organization and an agile supplier. While entering into contracts is not new, aligning supplier contracts with agile product development is a contemporary concept. A traditional supplier contract is a low-trust, command-and-control artifact that relies on milestones and deliverables to manage the contract and process payment. An agile agreement is different in that it requires a high-trust, iterative, and incremental approach to supplier management. An agile agreement defines the agile terms and conditions for both parties, the fixed product development time period, and the variable scope of work that the supplier will perform.

Agile digs describe the physical or virtual workspace that a leader provides for an agile team. Agile digs is a work environment that aligns with agile values such as collaboration and visibility. To promote collaboration, the workspace enables team members to talk freely, see one another, and gather together in common spaces. To enable visibility, agile digs include wall space, whiteboards, and information radiators. The ideal agile digs environment is a mixed-media space that allows for team collaboration, customer engagement, and individual work.

The purpose of an Agile Partner Assessment is to select an external partner to collaborate with that is committed to agile values and to deliver products and services in an iterative, incremental way. It is important to carefully analyze and select an agile partner who aligns with your organization. In order to make an informed decision, start with reviewing the organizational agile values and identifying criteria that must be met. Next, conduct research to identify multiple companies that can be evaluated. Last, ensure that key stakeholders are included in making a final selection.

The purpose of All Hands Raised is for formal and informal leaders to share goals and objectives with teams and functional groups, and more importantly, receive feedback and proactive acknowledgment. As the number and size of teams increase, All Hands Raised provides a structured, yet agile, framework for the sharing of vision and goals, responding to direct questions, and listening to the voice of the organization. The All Hands Raised also helps prevent the corporate version of the “telephone game” wherein important messaging is diluted and transformed beyond recognition.

The Arc of Conversation is a communication framework used to resolve a concern or overcome an impediment. It involves coaching and active listening from one party and honest, direct communication from the other party. The key to the arc of conversation is for the “coach” to provide a comfortable environment for the “coachee” to speak their mind. The desired results of this communication framework are a common understanding of the issues, identification of possible solutions, and a shared accountability for the resulting actions.

Automated Build is a component of an overall continuous integration or continuous build strategy that increases product quality and development efficiency. Automated Build is a system that executes unit and regression testing on completed code modules without manual intervention, checks the modules into a configuration management (code management) system, compiles them, and, assuming success, builds them into the larger code base for integration, system, and user acceptance testing. An automated build system can also enforce rules, such as coding standards, and improve code quality using success criteria.

Backlog grooming (sometimes called story-time) is a common technique used by product owners and teams to clarify, size, and prioritize the backlog of epics and user stories before and during a sprint. The product owner has accountability for the product backlog and engages in regular, collaborative discussions with the agile team to review and revise it. The agile team supports backlog grooming by providing knowledge of the product or service being developed and the relative size of the epics and user stories in the backlog. New epics and user stories may emerge as a result of backlog grooming. It is the responsibility of the product owner to capture these within the product backlog along with their acceptance criteria. Backlog grooming typically includes a negotiation between the product owner and the agile team on which user stories will be added, removed, or revised. The user stories at the top of the backlog are typically included in the next sprint or iteration.

A Best Practices Board displays the best ideas, work products, and lessons learned from one or more agile teams, functional group, or manager for the benefit of the entire agile community. Best practices are harvested from retrospectives conducted by agile teams, functional groups, and the enterprise. Defined criteria are used to select best practices that are truly “best in class.” Someone is assigned the accountability for posting and maintaining best practices on a physical or virtual board. The Best Practices Board is located in an area that is accessible to all members of the agile community. This could be a white board in a common area, a filterable list in a tool or wiki page, or a large digital screen in each team area.

Big Room Planning (Scaled Agile Framework), sometimes called Release Zero (Agile CMMI), is a broadly attended, intensely focused stakeholder event, often lasting for two days or more, where long-term planning, interdependency identification, systems learning, organizational architecture, and the performance and planning framework for a successful program is established.

Brainstorming is a group discussion technique used to generate new ideas or solutions related to a goal or a problem. A brainstorming session has a facilitator who welcomes all ideas and records them as they are offered. Participants quickly and spontaneously state their ideas in a manner that evokes kernels of corn being popped. The group avoids evaluating or critiquing the ideas during the brainstorming session. The facilitator helps the group to avoid planning or determining how the ideas will be implemented. Brainstorming sessions may be time-boxed or terminated when there are no more ideas to offer (or kernels of corn to pop). For a successful brainstorming session, establish ground rules such as:

A burn down chart is an information radiator that visually depicts a “value trajectory” of the sprint/iteration. Based on the number of story points an agile team is historically able to “burn down” during each sprint (“velocity”), the burn down chart helps the product owner, agile team, and leadership to understand whether or not they will deliver the desired business value and functionality that was identified in the forecast during sprint/iteration planning.

User stories have three critical components often called the 3Cs: card, conversation, and confirmation. User stories are often written on cards, or a digital equivalent. The card does not contain all the information, but is a reminder of what the story is about for the requirements discovery and backlog grooming ceremony. The detail about each requirement, epic, or story is communicated from the product owner to the agile team through conversation that involves an exchange of views, scenarios, and operational workflow. The product owner typically defines the confirmation, or acceptance criteria, directly before user stories are selected for each sprint.

Continuous Deployment is an extension of continuous integration, and it is focused on minimizing the time between product development and that product being used by end users. Continuous deployment is the process that takes validated features from continuous integration and deploys them into the production environment where they are tested and prepared for release. The goal is to deliver incremental and valuable solutions to the end users as frequently as possible. To enable continuous deployment, the team typically relies on automation tools.

Continuous Integration (CI) refers to the assembly of product components in incremental stages, using a purposeful strategy and defined procedures. CI integration is an approach to continuous testing and product integration that was first introduced in extreme programming (XP), but is not now common in almost all successful agile projects. In a CI environment, an application is built and unit tested, and in some cases integration tested, using automated tools, each time new code is “checked-in” to the code management system.

CRC Cards (Class, Responsibilities, Collaborators) are typically used when object-oriented design and development is preferred, and are helpful when there is a need to rapidly design one or more product features that may be instantiated as an object within the source code. First, two or more team members write down the names of the most critical classes involved in the feature on index cards. Second, the cards are fleshed out with lists of the responsibilities of each class and the names of collaborators (i.e., other dependent classes). Third, team members perform a role-playing exercise and assume the role of one or more classes while playing out a plausible scenario of the design.

The Daily Stand-Up (or “Daily Scrum” or “Daily Meeting”) is an agile technique that is popular with most agile teams. It is used to maintain a shared understanding of progress, identify impediments and risks early (“fail fast”), and increase collaboration and transparency among team members. As the name indicates, the meeting occurs every day, and participants often stand for the duration of the meeting in order to encourage brevity.

The definition of done (DOD) is a fundamental element of any agile project that helps maintain quality and limit scope. It is an agreement within the team that defines what must be completed for each user story in order to be presented at a sprint review with the product owner. Definition of done can be applied to epics, user stories, and tasks using unique criteria to define when each is “done.” The DOD can be extended to each agile including sprint planning, sprint demos, retrospectives, and backlog grooming in order to achieve team agreement that each ceremony is complete. In that case, the DOD defines the tasks and work items required to complete each agile ceremony.

A definition of ready (DOR) enables a team to specify certain preconditions that must be met before a user story can be accepted into a sprint. The goal of the DOR is to identify defects in the story before work has commenced, thereby reducing defects early, when they are the least costly to address. User stories that are "ready" are clear, concise, sized appropriately for a sprint, and most importantly, actionable.

Dot Voting is a technique that allows an agile team to quickly select or prioritize items with input from all team members. Each team member is given the same number of dot stickers and instructed to place the stickers near the list of items they wish to select or prioritize. Team members may place as many dots as they wish on any item(s) on the list. Items with the most dots are selected or prioritized based on the number of dots they receive. This technique is frequently used during the sprint retrospective to help prioritize improvements.

An epic is a large user story that describes a body of work that cannot be completed in a single sprint. Teams will break down an epic into smaller user stories that can be accepted and completed within a single sprint. The product owner has responsibility for writing epics and the user stories that result from them. Both epics and user stories are maintained in the product backlog.

Evaluation is a method to understand how work is being done. Whereas a Gemba Walk is to “go and see,” an evaluation is to ask, record, and provide feedback to an agile team or functional group. Evaluations are conducted against a known baseline, and they are performed by an objective, trained resource using a checklist or commonly understood set of criteria. Results are communicated to the agile team or functional group to help them improve team performance. Evaluations are valuable for understanding the consistency of behaviors across many teams within a large organization.

Frequent Releases is a looser and more relaxed version of Continuous Deployment. Their primary purpose is to put new or updated products into the hands of the end-user community quickly to gather feedback and respond rapidly to change requests. A release plan is used to define the frequency and timing of releases, and they can occur after each sprint or on a calendar schedule. Monthly releases that include the product increments of two two-week sprints are common among large agile organizations.

A Gemba Walk is a technique used to observe and understand how work is being performed. Gemba is taken from the Japanese word gembutsu, meaning “real thing” or “real place,” and a Gemba Walk has the following elements: observation (watching people perform work in-person); location (observing people at the actual location where work is performed); teaming (interacting with people performing the work). Gemba Walks provide an up-close, detailed view of behaviors in action and are a powerful tool for identifying process improvement opportunities and new ways to support the agile team. They are also useful methods for leaders to see how agile teams are demonstrating agile values.

Gemba Kaizen is a Japanese concept of continuous improvement designed for enhancing processes. Gemba refers to the location where work is performed, while Kaizen is tied to the improvements. Gemba Kaizen includes identifying changes, making improvements, monitoring changes, and readjusting as necessary. An individual, group of people, or an improvement suggestion system can perform Kaizen. Having a strategic system in place to monitor improvements will lead to great results in the long-term overall improvement.

Goal, Question, Metric (GQM) is an approach developed in the early 1980s, piloted at the NASA Goddard Space Flight Center; it is used to derive useful measurements from one or more goals.

Incremental Development is the practice of breaking the delivery of features or functions into small pieces that can be envisioned, built, tested, and delivered in a predictable, timeboxed period of time. Through the completion of multiple increments, a working system is created and delivered that fulfills the functional and nonfunctional requirements. The approach requires multidiscipline engagement, and the creation of a design and other documentation in matching increments. Paired with Iterative Development, it is a powerful and predictable work management system that forms the basis of most agile frameworks.

A Kamishibai Board is a visual information management system used to plan and capture the results of process audits on the most critical processes in the organization. The primary purpose is to give leaders a schedule for when to audit a process and what behaviors to observe. A Kamishibai Board is often part of the Gemba, the location where work is performed. The board shows the status and results of the required audits for each team or group and displays notes about issues, risks, and corrective actions. The primary goal of the board is to enable immediate problem resolution.

A Kanban Board is a visual work management system that enables understanding and optimization of continuous work being performed by a team or functional group. The board depicts the state of work across the top, and the flow of work as it goes through each state. A basic Kanban Board has states for “waiting,” “in progress,” and “completed.” Teams are free to adapt the board and can define as many states as needed to understand how much work is to be done, being done, and is done. A major goal of Kanban is to limit work in progress to drive improvements in efficiency and throughput. Choose Kanban when the work in the “waiting” state is not easily predictable, or when the type of work is driven by demand.

The Kano Model is a technique used in product development to identify the most appropriate mix of features in order to maximize the satisfaction of a product. When using the Kano Model, product features are grouped into three categories: Basic, Performance, and Exciters. The Basic category contains features that the product is expected to have. For example, if the product is an automobile, turn signals would be considered a basic feature. These features do not drive satisfaction with the product, but the absence of a Basic feature can lessen customer satisfaction with a product. The Performance category contains features that can drive a linear increase in satisfaction. Features that fall into the Exciter category are the type of features that can differentiate the product and make it stand out from the competition in the market.

Lean Coffee is an agile technique that allows for successful, collaborative meetings with minimal planning or agenda setting. Personal Kanban boards, sticky notes, sharpies, and innovative voting techniques such as dot voting, fist-to-five, or even dart-guns with targets are often used to aid in the collaboration and decision-making process.

Mob programming is a technique used by a collaborative software development team to rapidly solve a problem, or to write complex software. Mob programming is similar to pair programming, but with two distinctions. First, mob programming uses as many developers as possible so that many perspectives lead to a more complete solution. Secondly, mob programming is performed on-demand, and it is not a standard behavior for the team.

Obeya is Japanese for “big room.” It refers to a dedicated space where team members meet to collaborate and solve problems. It is set in an environment that supports the free flow of information and communication between team members and other stakeholders. An Obeya Room helps to minimize barriers that can stifle communication and inhibit collaboration; and the use of charts, graphs, boards, sticky notes, and other visual information management tools are commonplace in Obeya Rooms as they assist with collaborative problem solving.

Open Space Technology is a way to enable a diverse group of people, in any kind of organization, to create inspired meetings and events where the outcome is unclear. In Open Space sessions, participants create and manage their own agenda of parallel working sessions around a central theme of strategic importance.

Pair programming is a software development technique in which two developers work together to complete a coding task. They generally work at one workstation with one programmer being the “driver” and the other being the “navigator.” The navigator reviews code as the driver is entering it, performing a sort of real-time code review. While this typically appears increases the cost of programing, the reward of increased code quality far exceeds the investment in time and effort.

The purpose of a peer review is to ensure that the highest quality is achieved, given the allotted timebox, prior to releasing a work product to the next stage in the process, or to the customer.

Planning Poker is an agile estimation technique that establishes relative sizing using story points and playing cards.

The product backlog is a prioritized list of everything that may be included in the product. It can include epics, stories, features, bugs (if the product is in production, or if there have been releases of the product in prior sprints), documentation changes, and any other tasks required by the product owner or agile team. The product owner owns the backlog and the priority of the items on it. The product owner may seek input from stakeholders, business representatives, and the agile team to help set the priority, but the owner is responsible. The backlog is maintained during the sprints through the backlog grooming ceremony.

Product scenarios are used to describe how a user will interact with a product to perform actions to achieve a specified goal and tie the who, what, when, why, where, and how in order to provide the overall context of those user actions. In order for a product scenario to be effective, it utilizes user profiles (personas) and focuses on the key interactions between the user and the product. The use of product scenarios can help narrow the focus to which product features would provide the most value to customers.

The Project (Team) Charter summarizes the project or team’s objectives, scope boundaries, behaviors, and cultural characteristics. The team collaborates to develop the Project (Team) Charter in order to define the common purpose they are working toward. Topics to be considered for inclusion are:

A prototype, or sometimes called a “spike” if it’s limited in scope or functionality, is a technique used by agile teams to create a product or service proof-of-concept in order to quickly solicit feedback about the design from customers and end users, or to help the team understand the user stories (see “Spike (Design Spike) for more information). Prototypes or spikes can be developed in various ways depending on the type of feedback desired. For example, they can be created using basic materials (e.g., pen and paper) or sophisticated technologies (e.g., markup languages). Prototypes or spikes allow customers to interact with a product giving product teams insight into which features are most important to the end user. The ability to experiment with multiple prototype iterations, and test various concepts in the field, provides critical input into refining the product vision.

The purpose of release planning is to project a long-term plan for delivering specific functionality on a loose schedule to meet a business requirement. The used of fixed plans, budget, and functionality, commonly seen in “waterfall-style” planning, is discouraged. The release plan is vision, based on known variables, of what may be released along a given timeline.

The purpose of a retrospective is for each team or functional group to reflect on actions, results, and behaviors from the current sprint, and identify potential improvements for the next. Retrospectives align to one of the core principals from the Agile Manifesto, which states “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Review is a well-defined and formal method for ensuring that a work product meets team or organizational expectations, and to ensure that defects are identified and corrected as early as possible. Review is an opportunity to “fail fast.” Unlike a Gemba Walk, which is to “go and see,” a review is to “ask, record, and provide feedback.” Reviews are useful to gather a broad set of perspectives, develop knowledge of less-experienced team members, and to standardize improvements across teams and the organization. Reviews can be informal observations, or can use formal checklists and process baselines, but should always generate data that can be used to share learning and prevent the recurrence of common problems.

The purpose of the “Roles and Accountabilities” game is to build a common understanding of team roles and accountabilities, and to encourage self-subscription to accountabilities. This game identifies key roles and accountabilities on index cards, then has the team align the accountabilities to each role. While aligning accountabilities, the team can work through ambiguous or contentious accountabilities, and the scrum master may assist by helping team members reach the best conclusion. This game may be applied to different types of teams in an organization where clarity and common understanding are needed. At the conclusion of the game, team members can self-subscribe to roles, and all the accountabilities for each role that have been defined.

Scrum of Scrums is a technique that enables the effective synchronization among interrelated teams. Each team designates a representative, often the scrum master, to participate in the scrum of scrums events, and to ensure that the teams are coordinated and synchronized. The scrum of scrums encourages a daily meeting where the representatives communicate and collaborate about issues, risks, and status across teams.

A scrum wall/scrum board is a visual information radiator for displaying the current state of user stories and tasks within a team. Transparency is an important principle in scrum, and the scrum board is a way for a project to display what is being worked on, what is in progress, and what has been completed. If the team is at one location, then a physical scrum board is recommended, but distributed teams may wish to implement tools within popular agile application life-cycle management systems. The scrum board is continuously updated throughout each sprint.

Self-Selection/Self-Subscription is a core agile value that encourages team members to own their decisions by selecting the work that they will do based on skills, interest, and the team’s needs. It works best when used during a facilitated ceremony where a scrum master or another facilitator ensures that product owners, project managers, other managers, or other outside influences are not tasking individual team members. The highest level of team member commitment is achieved via self-selection, a technique that enables self-organization.

A Spike is a solution-specific experiment, often taking place during an entire sprint, but sometimes in shorter durations, aimed at answering a question or gathering information important to the team’s success.

A sprint is a timeboxed event where most work gets done, and typically has a duration of two to four weeks. Several ceremonies are embedded in a typical sprint, including sprint planning, sprint demos/reviews, retrospectives, daily stand-ups, and backlog grooming.

A Sprint Demo (also called Sprint Review or Show and Tell) is a collaborative technique used to ensure that key stakeholders are aware of, and accept, the value being delivered at the end of each sprint. During the sprint demo, the work that was completed, as well as the forecasted work that was not completed, is demonstrated to the product owner and other customers.

A sprint planning meeting occurs at the beginning of each sprint, and is a negotiation between the agile team and the product owner as to what value can be delivered in the upcoming sprint. During the sprint planning meeting, a sprint backlog is developed and tasks are identified to support the forecasted user stories. Team members assess how much work they can accomplish during the sprint based on known velocity, and the team members subscribe to the various stories and tasks to be completed.

Stakeholder identification and management is the process used to identify all stakeholders for a project, and how they will be involved. It is important to understand that not all stakeholders will have the same influence or effect on a project, nor will they be affected in the same manner.

A State of the Team is a gathering of multiple teams to understand what has been accomplished by each team, and what is needed from other teams, functional groups, or leadership. The state of the team allows all stakeholders to understand a global view of all status and progress. This allows leadership to assess the organizational risk profile, and determine where support is needed, as well as an opportunity for teams to learn what others are experiencing. It is an important tool to build trust and understand progress at an organizational level.

A SWOT analysis is a strategic planning tool that helps a business entity identify their strengths and weaknesses, as well as opportunities and threats that may exist in a specific business situation. A SWOT analysis is most commonly used as part of a sales or marketing plan, but it is also a good tool for agile teams to use as a starting point for projects or sprints.

A team agreement is a social contract entered into by members of an agile team to define team behaviors, expectations, and standards. Some team agreements are simple ideas written on a white board, while others are detailed charters that contain important facts about the team itself. Team agreements are typically developed at the beginning of a release and can be updated after each sprint retrospective or sprint demo.

The Team Estimating Game (sometimes called the Fibonacci Team Estimating Game) is an agile estimation technique that establishes relative sizing using story points and a rough order of magnitude estimation. Planning Poker is a similar technique that uses playing cards to depict story points.

An agile team should have their own space, known as a Team Room. Team room set-up is typically done when a new team is formed, or a new project is set to begin. Elements of a team room that need to be considered are listed below.

Technical Debt is incurred when the agile team proactively determines that a less optimum, less efficient, or less robust solution is appropriate given constraints of time, budget, or resources. As this graphic from Martin Fowler describes, as technical debt increases, the costs and effort to continue development, or maintain an existing system, will become too high, and a “technical debt sprint” should be scheduled within a release to improve code quality.

Test-driven development (TDD) is an agile technique where a developer will write a basic test case to verify the desired functionality, knowing that it will fail, and then writes the minimum amount of code to pass the test. The developer will then enhance the code to ensure that it meets acceptable performance and coding standards and principles.

Three Diverse Humans, or TDH, is a User Story and Design validation technique that involves review and input for three separate, but equal, individuals prior to Product Backlog generation, or commitment to a complex design. The typical TDH session is a one-hour, rapid fire meeting that includes a developer, an analyst/SME, and a tester, but it can be attended by alternative roles as well.

Agile teams are learning teams. There are different ways to train team members, but each one should be designed with outcomes that build capability. Organizations should identify what training methods will work best for each scenario, and ensure that all team members have the capabilities to meet their commitments.

Unit testing is a technique applied by individual software developers to ensure that the smallest, self-contained pieces of code function as designed and provide the correct results. Because manual unit testing is time and effort intensive, many tools exist to automatically run unit tests based on design elements coded directly within code modules. Continuous Build/Integration tools ensure that code is unit tested with no failures prior to check-in of code.

Velocity is a historical definition of a given team’s ability to deliver value during a consistent sprint duration.

Visual information management is the practice of using information visualization techniques to depict important information to a large group of people. Visual information management is a clear, simple, and effective way to organize and present the result of a team’s work. It can also be perceived as fun by the teams, since visual elements bring color and life into an otherwise sterile office environment. Visual management will positively influence the behavior and attitude of team members, managers, and stakeholders by helping build transparency and trust.

Successfully transforming an organization where leadership practices traditional command and control, to one that is agile and self-organizing, will bring you numerous benefits, but it’s not as simple as adopting a few scrum ceremonies. As powerful as those ceremonies are, they are only part of the picture. During this chapter, I’ll describe my own journey to an agile leadership state, along with what worked, what didn’t, and what I would do differently next time (sound familiar?).