Blog

SAFe® Agile Transformation Webinar Recording: Mapping Business Outcomes to SAFe

By: Mike Hall | May 19, 2020 |  Agile Coaching,  Agile Transformation,  Leadership,  Webinar

In this SAFe® Agile transformation webinar recording, Mapping Business Outcomes to SAFe, Mike Hall, Senior Agile Coach and SPC5, discusses how to ensure your SAFe transformation achieves desired business outcomes. Watch the video to discover the missing “connective tissue” that ties your business objectives to the underlying framework.

View the full slide deck, here.

If you are interested in the Path to Agility cards, learn about our certification process, here. 

Learn more about our approach to SAFe Agile transformations, here.

Blog

4 Myths About Scaled Agile Framework® (SAFe)

By: Mike Hall | Feb 06, 2020 |  Agile Transformation,  Article

Scaled Agile Framework or SAFe® is the most popular and far-reaching of the Agile scaling frameworks out there. But before you make the decision to go all-in with this popular framework, it’s important to know the facts. Here are 4 busted myths about SAFe.

1. Scaled Agile Framework is prescriptive!

The myth that “SAFe is prescriptive!” is the one I hear the most often. Let’s examine this a bit closer by starting with the meaning of the word “prescriptive”. A common definition for this word is “enforcement of a rule or method”. Even more telling are the listed synonyms: dictatorial, narrow, rigid, authoritarian, repressive, dogmatic. Yikes!

SAFe is a framework. It is not a set of rigid rules. Like any good framework, it requires thoughtful customization to your specific situation. The documentation available at Scaled Agile clearly highlights this dynamic. 

There is one “rigid” aspect to SAFe, and rightfully so. The 10 SAFe Principles are considered immutable. As mentioned above, the principles are considered best practices from the Lean and Agile worlds. These guiding statements are principles, not practices. SAFe clearly allows for customized practices as long as the principles are not encumbered.

2. Scaled Agile Framework is heavyweight

At first glance, SAFe looks overly complicated, thus the cries of “heavyweight”. I would instead call it “complete” or “comprehensive”. But let’s be honest here – typical Agile enterprise transformations are complicated! It stands to reason that most enterprises will need a reasonably comprehensive framework to leverage when pursuing full enterprise agility.

Designed specifically for large enterprise, SAFe addresses the important enterprise-level challenges such as:

  •     How business strategy is translated into executable actions at the development team level
  •     How to ensure seamless collaboration between IT and business
  •     Lean economics
  •     Funding
  •     Pull-based model of bringing the work to persistent teams
  •     Consistent estimation approaches across all teams

3. Scaled Agile Framework is RUP

As a software developer back in the day, I familiarized myself with the Rational Unified Process (RUP) and experienced some reasonable success using it on several projects. RUP has 4 project lifecycle phases – Inception, Elaboration, Construction, and Transition. While it sounds a bit waterfall-ish, these phases do overlap significantly, which allowed for some level of inspection and adaptation between the phases. RUP also points out that iterative development should be used during the Construction phase.

I like to think of RUP as a “bridge” from Waterfall development to Agile development. Personally, at the time I did not think RUP went far enough from an agility perspective. But it was significantly better than standard Waterfall, and for that, we owe the inventors a debt of gratitude.

There is nothing in SAFe that even remotely resembles RUP. SAFe is Agile on steroids, scaled for the enterprise. RUP is a bridge between Waterfall and Agile. In SAFe, there are no old-fashioned phases or gate reviews. Frankly, the only thing in common between SAFe and RUP is that they are both product development frameworks that help teams be successful. And that’s a good thing. 

SAFe represents advanced, evolved, mature Agile thinking – for the whole enterprise.     

4. Scaled Agile Framework is an all-or-nothing approach

Another popular myth is that SAFe must be used in its entirety regardless of the situation. This is false.

As described above, Full SAFe has 3 levels: Portfolio, Large Solution, and Essential. SAFe is configurable. If you don’t need a level, then don’t use it. For example, Essential SAFe consists of only the Team and Program levels. Many enterprise transformations use Essential SAFe only. Others start with Essential SAFe and then add a 3rd layer over time to handle even larger initiative (Large Solution layer) or portfolio management (Portfolio layer) to handle business definition and funding.

Within each layer is a set of roles, constructs, and events. If any of these do not make sense in your specific situation, then don’t use it. But always cross-check your decision against the 9 SAFe principles to make sure that you are still headed in the right direction from a Lean-Agile perspective.

I like to call SAFe a “subtractive framework” in that it covers all or most situations for a full-on enterprise Agile transformation. An Agile leader wanting to apply SAFe can pick and choose which levels to use. You can start with just the 2-level Essential SAFe which provides a straightforward scale up from team-based Agile. You can subtract aspects that do not fit your culture. You can also adjust the specific practices recommended to best fit your company’s culture and needs – as long as you don’t violate SAFe’s nine core principles. 

Conclusion

SAFe is here to stay. It satisfies the need for many organizations to scale Agile within their enterprise. While it does have its detractors, SAFe should be considered carefully by those leading an Agile transformation. Continue your reading on SAFe with Demystifying SAFe® : A beginner’s guide to Scaled Agile Framework.

 

Looking to scale Agile throughout your enterprise? 

Contact Agile Velocity to explore options and find the right solution for you.

 

Blog

The Most Important Question to Answer for Successful Agile Transformations

By: Mike Hall | Sep 24, 2019 |  Agile Transformation,  Article,  Leadership

A single question mark in a thought bubble is against a solid yellow background, representing the most important question to ask for a successful Agile transformation. For leaders during an Agile transformation, the question of why the organization is going Agile is vital. Without this compelling reason for change, the transformation runs the risk of losing steam and failing.In a recent discussion with a business leader, I asked a simple question: “Why are you considering an Agile transformation?” 

“We just want to get better,” she replied.

Awkward silence. 

I understood what she meant. We all want to get better. But that’s not a great reason to spend hundreds of thousands of dollars on full-scale organizational change. Not when she didn’t have any particular business goal in mind.

Any type of transformation—Agile, digital, or otherwise—is serious in terms of cost, effort, and time. It’s not uncommon for a transformation to last several years, impacting hundreds of workers. Plus, not all Agile transformations are successful Agile transformations. CIO digital magazine reports only 17% of transformations achieve a sustained level of improvement. 

In my experience, this is often caused by a lack of a compelling, business-centric purpose or focus for the transformation. Successful Agile transformations ask workers to think differently, act differently, and evolve through continuous improvement. Workers must adopt different values and be willing to change their mindset about how they approach work. When asking this much of your people, you should provide a good reason. Something that is both exciting and important. 

Identifying Your Compelling Reason for Change

As a leader, you can uncover your compelling reason for transformation by asking this killer question first and foremost:

“What is our business objective(s) for this Agile transformation?”

Starting with a business objective helps ensure that everyone involved in the Agile transformation understands why they are being asked to change. This is key to a successful Agile transformation.

A business objective also aligns the underlying Agile transformation efforts in pursuit of the stated objective. Progress towards your business objective can be measured and adjustments made as needed. Establishing a business objective will also naturally lead to a host of relevant follow-up questions that can be explored to determine the path forward. 

Business objectives such as “We want to get better,” “Everyone is doing agile now,” and “We need to go SAFe® because it is popular” are not enough. They make it more difficult to prioritize work pertaining to the Agile initiative.

In contrast, great business objectives are S.M.A.R.T. (specific, measurable, attainable, relevant, and time-bound). But don’t stop there! They should also be inspiring, motivating, and action-oriented. For example:

  •     To keep our customers safe from digital harm and reduce damage from criminal cyber activity, we want to improve our market responsiveness to 1 month or less when new security breaches are found.
  •     In order to re-establish customer trust in our XYZ product line, we want to reduce post-release defects found within 6 months of a release by 80%.
  •     Increase our product revenue by 40% within 2 years through prioritized delivery of add-on services in order to stave off the market competition from the fast-follower competition.

Agile Velocity’s Path to Agility® framework identifies the following 9 areas for business objectives. Consider these areas when crafting your own business objective for your Agile transformation.

As I delved deeper with the business leader I mentioned earlier, she realized she was truly after a level of development predictability that would allow her company to make accurate marketing statements about upcoming product releases. From there, I encouraged her to include a quantitative factor in her business objective to ensure that it was measurable.

We went from “We want to get better” to a clear business goal that guided the transformation through to success. 

 

In my next article, I’ll explore how to organize the Agile transformation effort. Now that we have a great business objective, we can identify transformation outcomes and underlying technical capabilities that influence our business objective.

In the meantime, you can read more about our approach to building lasting business agility, you can check out our Transformation Services page.

Blog

Horse Before the Cart – An Outcome-Oriented Approach to SAFe® Transformations Presented at Agile2019

By: Mike Hall | Aug 14, 2019 |  Agile Transformation,  Slides

Leaders often ask, “Will implementing SAFe® lead to my desired outcome?” This is like asking, “If I put the cart in front of the horse, will the horse push it?”

SAFe® is all about events, roles, responsibilities, cadence, scaling, and process. It can read like a set of prescriptive rules and top-down regulations–some agilists even claim that SAFe® is not agile!

In this workshop at Agile2019, Mike Hall shared an outcome-oriented approach to a scaled agile transformation. Instead of starting with the framework, Mike starts with a business objective. Attendees explored what agile outcomes will influence an organization towards a certain business objective. And collaboratively prioritized capabilities within these outcomes to drive improvement. Then, attendees used SAFe® constructs to realize the capabilities in order to achieve the desired business objective.

Key takeaways from “Horse Before the Cart – An Outcome-Oriented Approach to SAFe® Transformations”:

  • How to apply an outcome-oriented approach to a SAFe® transformation
  • The ability to map agile transformation outcomes, agile capabilities, and SAFe® constructs to lead an organization towards a desired business objective
  • How to integrate outcome-oriented thinking into your organization 
Blog

5 Practices To Start Scaling Agile

By: Mike Hall | Jun 04, 2018 |  Article,  Leadership,  Process

When considering scaling Agile, it is important to start small. Some of the various scaled Agile frameworks available can look incredibly complex, while others can look simplistic and incomplete at first glance. Relax. Don’t over-complicate it. Start small with these proven best practices—and then fill in the rest as your Agile journey continues!

Situation

How do you know when to apply Agile at scale? Before we talk about scaling, let’s determine if you truly need to scale. Common situations causing a need for scaling include:

  • More and more large initiatives that require multiple teams
  • Limited collaboration between teams working on similar or dependent efforts
  • Late-breaking dependencies that impact the delivery schedule
  • Teams focused primarily on their deliverables, often at the expense of the larger program objective
  • The pursuit of full enterprise agility beyond just team-level agility
  • Burning platform—current way of doing business is inadequate to survive

Many enterprises have experienced success with Agile at the team level. Their teams are working iteratively and incrementally, delivering some form of business value every 2 weeks. But then they realize that Agile is also needed for their initiatives that are broader in scope and require a significant number of teams.

In this situation, how do we ensure that the multiple teams involved are fully synchronized and working effectively towards a common goal? How do we ensure that they are managing risks well? How do we help ensure the success of the program?

We recommend the following five practices to start scaling Agile:

  • Scrum of Scrums
  • Product Owner Sync
  • Program Backlog
  • Dependency Identification and Scheduling
  • Common Integration Environment

Scrum of Scrums

The Scrum of Scrums is a scaled version of the team’s daily standup. The purpose of the Scrum of Scrums is to ensure alignment of all teams working on the program. Most Agile scaling frameworks (SAFe®, Nexus, Scrum at Scale, etc.) recommend this synchronization event.Scrum of ScrumsThe Scrum of Scrums is held 1 – 2 times per week for 15 – 30 minutes. Each team sends a representative, typically the ScrumMaster, to the Scrum of Scrums. If additional expertise is needed for a discussion, the ScrumMaster can bring in development team members to assist in understanding and decision making. If the multi-team program has a Program Manager, the Program Manager also attends to better understand the inter-team risks.

Topics discussed at the Scrum of Scrums include:

  • Impediments, especially program or organizational level
  • Inter-team dependencies
  • Upcoming milestones
  • Scope and schedule adjustments
  • Integration progress
  • Looming risks
  • Action items

Product Owner Sync

The PO Sync is the content-focused equivalent of the Scrum of Scrums. It is a practice performed even in smaller organizations working on the same platform. The purpose of the PO Sync is to ensure alignment of the product vision and work-related content across all involved teams. SAFe® and Scrum at Scale scaling frameworks recommend this synchronization event.

Product Owner SyncThe PO Sync is held 1 – 2 times per week for approximately 30 minutes. Each team sends their Product Owner to the PO Sync. If the multi-team program has a Program Manager, the Program Manager also attends to ensure the team efforts are cohesive and supportive of the program goals.

Topics discussed at the PO Sync include:

  • Functionality, performance, and interoperability
  • Scope and schedule adjustments
  • Feature prioritization
  • Validation of feature prioritization within the Team Backlogs
  • Coordination and scheduling of inter-team dependencies
  • Team progress on features
  • Decomposition of features to fit within a release
  • Minimum viable product set and minimum marketable feature set
  • Action items

Program Backlog

When multiple teams are working on the same initiative, it is important to establish the Program Backlog. For our purposes, the term “program” is a coordinated multi-team effort. The Program Backlog is a higher-level backlog different than each team’s Product Backlog. The Program Backlog is created and maintained by the Program Manager role or a Product Owner from one of the teams. The Program Backlog consists of features in priority order. All Agile scaling frameworks recommend this artifact.

Teams take the features from the Program Backlog and decompose them into user stories. The user stories then become part of the Team Backlogs. The order of the user stories within the Team Backlogs should reflect the feature priorities. Care should also be taken to allow each team to focus on one feature at a time as serial development is much more economical than parallel development.Program BacklogThe teams then develop the user stories comprising the feature across iterations. In the simplest approach, a feature is developed by one team. In a more complicated approach, a feature is developed by multiple teams, with each team developing their specific user stories while collaborating tightly with the other teams working on the same feature.

Dependency Identification and Scheduling

One of the biggest risks when scaling Agile is inter-team dependencies. To mitigate the risk associated with dependencies, teams working on the same program should plan together (iteration planning and/or release planning) to identify the dependencies between teams. Dependencies can also be removed or reduced by adjusting team composition to be more cross-functional.

Dependencies are bi-directional in that there is both a giver and a getter. To ensure visibility, each dependency should be tracked within the Team Backlogs as either a “Give” or a “Get”. Dependency Identification and Scheduling - "Give" and "Get"

A “Give” is where one team provides a specific deliverable to another team on or before a specified date or iteration. A “Get” is where a team receives a specific deliverable from another team by the specified date or iteration. A “Get” user story will typically involve integration activities across teams.

Care should be taken by the giving team’s Product Owner to prioritize the “Give” in advance of the recipient team’s “Get” in order to reduce the risk of developing both the “Give” and “Get” within the same iteration. As a general rule, the “Give” should be provided 1 or 2 iterations prior to the “Get” integration work. Also when integration work is occurring, the “Give” team should allocate some bandwidth to support the “Get” team with any potential issues found during integration.

Common Integration Environment

Finally, integration is key when multiple teams are developing the same product. You will need to establish a common integration environment for multi-team programs. Ideally, this is done prior to iteration 1 to ensure demonstration of working software from the integration environment each and every iteration.

Typical activities in establishing a common integration environment include server setup, continuous integration (CI) tooling, test case automation, and automated deployment migration.

As in any scaled Agile situation, integration should occur each and every iteration. The true measure of multi-team program progress is the level of integration, not the progress of each team in their local environments. Any approach that defers integration adds an unacceptable level of risk to the program schedule.

 

 

Start small and “think Lean” when considering how to scale Agile at your company. Over time, add in the additional constructs, policies, and approaches on an as-needed basis where it makes sense.

Scaling Agile is a crucial consideration of expanding beyond team-based Agile and pursuing enterprise agility. To ensure your success, call Agile Velocity. We have the appropriate experience in the various scaled Agile frameworks (SAFe®, DAD, LeSS, Scrum@Scale, and others) and can help you apply best practices for your specific needs.

What’s Your Organizational Agility Score?

In less than an hour, you’ll get valuable insights into your organization so you can improve team performance and achieve your business goals faster.

Learn more

Blog

Lean Economics 101: Parallel Development Is Killing Your Productivity!

By: Mike Hall | Apr 09, 2018 |  Article,  Lean

railroad tracks running in parallel

This is another in a series of blogs on the topic of Lean Economics, emphasizing the economic aspects of product development. You can find the first post about WIP limits here. 

 

As a developer, do you work multiple projects in parallel? As a leader, do you have a team which works multiple features in parallel? Is there more work than people?

Parallel Development is working multiple projects or features at the same time, as shown in the diagram below. It is a common situation I often see when coaching or delivering training. Parallel Development has, unfortunately, become commonplace in industry and accepted as the default standard way of organizing work as our work lives become busier and busier–just assign more and more projects to people, and hope they figure out how a way to get it all done!

Managing 3 high priority projects in parallel development

Often times when I query for reasons behind this type of work model, the refrain is a familiar “We have more work than people. Thus, our people need to be good enough to work multiple projects and show good progress on all of them.”

Parallel Development: The Efficiency Killer

There are many disadvantages to Parallel Development including:

  • Delayed delivery of business value
  • High cost of context switching
  • Inefficient work model
  • Low employee morale

 

All of this can lead to a frustrating work environment where employees are routinely interrupted to begin work on a new project with no regard to their current workload. Everyone is 150% (or choose your number) allocated piecemeal across multiple projects. If the feeling of “starting is common, but finishing is uncommon” is pervasive, then your current work model is economically challenged and likely needs a major adjustment.

In a Parallel Development approach, the business value of each feature is delayed as the team members routinely multitask by working on multiple projects and features as shown in the figure above. Time lost in context-switching can be more than time applied to business value. Often in this situation, the desire to “show some progress” to all stakeholders is deemed more important than delivering value at the earliest point in time.

Serial Development: A Better Way!

The good news is this: there is a better way! Serial Development is when the Agile team focuses on a single project and single feature at a time.

Advantages of Serial Development include:

  • Consistent, early delivery of value
  • Limited context switching
  • Focused development work
  • High levels of employee satisfaction

Serial Development requires courage!

It requires the courage…

  • to ruthlessly prioritize features–not only within the same project but comparatively across multiple projects as shown in the figure below.
  • to allow the team to focus their development efforts on one feature at a time.
  • to inform your stakeholders as to when their features will likely be developed instead of “We have started, but not much progress yet”.

And Serial Development requires courage in the form of coaching your stakeholders that Serial Development will help ensure that their feature(s) gets the development team’s attention at the absolute earliest opportunity based on prioritization.

Managing 3 projects with a prioritized team backlog

Comparison: Context Switching

Not convinced? Let’s compare Parallel Development versus Serial Development in terms of context switching. Parallel Development experiences significant context switching costs as the team members bounce back and forth across multiple features and projects trying their best to keep everyone happy. The generally accepted authority on the cost of context switching comes from the seminal book Quality Software Management: Systems Thinking by Gerald M. Weinberg.

n of Parallel versus serial development in context of context switching

In summary, if you are working on 5 projects in parallel, you are only 20% productive! Moving over to a Serial Development model will help you gain back the 80% productivity lost in context switching. Multiplying this by all members of your team can result in significant levels of productivity gain for the entire team!

Comparison: Value Delivery

Now let’s compare Parallel Development versus Serial Development in terms of delivery of value. I’ll use a simple example from one of our training courses. This example is feature-based but also applies to working multiple projects.

Setup: You work on a team that has a team backlog consisting of 3 features: A, B, and C. Each feature takes the entire team 1 month of time and delivers 1 unit of value. Let’s investigate the value graph across two scenarios – Parallel and Serial Development.

Scenario 1: Parallel Development with an assumed 40% context switching overhead (ref: Quality Software Management: Systems Thinking). The team multitasks across all 3 features making some progress each month (approximately 20% complete) while experiencing the context switching cost. At the end of month 1, no feature is completed. At the end of month 2, no feature is completed. Same for month 3, and same for month 4. Finally, at the end of month 5, the team delivers all 3 features.

Scenario 2: Serial Development focusing on 1 feature at a time. At the end of month 1, feature A is delivered. Context switching cost is minimized and occurs only during the planning associated with kicking off work on the new feature, e.g. during sprint planning and backlog refinement. The team delivers predictably, early and often, 1 feature per month. Delivered features continue their value month-to-month as the next feature is being worked on.

                                                        Parallel Development graph value over timeSerial Development graph value over time

Comparing the two value graphs, which is better in terms of value delivery and cost of delay? In the Serial Development approach, the customers not only enjoy the incremental value of the features delivered as soon as possible, but they receive all 3 features in total much earlier than in Parallel Development!

Comparison: Revenue

As a final comparison, let’s look at a simple revenue example. In the above graphs, assume each feature delivers $100,000 of revenue each month.

For Parallel Development, the total cumulative revenue at the end of each month is:

  • Month 1: $0
  • Month 2: $0
  • Month 3: $0
  • Month 4: $0
  • Month 5: $0
  • Month 6: $300,000

For Serial Development, the total cumulative revenue at the end of each month is:

  • Month 1: $0
  • Month 2: $100,000
  • Month 3: $300,000
  • Month 4: $600,000
  • Month 5: $900,000
  • Month 6: $1,200,000

For Serial Development, the total revenue at the end of month 6 is 400% greater than Parallel Development. The bottom line for this example – developing features serially delivers the business $900,000 in additional revenues!

Four Steps to Begin Serial Development

  1. Ruthlessly prioritize the feature requests across all project demands.
  2. Group the user stories in your team backlog based on a single feature for a single project.
  3. Pare the stories down to a minimum marketable feature that can be launched. Ideally, the team will be able to complete the highest priority minimum marketable feature in the next sprint (or two).
  4. Encourage swarming within the iteration to focus on a few high-priority user stories and complete them as early in the sprint as possible. Effective use of WIP limits can lead to swarming

 

Stop the madness! Parallel Development is wrought with waste and creates a chaotic environment for employees. Serial Development is a much more economical work model ensuring the earliest delivery of value to the end customer and higher employee morale. If your team members are currently mired in Parallel Development, then take action to shift over to a focus-based Serial Development approach. This may take a bit of courage and hard work, but the benefits are so well worth it.

For more on how you can build lasting business agility, you can check out our Transformation Services page.

 

Blog

Lean Economics 101: The Power of WIP Limits

By: Mike Hall | Mar 13, 2018 |  Article,  Lean,  Product Owner,  ScrumMaster

This is the first in a series of blogs on the topic of Lean Economics, emphasizing the economic aspects of product development.

 

I have a friend who once emphatically stated “Agile will never work at my company because we have more projects than people! Everyone here works on 5 or 6 projects at the same time. It’s important to show some progress on all efforts to keep everyone happy.” Do you have firsthand experience being in this situation? I’ll share my response to him at the end.

The concept of Work In Process (WIP) – also called Work In Progress – comes from the world of Lean manufacturing. In Lean manufacturing, WIP is considered a form of inventory – the materials that are currently being worked. As such, it is actually considered “waste” because it ties up cash. That’s right – WIP is waste! It needs to be reduced.

Effective Use Of WIP

Effective use of WIP is when the team takes on a small amount of work, focuses on it, and works it to completion in a short period of time before pulling any additional work. This approach enables a consistent flow of value from the team (as indicated in the diagram below) and is considered much more desirable than context switching across multiple efforts in parallel.

WIP: Working items in parallel or priority order

Warning Signs You May Be Ignoring Lean Economics

Warning signs that you might not be considering the economics of product development include:

  • Many things started, but very little finished recently
  • Heavy multitasking
  • Costly context switching
  • Slow, painful deliveries
  • Lack of accuracy when predicting delivery scope and dates
  • Low product quality and constant rework

All of these add up to a very frustrated team overloaded with work that just seems to never get completed. Reliance on “heroes” is the norm. Overtime is rampant. Customer satisfaction is dropping. Stakeholders are screaming. We scream back: “We need more people!”, or better yet “Please just let me focus on one thing at a time!”

What is a WIP Limit?

The amount of work occurring at any one time is “limited” to what the team can accomplish in a short period of time and established by a constraint called the WIP limit.

A great description of the economics of WIP is described in Donald Reinertsen’s seminal book The Principles of Product Development Flow. At the time of this writing in 2008, less than 1% of all product development teams were managing WIP constraints. With the success of Agile methods and a renewed focus on the economics of product development, this number has improved greatly over the past years.

Most teams use a default WIP limit according to the available capacity of the team and what makes sense for the effort at hand. Development teams can set their WIP limits for the number of user stories (or tasks) in work at any one time. This WIP limit can provide opportunities for pairing and cross-training.

A Program Management team may have a WIP limit for the number of features being researched, the number of features ready for development, and the number of features currently being deployed. As you move into higher levels of planning in the organization, from individual programs to whole portfolios of programs, executives and business owners may have a WIP limit for the number of business cases being developed, the number of initiatives being considered for funding, and number of initiatives in development at one time. This level-by-level WIP approach helps to create an alignment of available capacity to the demand, and also provides a very important visible indicator as to what initiatives are truly being worked on and even more importantly, which ones are not!

Who sets the WIP limit? WIP limits are determined by the teams involved in the work at their respective level (team, program, or portfolio). Thus, team members at each level need a basic understanding of Lean economics and how adjusting the WIP limit can impact the flow of value – both positively and negatively.

What is the Right WIP Limit?

A WIP limit that is too small will result in idle workers and minimal flow of value. A WIP limit that is too large will result in delayed delivery and increased average cycle time (time from work starting until done). A WIP limit that is “just right” will result in optimized value flow and predictable delivery cycles. Often times finding the optimal WIP limit takes a bit of trial and error.

WIP limits can be adjusted from time to time in an experimental attempt to drive even higher levels of value. For example, an Agile team of 7 developers may adjust their “in work” user story WIP limit from a default of 7 down to 3 to ensure that a healthy amount of “swarming” is occurring on the highest priority user stories committed for the iteration. This supports the concept of demoing stories to the Product Owner as early in the iteration as possible and the possibility of continuous deployment. WIP can also be adjusted downward to account for the typical vacations and personnel outages that teams experience.

Visualizing WIP

WIP limits can be applied as work flows through the different stages of development. A common team-level storyboard example follows with WIP limits indicated in the appropriate columns. These WIP limits cannot be exceeded, forcing team members to consider helping others in pursuit of the larger goal of getting a user story to Done over beginning a new one.

WIP limits on the Kanban board

Teams at the program and portfolio levels use the same technique with their specific column names and WIP limits.

What’s the Big Deal?

Applying WIP allows us to “stop starting, and start finishing”. Some advantages of WIP and the use of WIP limits include:

  • Improved flow of value through your team pipeline
  • Productivity gains due to less context switching
  • Ability to focus
  • Identification of bottlenecks and waste – leading to subsequent remedy
  • Improved cycle time
  • Promotion of cross-training and less reliance on “heroes”
  • Encouraging a focus on quality!

Conclusion

Now, regarding my friend’s comment about working 5 or 6 projects at once – I used the left hand portion of the first figure (“Working on many items in parallel”) to explain that his approach was making some progress on many things, and every time period check would hopefully show an adjustment in the horizontal progress bar. I deemed this approach “moving yardsticks” instead of truly completing work. In the end, all (yes, all) of his project stakeholders will end up disappointed to varying degrees. I then explained the tremendous cost of context switching across multiple efforts (ref: Quality Software Management: Systems Thinking). I also pointed out that his leaders were suffering from an unwillingness to make tough prioritization decisions, and that this often requires a cultural change at the leadership level – stay tuned for future blogs in this series discussing these concerns.

After a few more (lite) beers to let it all sink in, I explained the good news – there actually is a much better way! Organize all of the work into a single team backlog. Prioritize the work such that single features/stories can be worked to completion and context switching is reduced. Apply WIP limits at all levels (team, program, and portfolio) to ensure a healthy flow of value through the team’s work pipeline. And then say goodbye forever to unmet expectations!

 

Blog

7 Scrum Guide Observations, Loopholes, And Interpretations For The Practical Agile Team

By: Mike Hall | Sep 13, 2017 |  Article,  Scrum

Man reading the scrum guide

As a 15-year Scrum practitioner, I try to revisit the official Scrum Guide, sometimes referred to as the “Scrum Bible”, to make sure I stay on top of any updates associated with the framework roles, events, artifacts, rules, and underlying philosophies. This time, I uncovered 7 interesting observations Scrum teams can use in their day-to-day activities.

#1: Developer Can Proxy The Product Owner Role

After clearly spelling out the Product Owner (PO) responsibilities such as expressing and ordering backlog items, the Scrum Guide states, “The Product Owner may do the above work, or have the development team do it. However, the Product Owner remains responsible.”

In a situation where the PO is unavailable or leaves the team, the developer could play the PO role for a short period of time. In general, we do not recommend that the Product Owner role be proxied, but it never hurts to be better prepared for unique situations such as these. One way your team could improve is to ask a developer to perform or shadow the PO role for a Sprint or two in order to better understand how the role operates and how the product vision influences the product backlog.

#2: There Is No Rule Preventing Inconsistent Sprint Durations

We all know that consistent durations for Sprints (e.g. 2 weeks) is preferred and logistically practical. I would have guessed that the official Scrum Guide makes it clear with a rule that states something like, “All Sprints must be the same length.” Not so.

What the guide does say is this: “Sprints best have consistent durations throughout a development effort.” That leaves open the possibility for a different length Sprint – but obviously only when it makes sense.

Knowing this flexibility is built in, your team can use it judiciously from time to time. For example, having a 3-week Sprint over the Christmas holidays may make sense for your team instead of following a religious 2-week Sprint. Of course, it is never a good idea to extend the length of a Sprint in order to complete unfinished work.

#3. Scrum Is Silent On What To Do With Unfinished Work Except In The Case Of A Canceled Sprint

Many teams just naturally assume that unfinished work in a Sprint automatically goes into the next iteration. Several popular Agile tools are instrumented with the default behavior of splitting unfinished work items into the current Sprint (what was completed) and the next Sprint (what was not completed). The Scrum Guide is strangely silent on where this unfinished work goes except in one specific case – when a Sprint is canceled. In this case, the Scrum Guide states, “All incomplete Product Backlog items are re-estimated and put back on the Product Backlog.”

It is probably safe to assume that the same is true even if the Sprint is not canceled – unfinished work goes back to the Product Backlog for discussion in the Sprint Review and consideration for selection in the upcoming Sprint Planning event. It is entirely possible that unfinished work from one Sprint is not selected for the next Sprint, so consider moving unfinished work to the Product Backlog to give it a chance to be discussed again within the context of your latest priorities.

#4: Sprint Goal Is Crafted During Sprint Planning After The Development Team Chooses Backlog Items

Perhaps your team starts Sprint Planning with the Product Owner announcing the Sprint Goal.  Or worse, your team does not even bother with establishing a Sprint Goal. A Sprint Goal is important because it explains why the current product increment is being built. It can also be used as a cross-check reference point for all work going on within the Sprint. The Scrum Guide says, “After the Development Team forecasts the Product Backlog items it will deliver in the sprint, the Scrum Team crafts a Sprint Goal.” As you can see, the entire Scrum Team participates. And, it follows the selection of the Product Backlog items (not before).

#5: Daily Scrum Discussion Points Are Within The Context Of The Sprint Goal

Chances are your team holds a Daily Scrum where each team member speaks about what they did yesterday, their plan for today, and discusses any impediments. Some teams use a context of the Product Backlog work item, while other teams use decomposed work (tasks) as their discussion context.

The Scrum Guide lists three topics for each developer to discuss:

  •      What did I do yesterday that helped the Development Team meet the Sprint Goal?
  •      What will I do today to help the Development Team meet the Sprint Goal?
  •      Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

As you can see, the discussions should all be within the context of the Sprint Goal. Not a task, not a story, not a work item. Your team can improve by making the Sprint Goal visible, phrasing their statements in the Daily Scrum around the context of the Sprint Goal, and ensuring there is no potential work being discussed outside of the Sprint Goal.

#6: The Result Of The Sprint Review Is A Revised Product Backlog

Is your Sprint Review a demo only? Is the result a thumbs-up or thumbs-down on what was demonstrated? The Scrum Guide says, “The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint.” It describes the Sprint Review being a discussion of what was accomplished and not accomplished, problems encountered, solutions found, demo of working software, discussion of the Product Backlog, and all attendees (Scrum team and key stakeholders) collaborating on what to do next! As you can see, much more than a demo. This collaboration leads to a revised Product Backlog.

Take full advantage of having the key stakeholders present in the Sprint Review. Leave plenty of time to review the Product Backlog, collaborate with all attendees on what to do next, and yes, even adjust the Product Backlog right then and there to indicate the consensus.

#7: During Sprint Planning, Work Decomposition Is Done Only For The First Few Days Of The Sprint

This was the biggest surprise to me, a person with 15 years of experience using Scrum. As we all know, the second part of the Sprint Planning event is for the Development Team to decompose the selected Product Backlog items into a collection of bite-size chunks of implementation work. The Scrum Guide says, “Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less.” In other words, the Development Team decomposes only enough to cover the first few days of the Sprint during Sprint Planning. The unstated assumption is that the other work items selected for the Sprint will be decomposed during the Sprint as needed.

This approach encourages the Development Team to “swarm” the highest priority work items, completing them all the way to “done” before addressing the next set of selected Product Backlog items. However, it brings up an obvious challenge – if the team is expected to track remaining hours of work within the Sprint (as described in the Scrum Guide), how can this be done effectively unless all work items are at least preliminarily decomposed and estimated during Sprint Planning?

Final Thoughts

Let’s take it to the next level with an even deeper understanding of Scrum. By incorporating one or two (or all) of these interesting observations from the Scrum Guide, your team can improve their productivity and delivery effectiveness.  I challenge each reader of this blog to reread the official Scrum Guide. What new learnings did you find that are surprising or seldom used in your experience?

For more on Scrum and building lasting business agility, you can check out our Transformation Services page.

Blog

The True Cost of a Non-Safe Team Environment

By: Mike Hall | Jul 11, 2017 |  Article,  Scrum,  Team

Person drowning in a sea of uncertainty and stress caused by an unsafe team environmentA few years back, I experienced what I will call “the true cost of a non-safe team environment”. I was working on a program-level initiative and had worked up an email (names changed to protect the innocent) to a remote member of our team that reads something like this:

“Barb – we really need a Product Owner Sync meeting for our larger programs. I can start documenting this tomorrow. Your thoughts? Thanks, Mike H.”

Total time: 1 minute (hey, I type with two fingers only!).

Right before hitting the SEND button, I was hit with a jarring set of recollections…

I recalled instances in which my words had been misunderstood within our team, and times where my words were met with retribution and ridicule. I remembered getting halfway through my first sentence and being cut off once the listener figured out what point they thought I was going to make (they were wrong). I remembered struggling to get a word in edgewise because as a team, quite frankly, we were poor listeners.

Then there was that time when I offered up what I thought was a helpful suggestion and the idea was misinterpreted causing a long circuitous conversation for clarity. There was that feeling of assumed negative intent.

Then I recalled a time where I made a polite casual comment for everyone’s awareness and was immediately labeled “negative”.

After a few minutes of pondering the lack of safety amongst our team, I yearned for a team environment where safety and courage were first-order values. I thought about times in the past where I had been part of high-performing Scrum teams where team safety was the norm. Then I crash-landed back to reality.

If I hit SEND:

  • She may think I am complaining.
  • She may already be aware and think that I am obtuse (with apologies to Shawshank Redemption)
  • She may think I am trying to show off my knowledge
  • She may think I am pointing out the deficiencies of the current team for not recognizing this previously
  • And finally, she may think I don’t have enough to do (the horror!).

So, what to do? I began a laborious edit on my email to ensure that (hopefully) nothing could be misconstrued or taken the wrong way. My newly crafted email ended up like this:

“Barbara – thank you so much for all you do. I just love working on this team!

Yesterday’s discussion on the scaling aspects of our Agile transformation was great. As the resident expert on scaling Agile, how do you think it went? As I investigate the different scaling approaches out there (SAFe, Nexus, LeSS, etc.), I am noticing a trend towards maintaining synchronicity between all team Product Owners involved in the program. Do you notice the same? I have experienced this in the past, but since I am relatively new to this team and don’t yet have the full picture of the program context here at <business name withheld>, I’m not sure if it applies or not. I am very curious about your experiences.

If your experiences are similar to mine, then how would you recommend we convey this information? Should we do an update of our Program Synchronization artifact, or a lunch & learn, or a small class segment on the topic? How are these situations typically handled? Or, is it even worth pursuing right now given the challenging situation of our current priorities?

As you can see, the intent of this email is to explore the possibility that there might be a potential need for our program managers managing the larger programs. I’m not sure at what point the size issue tips over into this need, but I thought I would check with you first. I am aware that you have worked closely with many/most of these large program leaders in the past, so hopefully, you will be able to provide me with some directive guidance.

Please advise. Have a great day, and I am looking forward to our next face-to-face discussion.

Thanks, Mike H.

Total time: 2.5 hours due to wordsmithing and imaginary role-playing to reduce anxiety. From 1 minute to 150 minutes. If my math is correct, that is a 14,900% increase in waste. Lean purists are rolling over in their graves right now!

I finally pressed the SEND button. Several of the Scrum values came to mind as I heard the swoosh of a successful send, most notably:

  • Courage – the willingness to create an environment of psychological safety where team members can speak their minds without fear of retribution
  • Openness – be open about the work and our interactions with others, no hidden agendas
  • Respect – every team member is capable and deserves our respect, always assume positive intent

I like to think of my work team as an extension of my family. The best work situations occur when there is a family-oriented environment embodying the Scrum values mentioned above. In families, we have courageous and difficult conversations every now and then. Feelings sometimes get hurt, but we mend it. Our intentions are understood to be honorable. We rely on love and mutual support to move forward – for the greater good of the family.

Scrum teams should feel more like an extension of our families. One way to achieve that is to ensure that your team is safe.

If you are an Agile leader or influencer, you can help your team embody safety by:

  •      Making your team values both visible and compelling
  •      Embracing diversity of thought – it leads to better decisions
  •      Requiring respectful listening skills
  •      Making sure retrospective topics about team safety are prioritized very high
  •      Removing the fear quotient – demonstrate (again and again) that this is a safe team
  •      Demonstrating vulnerability – admit to your own mistakes and preconceived notions
  •      Viewing failure as a learning event – celebrate each in a small but meaningful way
  •      Calling out situations where someone is not assuming positive intent
  •      Understanding that healthy conflict is good – it grows our team
  •      Publicly thanking team members for constructive feedback.

It’s not just about adopting Agile practices. An successful Agile transformation also involves assessing if your organization’s current culture supports agility. Our assessment services help leaders understand if they have the processes, systems, and culture in place to sustain adoption and nourish long-term agility. Learn more about Agile assessments here, including additional benefits. 

Blog

XP Values – The Forgotten Agile Guidance!

By: Mike Hall | Jun 21, 2017 |  Article,  Team,  Technical Practices

XP Values Diagram featuring Courage, Feedback, Respect, Communication, and SimplicityWhen you hear the term “extreme programming”, what do you think of? Coding while skydiving at 15,000 feet? Bug-fixing while scaling the north face of Kilimanjaro? Refactoring while swimming with sharks at the Great Barrier Reef?

For tech nerds like me, we probably think of the wealth of technical practices espoused by this Agile method. These technical practices include stories, pair programming, slack, continuous integration, test-first, and others. Extreme Programming (XP) practices are typically used within a Scrum or Kanban team to help ensure high levels of software quality and continuous integration.

(more…)