Practical LPM with Jira Align

I’m very excited to post this recording of a talk I did for the Agile Richmond conference.

This talk gives 5 key ideas from SAFe’s LPM training class, and shows how to put them into practice using Jira Align. These are two topics that I’m very passionate about, so it was a lot of fun to put them together for this talk.

Please take a look below!

2020 Scrum Guide Updates

Why the Scrum Guide?

On 11/18, a new version of the Scrum Guide was released. This was the first major revision since 2017! This is the location where Ken Schwaber and Jeff Sutherland come together to agree upon “What is Scrum?”

Most (all?) major Agile scaling frameworks build on Scrum. It’s amazing how many Scrum Masters aren’t actually familiar with the Scrum Guide!

The Scrum Guide calls out 7 major changes to the Scrum Guide, which I’ve condensed into the 6 topics below:

1. Lighter & Less Prescriptive

The Scrum Guide is down to 11 pages from 17, and has been made more broadly applicable. Language referring to software has been removed, and simpler language has been implemented.

The Scrum Guide seems to be moving to be more broadly applicable across domains and contexts. The Scrum Events are less prescriptive than they previously were. For example, the Three Questions have been removed from the Daily Scrum section.

These small changes will allow the Scrum Guide to be applicable in more domains, which can only be a good thing for Scrum.

2. Sprint Goal, Definition of Done, and Product Goal Linked to Their Artifacts

This is perhaps the most consequential change to the Scrum Guide. While all three Commitments existed before, they were loosely defined. They’ve been called out explicitly as “Commitments” and tied directly to the Scrum Artifact of which they support.

Each Artifact can be thought of as a unit of delivered work. Each Artifact now has an associated commitment that allows Stakeholders and the Scrum Team to understand what is expected within the Artifact.

ArtifactCommitment
Product BacklogProduct Goal
Sprint BacklogSprint Goal
IncrementDefinition of Done

This addition will be a great reminder for teams about the different levels of commitments that exist within the framework. I hope this encourages Scrum teams to avoid glossing over these important commitments.

3. Product Goal

“The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against”

The Product Goal is completely new terminology that is referenced in the change listed above about commitments and emphasizes the importance of having a longer-term vision for your product.

Though it seems obvious to look ahead, it’s very easy for Scrum teams to lose the forest for the trees while executing their sprints. In my opinion, one of the many reasons that Agile scaling frameworks are so popular is to help support long-term planning. I love that the Scrum Guide is being more explicit about the importance of longer range planning.

4. One Team

The phrase “Development Team” has been removed from the Scrum Guide to avoid the idea of a “team within a team”.

In practice, I often hear the phrase “core team,” which is another key signal of the existence of a team within the team.

The Scrum Guide has made some subtle changes to drive home the idea that there is a single Scrum Team with 3 roles – a Product Owner, a Scrum Master, and Developers. Developers is explicitly defined as any team member who does the work, even though it is very software-specific language. I do wonder if this language will change to be more generic in a future Scrum Guide update.

5. Self-Managing Instead of Self-Organizing

This is a change that is so subtle that I’m not sure why the authors called it out as one of their most important changes. The terms are generally interchangeable in common usage, and even the Agile Manifesto Principles use the term “Self-Organizing.”

The authors of the Scrum Guide believe that self-organizing means that the team defines when and how the product is built. They believe that self-managing means that the team defines when, how, and what is built (emphasis mine).

I believe this is intended to reinforce the change listed above about One Team – reemphasizing the idea that the Product Owner is a part of the Team and the Team is defining what gets built.

6. Sprint Planning Addition – “Why”

Answering the questions “What” (can be built) and “How” (will it get done) have always been a part of the Sprint Planning event. With the new update, the question “Why” has been added – instructing the teams to answer the question “why is this sprint valuable?”

I think this is a great addition to remind teams not to hyper focus on the tactical things being built – similar to reasoning behind the Product Goal.

Final Thoughts

A lot of these changes are subtle, but I do think they are moving the Scrum Guide forward, which is always great. I look forward to see what future enhancements will be made in future versions.

Parkinson’s Law & Agile – How to Use the “Uh Oh Effect” to Promote Agility

What is Parkinson’s Law?

Parkinson’s Law is a rampant idea, though many don’t know the idea by this name.  Parkinson’s Law states that:

“Work expands so as to fill the time available for its completion”

Parkinson’s Law was proposed by Cyril Parkinson in 1955 in a satirical article that mocked government bureaucracy, so it was likely never intended to be taken seriously. [1]

However, this idea often has legs.  After all, we’ve all had experiences where a time crunch inspires an amazing amount of work to be completed in a short amount of time. Maybe you managed to learn a semester’s worth of material in the week leading up to the final exam. Or had a project with a tight deadline that inspired a heroic effort.

Or perhaps you’ve been on the flip side of this law, where work without a deadline expands:

Parkinson’s Law is Supported by Science

Evolution Research Sets the Stage

It turns out that Parkinson’s Law is actually supported by science.  The story beings with research on evolution from Niles Eldridge and Stephen Gould.

The prevailing theory of evolution was that it occurred in a smooth, upwards progression. Eldridge and Gould discovered that for many species, evolution was not a smooth progression, but long periods of relative stability with short bursts of change. This is called the “punctuated equilibrium” model:

Gersick Discovers the “Uh Oh Effect”

Connie Gersick was researching organizational behavior to discover how teams complete projects.  She studied 8 groups of teams of various size (3-12 people), different project lengths (7 days to 6 months), across different domains.

She found that progress was not linear like the phyletic gradualism model. Instead, the groups made progress that resembled the punctuated equilibrium model – long stints of stagnation followed by bursts of intense progress. [2]

The interesting finding is that what prompted the shift was consistent across the groups. It was the halfway point of the deadline.

We call this the “Uh Oh Effect” – seemingly halfway through the course of the project, the teams collectively said “Uh oh,” and adjusted their approaches to allow more effective progress.

How to Leverage the “Uh Oh Effect” for Agility

People don’t like to talk about Parkinson’s Law, or the “Uh Oh Effect” in the context of organizational Agility because it often promotes waterfall-like behaviors.  Leaders use this idea to set overly-ambitious deadlines for big chunks of work to ensure that work gets done in a timely manner:

This is inherently waterfall behavior, but I also argue that it’s inefficient. Remember, based on Gersick’s research, that regardless of project length, the first half of the project is largely ineffective. Only at the temporal midpoint does the team say “Uh oh,” and identify more effective ways of working, and make huge movement forward in a punctuated equilibrium type of progress.

I believe knowing about Parkinson’s Law and the “Uh Oh Effect” should lead us to thinking in smaller units of work and smaller time blocks. Remember, that the first half of the timebox isn’t very effective, regardless of the size of the timebox. So use smaller timeboxes to increase the numbers of “Uh Oh’s” that your team gets.

 

[1] https://medium.com/the-mission/parkinsons-law-why-constraints-are-the-best-thing-you-can-work-with-4fad6e0e91cf

[2] https://files.eric.ed.gov/fulltext/ED504567.pdf

Roman and Greek Team Norms Session

I made this clip to document a technique I created to run a Team Norms building session for a team.  It’s a two-part technique that allows for rapid brainstorming for the first half and a deeper dive into tricky team issues for the second half.

 

This technique was a big hit with my team, and I think this is a great technique if you’re going to run a team norms session for your team!

 

12 Agile Principles

While this is too much content to clone onto this forum, myself and 2 colleagues put together a nice series on the 12 Principles of Agile. This series tackles common problems that organizations face in achieving each Principle.
This series is near and dear to my heart. I find that working with the 12 Agile Principles can be a great guiding light to fostering better Agility.

Check out the first part of the 12 part blog series here!

The Three Things Agilists Can Learn From Wonder Woman

Paradise Island

Superhero stories are the parables of our time and that’s why even mere mortal Agilists can learn some lessons from these crusaders. Don’t worry if you don’t have a tiara or a lasso of truth; there are still plenty of things you can learn from Wonder Woman.

Let’s set the stage–Diana Prince, Wonder Woman, lives in Themyscira on the Paradise Islands among the Amazons. The Amazons are warriors who spend most of their time training and consider themselves the most elite fighters in the world. The Paradise Islands are living up to their name until one day, the German army arrives. Which shouldn’t be a problem, right? These are the most elite warriors in the world. But unfortunately, that doesn’t end up being the case.

The Germans have guns and the Amazonian archers aren’t equipped to handle that tech. Eventually the Amazons do win, but it takes a literal heroic effort from an actual superhero to help them make it through this battle.

Get Off the Island

The first agile lesson we can learn from this scene is to get off the island. As lovely as that island is or maybe your comfort zone is– don’t isolate yourself. As an Agilist, make sure you’re working within your community and going to local meetups. Being involved can help you stay relevant and frankly more Agile.

When the Germans begin firing their weapons, you can see the bewilderment on the faces of the Amazons. Don’t be like the Wonder Woman here; make sure you’re getting out there and seeing what is new. It will keep you from watching the bullet fly right by your face. You don’t want the first time you’re seeing a piece of technology to be when it’s already starting to overtake you.

Make Sure Your Goals Are Clear as a Team

Were the Amazons really trying to be the best warriors in the world or the just the best archers? It seems if they had aligned their goals they might have been better prepared for this unexpected attack. When you’re working with your teams think about what your end goal truly is. Make sure you align everyone with what you are trying to do and make sure you know what you’re striving for.

Don’t Let Superhero Syndrome Mask Your Deficiencies

Everyone has probably been a part of a project where you witnessed the superhero mentality. This is when someone comes in and pulls all kinds of crazy hours to save a project last a minute. As Agilists, we want to make sure that even if we do get saved by a superhero that it doesn’t stop us from continuously improving. After this battle, do you think the Amazons actually learned about this new technology and leveraged it in their future battles? I’m not sure, but I do know that if you stop learning and improving as you go along it’s easy to be left behind.

What’s New in SAFe 4.5?

SAFe version 4.5 was released on 6/21, and I’ve been excited to dig in and see the changes.  Check out the official site for more details on change.  Here are some of the changes I’m most excited to see.

Making SAFe Easier to Handle

Big Picture Scaling

The SAFe 4.0 Big Picture can be overwhelming, especially when expanding to 4 levels.  SAFe has made 4 different views of the Big Picture that limit the focus of the model, depending on the organization’s need.

Part of this change gives better guidance to organizations on how to adopt subsets of the full Big Picture.  With this change, SAFe has adopted some of the lean agile mindset to the process of adopting SAFe – start with an MVP, and build Features on top of that as needed.

Implementation Roadmap

This isn’t 100% new in 4.5 – the implantation roadmap did exist in 4.0 as well. However, the Roadmap has replaced the implementing 123 article on the Big Picture.

SAFe has recognized that there’s more to implementing a successful SAFe environment than simply training all the relevant people involved.

There’s a specific emphasis in the new roadmap on identifying Value Streams and creating ARTs within the Value Streams – a hugely important factor to get right up front.  ARTs aren’t particularly helpful if they aren’t properly aligned with a value stream.  Either you have multiple value streams within an ART, which weakens the power of an ART, and creates a divide.  Or you could have an ART where the value stream actually cuts across multiple portfolios, which creates a huge mess.  Getting this right up front saves a huge amount of time and frustration for the teams and programs, so it’s great that SAFe has baked this into the implementation guidelines.

Lean Startup Mentality

SAFe has explicitely and heavily incorporated the lean startup idea into the model.  There is a newly placed emphasis on incorporating the “Build-measure-learn” lean startup cycle (which SAFe has expanded to “Hypothesize-build-measure-learn”) into all levels.  This has caused a number of small and larger changes to the model.

Lean Startup Cycle

This is one of my personal favorite changes to the SAFe model.  SAFe has tied the lean startup model directly across the Portfolio and Program layer.  This emphasizes one of the underlying principles of Agile – build lean, release, and only build more features if the MVP is worth building upon.

It also clarifies that work continues on the MVP until the tradeoffs suggest working on something else more valuable.

Continuous Delivery Pipeline and Dev Ops

SAFe has recognized that to release lots of MVPs, you need to have the Continuous Delivery Pipeline and Dev Ops to support it.   SAFe explicitly calls out both of these on the big picture to emphasize the importance.

Other Goodies

Compliance

SAFe has added an Agile version of Compliance to the Big Picture.  Compliance often lives in a Waterfall world, clashing with IT efforts to run Agile.

This is a great first step, and I hope that SAFe will look into other regulations that large enterprises face that often run in Waterfall, such as legal reviews.

SAFe Program Consultant (SPC)

The SPC has been added to the Big Picture.  SAFe is recognizing the need for additional help beyond the existing roles to help stand up and perpetuate a successful SAFe implementation.

I would encourage organizations to be careful about falling into the “Certification Trap.”  While a few of the training activities require an SPC to deliver, the majority of the SPC responsibilities can be executed by an experienced non-SPC coach.

SAFe 4.5 – A Leaner, More Experiment Heavy SAFe

The two major themes in SAFe 4.5 are an emphasis on experimentation through the Lean Startup Mentality and creating new tools that make SAFe itself scalable depending on the size and needs of the organization.  SAFe has leaned itself down as small as the Essential SAFe level.

Organizations that are considering SAFe can now combine these two mentalities in their adoption of SAFe.  They can start small and lean with an MVP of Essential SAFe, and evaluate the experiment.  If it works well, they can add new features to a larger version of SAFe, or abandon the experiment entirely.

With SAFe 4.5, I hope that organizations are now able to take these lean, experimental ideas not just into their software development, but also into their own adoption or expansion of SAFe.

Shifting Gears – Why and How to Shift your Team-Level Culture During your SAFe Innovation and Planning Iteration

Gear_Shift_1

SAFe is…well…safe

Traditionally, Iterations in a SAFe Program Increment are dedicated to delivering on User Stories and Features.  The ideal team is stable and has good, broken down work that allows for consistent delivery Iteration after Iteration.  The last thing any Scrum Master wants to see is a Velocity chart that looks more like a seismograph.

When teams get to consistent User Story delivery, the hope is that they can deliver Features consistently over the course of a PI. When talking about nailing the basics, one of the first things mentioned is meeting commitments on a regular basis.

In order to set up teams for consistent delivery, a conservative culture often develops in SAFe environments (and I’m not the only one to observe this).  SAFe encourage User Stories and Features that are well-defined, well-understood, and have minimal uncertainty.  Teams make sure their User Stories and Features are as refined as possible before committing to them in a PI or Iteration.

Conservative Culture Doesn’t Promote Innovation – and SAFe Knows This

This conservative Culture isn’t necessarily a bad thing.  Remember, it’s stemming from the lofty goal of consistent delivery.  However, it’s important to recognize that this Culture is not conducive to innovation.

The flip-side of encouraging consistent delivery is that risk taking is inherently discouraged. Anything inherently risky or uncertain is encouraged to be better refined.  This gives us predictable delivery, but how innovative can our delivery be if we’re not taking any risks?

SAFe explicitly recognizes that innovation may not really be possible during normal delivery Iteration by saying “finding time for free association and innovation in the midst of delivery deadlines can be difficult.” And they put their money where their mouth is by building in time in the PI to dedicate to innovation.

If We Really Want Innovative I/P Iterations, We Need to Deliberately Shift Culture

After 10+ weeks of conservative, consistent delivery, what are the odds that people will naturally shift into a mindset of innovation for 2 weeks?  As Agile leaders, we need to be deliberate to shift our Culture during the Innovation Iteration; otherwise, there’s a serious risk that the conservative Culture of the normal delivery cycle will bleed into the Innovation sprint.

How Can We Shift to Promote an Innovative Culture for Just One Iteration?

Hackathon

Hackathons are a common way of leveraging the Innovation Iteration to encourage novel thinking in a fun environment.  I recommend any hackathons leverage the SAFe encouragement for them to be free-form – allowing team members to work on whatever they want with whomever they want.  This is a clear shift in Culture from the hyper-organized environment during delivery sprints.

Make Time to Celebrate Failures in the Hackathon

There’s evidence that embracing failures helps encourage innovation.  If failure is actively discouraged, what incentive is there to stick out with an innovative idea if you’re likely to get hammered back down?

Take time to reflect what is being celebrated in your ART’s hackathon.  I worked with a client who celebrated the most successfully executed Hackathon deliverables, which was a great idea and added to the fun of the hackathon.  But what incentive is there to risk a truly innovative idea if only the successes are celebrated?

I encouraged the client to not just celebrate the successes, but also the failures.  We want to encourage Hackathon teams to dream big and try to build something that may not pan out.  We even implemented a “shoot for the moon” award – based on the phrase “shoot for the moon, even if you miss, you’ll land among the stars” – as a way of celebrating a Hackathon team that dreamed big, but didn’t quite hit their mark.  What a way to truly shift culture for your Hackathon Iteration by actively rewarding failed ideas. Could you imagine something like that in a traditional SAFe PI?