An Agile Focus on Process

Has improving your Scrum team been like taking a walk to Mordor? “Not with ten thousand men could you do this. It is folly.” Tolkien, Lord of the Rings. The path seems wrought with peril. Why not just implement the ceremonies first, then focus on the intent later. Stopping there incurs the risk of slipping back into bad habits. Maybe they were acquired from the misuse of Scrum principles, or are a hodgepodge from the expediency of the moment decisions. It begs the question, how would you evaluate if your team is doing Scrum properly? The first dimension out of the six to be discussed is agile processes. That seems to be a reasonable starting point but any one of them will do.

Author: Mark Haynes, https://dmarkhaynesconsulting.godaddysites.com/

Six Dimensions of Agility:

• Process Focused,
• Team Dynamics,
• Transparency,
• Customer Focused,
• Manageable Work, and
• Human Capital.

Rather than creating a detailed project plan, based on an agile version of the Capability Maturity Model the intent is to help you kick off your agile maturity conversation. In this way, you can help guide your team towards a better agile footing by asking probing questions. To that end we will:

• Review a few definitions to establish common ground,
• Identify a few Red flags to help assess if you are going off the rails,
• Specify Policy check-points to act as guideposts, and
• Provide assessment questions as a conversation starter. 

A focus on process

A foundational principle of Scrum is that teams control their underlying processes. This speaks to the philosophy of flexibility, and adaptability. If a team is to be able to react to the current business climate it needs the capacity to make timely changes to its processes. When evaluating a team’s process agility, consider three subordinate dimensions:

• Process Controls,
• Iterative & Incremental development, and
• Agile Ceremonies.

Process Controls assist with moderating the flow of work based on feedback loops. Shane Finkel distinguishes between empirical processes based on observation and experimentation vs. defined processes. “In Scrum, an empirical process is implemented where progress is based on observation and experimentation instead of detailed, upfront planning and defined processes. Using empirical process control is working in a fact-based, experience-based, and evidence-based manner. Defined process control, on the other hand, is a process with a well-defined set of steps. Given the same inputs, a defined process should produce the same output every time.”

There is a danger here when concentrating on Process over one’s Mission. The focus on the process may lead to consistent results but doesn’t guarantee to excel at one’s goals. Within the context of a light management framework, the watchword needs to become minimalization. In other words, the reduction of overhead. This is especially true of external influences tasked to your teams, such as status reporting, documentation reviews, or approvals. Consider shifting the focus to creating short, crisp ceremonies, implementing a visual pull-based scheduling system (Lean Kanban board), and improving feedback loops.

• Red flags:

1. 1. The team has little influence on how it runs its ceremonies,
   2. Process changes require formal approval by a Change Control Board, Process group, or external committees,
   3. Definitions for Done or Ready are provided to the Scrum team.

• Policy Issue Check Points:
  • • 1. The team is performing all the Scrum Ceremonies,
      2. Processes are easy to understand, at a glance, and
      3. The process favors producing useful work.
  • Assessment Questions
    • 1. Are your current processes excessive, complicated or consume a considerable amount of overhead? [Try calculating the Overhead Ratio of indirect hours over the total hours for the sprint.]
      2. Do legacy documents or procedures require formalized approvals and sign-offs? [Every formal approval is an additional impediment!]
      3. Is your Kanban board difficult to manage, especially during the Daily Scrum?
      4. Does the team have little influence on how ceremonies are run? [ It’s about team empowerment, not about management control!]
      5. Has the team’s Kanban board been specified by management or an externalprocess control group? [It’s hard to be agile with legacy, institutional controls!]
      6. Do the processes favor producing useful work, not on outcomes such as documentation or meetings? [Although processes are important, it’s more about the mission!]
      7. Are the Kanban board, Team Agreements, and Metrics posted and available to the public?
• Iterative, and Incremental Development although different in meaning needs to be viewed as highly complementary, as two sides of the same coin. A team can’t be Scrum without doing both simultaneously. The Scheduling unit of measure in Scrum is the Sprint. Every activity performed outside of the Sprint, therefore, isn’t a Scrum event!
  • Iterative processes are performed repeatedly, cyclically adding new functionality. When moving from one version of a product or service to the next, decisions are made based on feedback, and what’s needed going forward. According to the Agile Alliance Glossary, “The Agile Alliance defines an iteration as a timebox during which development takes place, the duration of which: may vary from project to project, usually between 1 and 4 weeks, and is in most cases fixed for the duration of a given project.”
  • Incremental processes make progress through small increments. The entire solution is built piece by piece, and you don’t need to wait until the project is completed to review the final product. Each successive version is usable and builds upon previous versions by adding user-visible functionality. According to the Agile Alliance Glossary, “The Agile Alliance defines Incremental development as when each successive version of a product is Usable and each builds upon the previous version by adding user-visible functionality.”If viewed through the lens of size and duration, it strongly suggests reducing complex ideas into simple ones, eliminating dependencies, and compartmentalizing functional themes into short periods.The Sprint is a mechanism to deliver complete, and usable work. Reduce dependencies between Sprints and between User Stories. Reducing your Sprints to the minimum necessary to complete a single theme.
    • Red flags:
      1. Sprints lengths are constantly changing,
      2. Sprint length or timing of ceremonies depend upon external factors, such as release dates, or
      3. User Stories must be worked on or released to production simultaneously.
    • Policy Issue Check Points:
      1. All work is performed within the Sprint,
      2. User Stories are small, & independent, and
      3. Every effort is made to eliminate dependencies.
    • Assessment Questions
      1. What meetings are scheduled, which don’t enhance the team’s mission?
      2. How often has the Sprint length changed in the last year? [Repeatably changing Sprint length may be systematic of structural issues, such as user stories transcending Sprints!]
      3. Are there activities that transcend the completion of the Sprint?
      4. On average how long does it take to start a User Story, test it, and become available for the next Product Interval? [ In other words, what’s your Cycle time?]
      5. Can User Stories be backed out of Production, independently? [ Can you turn on/off features in Production?]
      6. Are Sprints bogged down by “monster” User Stories? [How efficiently is the Sprint work queue operating?]
      7. Are there entire Sprints dedicated to non-functional activities, [How are you prioritizing features, refactoring, and infrastructure enhancements?]
      8. Are there Sprint themes similar to Waterfall Phases, such as:
         • “QA Sprint”,
         • “Debug Sprint”, or
         •  “Refactoring Sprint”?
• Ceremonies, Rituals, or Events are the framework on which Scrum achieves flexible process controls, through the guiding principle of incremental and iterative. This is the primary mechanism that Scrum uses to achieve agility.
  • A ceremony is a Scrum-specific term. They are purpose-driven meetings with a clearly defined goal, length, and frequency of occurrence. Each one serves a specific purpose and is integrated into the overall deployment of producing production-ready work products.Scrum is a light management framework, consisting of several ceremonies or events contained within a Sprint. Removing ceremonies or radically altering them is compelling evidence that you are not doing Scrum. Within the agile community, a ritual or an event is often used interchangeably. Additional meetings outside of the Scrum Ceremonies need to be viewed in terms of how they contribute to the team’s ability to perform their mission and add value for the users. According to M. David Green, Scrum: Novice to Ninja, “Each ritual is a face-to-face gathering in real-time, which takes people away from the work they’re doing, and offers them the opportunity to have targeted communication with each other about the context of that work”.

Below is a quick reminder of Scrum Ceremonies:

• • • The Sprint is a fixed-length period characterized by a specific set of cadences, to create potentially shippable products.
    • Sprint Planning is a discussion and collaboration between the Scrum Master, Product Owner, and Developers of high-priority work that defines the Sprint goals.
    • Daily Scrum is a short, daily session where the development team meets to discuss impediments to its progress to achieve its Sprint Goals.
    • The Review is when the Scrum team reviews potentially shippable products with the Stakeholders.
    • The Retrospective is when the Scrum team celebrates its successes and identifies areas for improvement based on lessons learned from the previous Sprint.
    • Red flags:
      1. Ceremonies frequently exceed their allocated amount of time,
      2. Ceremonies often get side-tracked, or
      3. Ceremonies are commandeered by one or several individuals.
    • Policy Issue Check Points:
      1. Management, Stakeholders, and Team members have been briefed about Scrum and their roles,
      2. Ceremonies support their intended purpose, and expected outcomes, and
      3. All ceremonies, events, and rituals are time-boxed.
    • Assessment Questions:
      1. General
         • Does the team consistently perform all the Sprint Cadences?
         • Have session guidelines been established, such as:
           • Show up on time,
           • No laptops,
           • No cell phones,
           • No outside work is performed, and
           • No judgmental behaviors?
         • Do ceremonies often exceed 60 minutes?
         • Do ceremonies get side-tracked?
         • Are the majority of Scrum ceremonies open to a wider audience? [Speaks to transparency (future topic) but is also an intrinsic attribute of Scrum ceremonies.]
      2. Agile Requirements Management
         • Are requirements split into phases, such as User Stories for:
           • Design,
           • Coding, and
           • Testing? [Are you doing Agile or Waterfall?]
         • Do User Stories consistently have a:
           • Name,
           • Description,
           • Actor (targeted human or non-human user),
           • Acceptance Criteria,
           • Priority, and
           • Size estimate? [Consider the minimal conditions to achieve a “Ready” state.]
         • Do User Stories have a Ready, and Done condition?
         • How many User Stories exceed 3 or 5 Story Points? [Can you deconstruct the User Story without compromising functional integrity?]
         • Do developersoften pull multiple User Stories to work on concurrently? [Pulling multiple User Stories creates inefficiencies, impediments, and unnecessary dependencies.]
      3. The Sprint
         • How often has the Sprint length changed in the last year? [Repeatably changing Sprint length may be systematic of structural issues, such as user stories transcending Sprints.]
         • Is the Sprint length or its Cadences designed to meet external demands, such as Release dates?
         • When changing Sprint length, are crucial tracking metrics re-baselined?
         • Are Sprint lengths longer than 3 weeks? [The longer the Sprint the closer it becomes a mini project plan?]
         • Are the Sprint lengths kept short enough to react quickly to changes? [If the Retrospective is the primary Scrum feedback loop, then the Sprint length becomes the minimal frequency of change.]
      4. Sprint Planning
         • Does Sprint Planning lacks focus or must occur over multiple sessions? [What exactly have you been doing, anyway?]
         • Does Sprint Planning contain estimation or enhancement activities? [Just because Scrum doesn’t include Estimation or Enhancement events doesn’t mean they must be a part of Sprint Planning!]
         • Are User Stories ready for Sprint Planning, Pointed, Prioritized, and meet their Ready condition?
         • Does the team commit to completing the User Stories within the Sprint?
         • Does the Product Owner commit to not adding or changing User Stories during the Sprint? [Sprint planning is also a contract between the development team and the Product Owner.]
         • Do User Stories often flow into the next Sprint?
         • Does Sprint capacity consider the team’s previous performance, algorithmic calculations, time for refactoring, or estimation inaccuracies?
         • Does the Product Owner provide a Sprint theme and an overview of the User Stories?
      5. Daily Scrum
         • Does the Daily Scrum focus on impediments, not discussions about the User Story?
         • Does Management or individuals commandeer the Daily Scrum to make pronouncements? [ Ceremonies, Events & Rituals should all be purpose driven.]
         • Has everyone had an opportunity to comment on their User Stories?
         • If further discussions are required during the Daily Scrum are they put on hold, and discussed during team break-out sessions? [Fruitful but off-topic discussions should be sandboxed for later consideration.]
         • Does the Daily Stand-up often exceed 15 minutes?
      6. Sprint Review
         • Does your team differentiate between a Demo and a Review? [Scrum specifies a Review, not a Demo. Used within the same Sprint they serve different purposes. How does your team differentiate between them?]
         • Do Stakeholders or Product Owners, change their minds about what the functionality of a User Story should be? [ Scope Creep vs.Scope Clarification? Are Stakeholders clarifying functionality specified during Sprint Planning or adding additional functionality once the Sprint has begun?]
         • Do Stakeholders, Product Owners, or management attend Reviews?
         • Are Stakeholders tasked with either accepting or rejecting changes based on the Acceptance Criteria?
         • Are Reviews being used to demo previously released features?
         • Are Stakeholders notified of what User Stories are being reviewed?
      7. Retrospective
         • Is the team distracted by institutional issues or concerned with issues outside the authority of the team?
         • Has an Action board been created, with assigned User Stories? [An Action Board is just a specialized type of Product Backlog!]
         • Can all the action items be completed within the confines of a single Sprint?
         • Does one team member seem to be burdened with the majority of action items?
         • Are the team’s performance metrics discussed during the Retrospective? [Consider alternative approaches to the Retrospective.]
      8. Post-Production
         • Are the stakeholders and customers satisfied with the functionality the team has delivered?
         • Are production defects analyzed for any systemic quality issue?

Closing Thoughts

It helps to assess your team’s current approach to Scrum periodically, whether or not you have made recent changes. These questions are purposely left open to interpretation, to help promote the conversation. In Ron Jeffry’s “The Card, Conversation, Confirmation” he proposes that user stories are “social” as opposed to “documentary” requirements. Consider this to be an extension of that approach to a maturity assessment.

A good candidate for the first Dimension of agility to consider are its processes. Compliance with Scrum Ceremonies may seem obvious but attention to a form without consideration of function will lead to stagnation. It’s tempting to stop there but consider this as the first part of your agile journey.

References

4 Dimensions for Scrum Mastery by Stephanie Ockerman

Scrum: Novice to Ninja, M. David Green, SitePoint Publishing

Scrum: Empirical Process Control Vs. Defined Process Control by Shane Finkel, April 15, 2016

Agile Alliance Glossary

About the Author

Mark Haynes is a renaissance man trapped in a specialist’s body. Lately, he has been working as a Scrum Master and Agile Coach. Agile is a philosophy, not a methodology. In interviews, people often ask him how long you have been agile? His answer is “Always. I just didn’t know what it was called before.”