Change The Culture, Change The Game

I was first exposed to the change pyramid in 2013 and still think of it often. I’ve had a fascination with how people interact with change and what makes it succeed or fail. I firmly believe that organizational change approaches for Agile transformations (or any effort) need to be flexible and responsive while allowing stakeholders, change agents, and change participants to pragmatically start from where they are. Many organizations want to change the culture. That’s a step in the right direction—getting warmer! But they focus on processes—getting colder. Processes are dynamic and change often. Culture is a behemoth that can outlast the cleverest of tactics.

In 2014, I spoke at the Global Scrum Gathering about the concept outlined in this pyramid. In essence, if you want to change the culture, you have to start by creating new experiences. What people experience builds their belief system (hot pan = ouch). Someone’s beliefs determine how they will act (hot pan = ouch = don’t touch). The sum of a group’s, department’s, or organization’s actions establishes a culture. So, rather than focusing on changing processes, which can result in severe resistance, try to create new experiences for employees. Demonstrate to them that they are capable of achieving something new. Help them connect the dots on how an iterative approach could help solve their most pressing problems. The result of the session at the Scrum Gathering was a packed room with attendees standing along the back and side walls. We were met with a standing ovation, which completely took me off guard, but it made me realize that we might be onto something.

Therefore, I now approach change through an Agile Experimentation Framework. I’ve found that this framework can be applied from a single team up to an enterprise. The Agile Experimentation Framework is simply this:

  • Identify the opportunity
  • Build an actionable hypothesis
  • Quantify how you will measure success
  • Set a timebox
  • Measure the results
  • Accept, reject, or pivot on the results.

How does this relate to the change pyramid, though? Actionable experiments tap into an employee’s growth mindset by making them a part of the problem-solving process. Presenting an employee with a process change has a much higher likelihood of being met with resistance if their experiences and beliefs don’t align with what is being proposed. Approaching it as an experiment can relieve apprehension for someone who is not open or aligned with a process change. Setting a timebox and measures for the experiment affords a legitimate option to “revert” or to keep inspecting and adapting with precision.

I believe that establishing an experimentation framework is an effective way to accelerate work culture advancement that will support visionary ways of working.

Futurespective: A Retrospective 6 Months In The Future

“The difference between dreaming and achieving a goal is having a plan with accountability.” -Every Inspirational Leadership Book EVER Written

Are you looking for a powerful exercise to help jump-start your team or organization’s continuous improvement efforts? Are you feeling stuck in a rut? Or are you just looking to mix up your retrospective format to keep things fresh? If so, tap into your creative side and let’s take a trip into the future.

Setting the stage

Imagine that we are 6 months in the future and you have a peek into how the team/program/department is performing. We have achieved our business goals, our staff is engaged, and customer satisfaction is at an all-time high. How did this happen? Given we don’t have a time machine, we will have to use our brains and imagination to figure out how we got to this ideal state. Think through the following questions and write down your answers.  Then we will review them all together to create a shared understanding and vision for the future. 

  1. What’s the common goals everyone was moving towards?
  2. What did we do start doing or do more of?
  3. What did we do stop or do less of?

Facilitating the exercise

Prep:

  • Write the three questions below on large sticky note posters or on a large whiteboard.
  • Bring regular sized sticky notes and pens and lay them out for participants.

During the exercise:

  • Set the stage by explaining the exercise.
  • Have participants start creating sticky notes (one item per card)
  • Try to group into clear themes as they are being placed on the board.
  • Do a readout of the cards, and quickly allow for clarification by submitters if needed.
  • Dot vote on the themes and/or individual cards to identify the top items.
  • Split the group into 3 teams. Send the teams to different parts of the room or different spaces work on identifying the following for each card/theme.
    • Methods
    • Impediments
    • Practical next steps
  • Bring the groups back together to share what they came up with.
  • Discuss to gain alignment.
  • Identify action item owners.

After the exercise:

  • Document the results and distribute to participants.
  • Propose to the group that you come back together in 2-3 months or on a regular basis to work towards the outcomes you’ve created a plan for.

Dot Voting

Dot vote to Identify the top 3-5 items from each category.  Then break the room into 3 groups to build agreements and identify practical steps towards achieving this ideal state. Then share back to the room what each group came up with. 

Creating an Action Plan

Work with participants to identify WHO, WHAT, WHEN, and HOW they will begin to act on them.

  • What methods can we use to achieve this goal or stop doing something?
  • Are there impediments to utilizing these methods?
  • What practical next steps need to be taken? And who will do them?

Timings

Depending on the number of participants in your futurespective, you may need more or less time than what is listed below. The timing below is for a group of 10-15.

  • 5 min – intro
  • 15 min – write out cards for all 3 questions
  • 15 min – grouping themes / Dot voting
  • 30 min – Build Plan
  • 30 min – share back / discussion
  • 5 min – Determine next steps

Team Roles Visualization Exercise

When working with a new agile team or when a role like the Product Owner or the Scrum Master changes, I’ve found that it is prudent to visualize the specific team responsibilities. If the majority of the team has a basic understanding of the role of Product Owner and Scrum Master this method could be especially useful. Much more so than the alternative of teaching the group about generic guidelines and hoping they figure it out. (However, as a facilitator you should coach the group on which responsibilities could be ideal for thier role-based “standard” agile practices.)  Another factor for Scrum centric organizations is that the Scrum Guide doesn’t have details about managers, so this is a good opportunity to codify that for your team(s). 

I’ve used this method to help out dozens of teams, and it typically aids in sorting out if everyone is doing the right things, and allows for grey areas to be accounted for.

Team Roles Visualization Exercise
Timebox: (30min for established teams, 60min for new teams)
Purpose: Bring clarity and alignment for the roles on an agile team.

  1. On a whiteboard draw out columns for the core roles for the team (PO, SM, Devs, Mgr, etc)
  2. Have each individual in that role write in the various responsibilities, processes, and even meetings they feel they’re responsible for.
  3. You now have an inventory of likely most of the things that comprise the teams rhythm of operation. As a facilitator/coach, write down any gaps you are seeing.
  4. Now go through each column and make sure the group is aligned, or if certain things should be moved to a different person. Also, help ensure the gaps you may have written down are addressed.
  5. Document the results with a picture or transcribe to a document that can be posted on your team portal.
  6. It’s suggested to distribute the results to the entire team.

For brand new teams or for teams that do not have an agile background, this similar exercise may be another option to help nudge along this activity.  Scrum Roles and Responsibilities Game

The Coaching Spectrum

 

 

There are many different ways to lead and coach within your organization. And often the type of approach you need to use can depend on your role in the organization, as well as if your role is catered towards delivery results vs the growth of individuals. Often times a consultant would need to operate more in the Partner / Modeller/ Hands-on Expert end of the spectrum. Whereas a traditional agile coach may live more in the Counsellor / Facilitator / Reflective observer end of the spectrum.  This isn’t to say either should be limited to any specific end of the spectrum, however, if an agile coach were to primarily operate as a hands-on expert, they could create too much dependence on themselves and deprive others of being able to grow and improve.

  • Counselor – “You do it. I will be your sounding board”
  • Coach – “You did well, you can add this next time”
  • Partner – “We will do it together and learn from each other”
  • Facilitator – “You do it, I will attend to the process”
  • Teacher – “Here are some principles you can use for problems like this”
  • Modeler – “I will do it; you watch so you can learn from me”
  • Reflective Observer – “You do it; I will watch and tell you what I see and hear”
  • Technical Advisor – “I will answer your questions as you go along”
  • Hands-on Expert – “I will do it for you. Or I will tell you what to do.”

Where do you feel you fall on the coaching spectrum?

Examining LeSS’s “Overall Retrospective” Model

In a time when discussions about how to scale agile are front and center there are many variations and approaches to consider.  Some popular scaling frameworks are Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Disciplined agile Framework (DaD).

Today we will examine one element of the LeSS framework, and that is the “Overall Retrospective” model. In general, it is widely accepted that the LeSS framework is much more lightweight than SAFe. And as with any framework, you don’t necessarily need to adopt every element therein, but that doesn’t mean it hurts to examine components with a critical eye.

According to LeSS’s guide “The Overall Retrospective is a new meeting in LeSS. Its purpose is to discuss cross-team, organizational and systemic problems within the organization.” This is similar to a “scrum of scrums” but with a retrospective spin. So, can you and your organization find value by leveraging “Overall Retrospectives”? Let’s look a bit deeper and find out.

The Positives

  1. Cross-team collaboration – it is very common for teams to only be able to take their growth so far until they hit cross team or organization-wide challenges. Encouraging and providing a model for cross-team retrospectives is a big win and something many companies could majorly benefit from.
  2. Tools provided – the model outlined in the LeSS model tees up very nicely a model that is to the point and gets to the heart of issues. The article says “An important tool for Overall Retrospectives is to use Cause-Effect Diagrams. Having the participants pick an issue and explore the different causes together in front of a whiteboard can lead to big insights and real, useful changes.” These type of methods are great to make retrospectives less subjective and move towards identifying real for experimentation and continuous improvement.

The Pitfalls 

  1. PO role – One thing you could not like about this model is that it distinguishes the PO as a separate entity from the team. This may not be the intention, but when the PO is designated as a separate piece apart from the team, it can create a dynamic on a team of “us and them”.  I’ve found it helps to message and position the PO as a “peer leader” of sorts that is an equal on the team. This means that POs should be a part of their team’s retrospective.  Product Ownership is such a critical component of a successful agile team, that having that role only active in cross-team retros would be missing many opportunities for growth.
  2. Managers & Retros – Not including managers in a retrospective typically is a signal of some kind of safety issue. Aside from this model, I’ve seen many teams hold two variations of their retro: one with management and one without. I think creating MORE meetings rather than addressing the behavior of a leader that doesn’t foster safety is counter-intuitive to the principles of LeSS. That being said, I am a fan of taking realistic steps forward so the dual phase retro can serve a purpose if the long-term goal is to groom leaders that can be present at a retro and have teams feel comfortable. I’ve also found that when treating managers as agile leaders it is important for them to attend retrospectives so they can take away action items to help support the team. If a manager spans multiple teams it could make sense for them to not be present at a team’s retrospective. I realize this may be counter to the popular belief in many agile circles, but take some time to consider if keeping managers in a silo away from the team is solving the right issue.

Summary

If your organization is struggling with cross-team collaboration “Overall Retrospectives” could prove to be a tremendous resource. As with any tool or process, you will want to carefully evaluate how to customize it for maximum benefit and minimal waste. LeSS is seeking to solve all the right problems with this process, but you may want to reconfigure the attendees at each level of retrospectives. Do you have experiences using this format or something similar?  If so please do share in the comments!

 

Detailed Sprint Planning Agenda

No Sprint Planning meeting will be the same, but I have observed some very practical steps to help you power through your sprint planning and ensure the essentials are covered.

Some assumptions:

  • Iterations are 2 weeks in length. (adjust time boxes listed below if you do 1 week or 3-4 week sprints)
  • Teams have some level of cross-functionality
  • Product Owner is embedded in the team and in attendance

Sprint Planning Agenda:

  1. (15-30 min) Recap of current sprint
    1. What is done?
    2. What is left and why?
  2. (5-10 min) Prioritize any leftover items – The PO decides if left over stories should move to top of sprint backlog or sent back to the backlog. (Do not assume that because something was a high priority before that it for sure is a top priority again!)
  3. (5 min) Close previous sprint in ALM tool (Jira, VersionOne, Rally, etc)
  4. (15-30 min) Revisit estimates for carryover stories. (Look for TOTAL effort, not just remaining effort. This is key for establishing velocity)
  5. (5-10 min) Evaluate capacity of the team (check for PTO, training, etc)
  6. (90-130 min) Create the Sprint Backlog – Pull stories from the backlog to create the sprint backlog one story/task at a time.
    1. Break each story/task down to sub-tasks
    2. Estimate hours for each sub-task (optional)
    3. Quickly Re-visit the estimates for the stories after tasks are created.  Still seem good? (Your estimate was first created in backlog grooming, now you’ve gotten more specific and need to make sure it still is accurate)
    4. Note: if the team is not yet highly cross-functional you will need to take a look and who these tasks might be assigned to. If you only have 1-2 people, a team with a specific skill set you do not want to create a situation where the rest of the team is blocked because they have too much work. If the team is cross-functional you do not need to assign anything to anyone other than the first task an individual will work on after sprint planning.
  7. (10 min) Fist of Five – Ask the team about their confidence level for the upcoming sprint items. Specifically, this is trying to gauge if they feel their commitments are realistic, and there is nothing blocking them out of the gates. If there are outliers take the time to discuss and adjust sprint forecast as appropriate. Remember, you can always pull additional items from the backlog should the team finish all items in the sprint backlog.
    1. 5 fingers: I am 100% sure we will complete everything this sprint.
    2. 4 fingers: I think it’s probable we will complete everything this sprint.
    3. 3 fingers: There’s a 50/50 chance we will complete everything this sprint.
    4. 2 fingers: I think it’s unlikely we will complete everything this sprint.
    5. 1 finger: I am 100% sure we won’t get everything done this sprint.
  8. (10 min) Create sprint theme/goals – This could be action items from Retro, or focus on collaboration, or some vision from the PO about a feature.

Tips for an awesome daily standup

1lf1r4

If you are a part of an agile team, you probably are doing daily standups (daily scrum), right?  As many things in life go, repetition can cause something to be less and less enjoyable, even to the point of dread. If the grind of the 3 questions (what did you do yesterday, today, and what are your blockers?) has got you down, here are some tips to optimize your daily standups.

1.) Start on time – Even if everyone is not there on time.  This may seem counter-productive, but who wants to wait around every day for 2-5 min while people wander in with their Starbucks or like to take a bathroom break every day before standup?  If you consistently start on time, people will get the hint that they need to be on time or will always be late.  Also, This rewards those who tend to be on time more often than not.  If you really want to have fun with it, start a standup tip jar.  every minute late you have to throw in a dollar to pay for the team’s beer run. 🙂

2.) Standup – There is a temptation to walk into a room, put down and open up your laptop, and settle in with a warm beverage.  This is a sure fire way to drag out your standups. By standing up people are slightly less cozy and more apt to get down to business and move on with their day.

3.) Do not turn standup into a status reporting session – In my opinion, the standup should be more focused on the plan forward than going over what took place in the past. There is often value to sharing what you’ve done if it helps share knowledge and communicate that you’ve completed something.  I always try to go by the 80/20 rule for standups. Let me explain: Only 20% focused on the past and 80% of your update focused on the present and future. another way of saying it is to spend 80% of your time discussing your plan forward and any impediments in your way. the #1 problem I’ve observed with most standups is that they spend 80% of their time on question 1 which erodes the intent on the standup.

4.) Be inclusive of remote team members – This could be a completely separate blog post, but here a few of the most important suggestions I can make.  First, use video if at all humanly possible. You lose so much in translation without seeing someone’s face. Next, consider having someone at the location where the team is mostly co-located be on point to making sure the remote folks are considered.  I’ve worked on many distributed team, and it’s very challenging to keep them in mind unless you are intentional about it. This article from Leading Agile has more great tips.

5.) Utilize a parking lot – if you or your team has a challenge with going deep into solutions at standup, it’s probably time to start using a parking lot.  Or as I’ve heard some people dub it, “The after party”.  If a conversation has gone too far into the weeds someone should propose it get’s added to the parking lot.  Quickly write it down on a sticky note, etc.  Then after everyone has given their update have the folks who need to keep discussing the parking lot item stick around.  I’ve worked with some coaches/scrum masters who are very legalistic about the parking lot. I say, use common sense.  If the team wanders into the weeds once and a while it’s fine, don’t shut it down.  But at the same time, you don’t want 7 team members that don’t need to be involved to have to sit through a conversation that could be had by 2-3 people.

6.) Streamline standup with other agile events if possible – Here is an example: You have a two-hour backlog grooming session from 1PM, then standup at 4PM.  Do you really want the team to go back to their desk to try to work for an hour, then go to standup?  I sure hope not, because context switching is costly and to be taken seriously!  The team should think ahead to try to minimize this context switching when possible.

7.) End on time or early – For a team for 6-12 I highly suggest going NO longer than 15 minutes for standup. And as we know tasks often expand to the time allocated.  This is why it is important to keep the conversation moving so you can finish early or on time, every time.

8.) Try mixing up the format once and a while – I was on a team once that did “third person Thursdays” where you had to give your entire update in the 3rd person.  It still accomplished the goal of standup but it was a fun way to mix things up. Another thing you could try is have team members attempt to give an update for the person standing next to them based on what you think they did and are going to do.  This method is slightly less productive but still fun. If your standup is in the morning, try surprising them with donuts or gourmet coffee once and a while.  Another thing you could do is a brief quiz at the end of standup. “What did Suzie say she was blocked on?” The first person to answer get’s a $5 Starbucks gift card.  I think you get my drift…mix it up!

I’d love to hear your ideas and experiences on how to make standups rock, and keep them from sucking!

Start With Scrum?

“Start with Scrum.”  Have you ever heard someone say this?  I’ve heard this statement multiple times over the years when folks are talking about agile transformation, and it rubbed me the wrong way.  The problem is, I couldn’t quite put my finger on why. In many ways, it makes sense right? Scrum can help someone wrap their mind around work decomposition, shorter feedback loops, retrospection, and being connected to the customer more through user personas. But why are so many teams struggling to find agility with scrum? I think I finally can explain why I think this approach isn’t the right thing to do if your end goal is agility.

1 – Scrum is a framework and agile is a mindset.

sahota

Source: Michael Sahota

Last year when I was presenting at the Global Scrum Gathering, we borrowed from Michael Sahota who said something to the tune of “If you adopt agile practices you could see a 20% benefit. If you adopt an agile mindset you could see 300% benefit!” So many people I meet that are interested in agile for their organization just want the benefits but without the mindset shifts needed to get there.  I don’t fault them for that because when you look at the Agile Manifesto it reads out very well and sounds like positive things for most rational people. What is sorely missing is the “counting the cost”. If becoming agile as an organization was as simple as doing some training and doing the Scrum Events, there wouldn’t be agile coaches.

2 – Scrum is so 1990’s.  (just like these awesome “hackers” in 1995)

hackers

Look…I love scrum.  I really do!  It’s something that opened up a doorway for me to be exposed to agile manifesto which has changed my life and career aspirations.  But, while I was working on a blog post entitled “The History of Agile” it dawned on me that Scrum was a response to waterfall. And it was a tremendous leap in the right direction away from fixed cost/scope/timeline type projects.  Then came along the agile manifesto which was a response to scrum and the various flavors of agility frameworks sprouting up. But we need to look ahead and allow the agile mindset to lead us into the great unknown.  Ron Jeffries, one of the great original thought leaders in agile even said “I may have invented points.  If I did, I’m sorry now.”  The point is, we need to inspect and adapt as technology changes, culture changes, and people change.

Here’s another awesome 90s picture just because I found so many great ones to use for this article.

fresh

 

 

 

 

 

 

 

3 – Training wheels can create improper habits.

training

 

 

 

 

 

 

 

 

I was listening to a presentation by Joshua Kerievsky last week and he told a story about teaching his daughter how to ride a bike. He said that many people talk to him about how Scrum is like training wheels for their organization to adopt agile.  He pointed out though that training wheels don’t actually teach you balance, they just teach you how to steer and peddle.  He took his daughter to the park one day and had her learn how to ride a bike by keeping her feet of the peddles and just pushing herself and lifting her feet to learn the balance.  She quickly got comfortable with keeping balanced which is typically the hardest part of learning how to ride a bike.  And in no time she was ripping around on the bike!  What’s the lesson here?  You don’t always need training wheels to begin your journey towards agility.

In conclusion, starting with Scrum may not be the right strategy for your team(s).  My personal guidance as an agile coach is to only start with Scrum if you envision something close to Scrum being your destination. And even in that is your situation, always start with trying to adopt an agile mindset before trying to implement a framework. By doing this, you are allowing your organization to tap into their creative potential, untethered to just one framework.

A Guide To Backlog Grooming

Photo Credit: Leanpub.com
Photo Credit: Leanpub.com

Backlog grooming is an activity many agile teams perform each sprint. This is the process of adding detail, estimates, and order of priority to items in the Backlog. This is an ongoing process in which the Product Owner and the Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.  The Product owner is responsible for having stories ready for grooming, and the Scrum Master is responsible for making sure the stories are groomed before sprint planning (via backlog grooming).

What is Backlog Grooming?

  • Removing user stories that are no longer relevant or needed
  • Re-assessing the relative priority of stories based on emerging information
  • Applying estimates to stories which have yet to be estimated
  • Correcting estimates based on newly discovered information
  • Creating new user stories in response to newly discovered needs by the team, product owner, or customers
  • Splitting user stories which are high priority but too large to fit in an upcoming sprint

Grooming will allow for:

  • A better understanding of user stories
  • Identification of dependencies and potential gaps for stories
  • User Story estimation for upcoming and future sprints

Product Owner’s Role

The Product Owner’s role in backlog grooming should start before the actual meeting. The PO will need to make sure that the stories are already prioritized. This is vital to making sure the team’s time is used to groom the most important items first. The PO should also add acceptance criteria or user acceptance test cases to stories as appropriate, depending on how soon each story will be pulled into a sprint. Backlog grooming should not be done without the PO.

Scrum Master’s Role

For this project The Scrum Master will schedule the meeting and take care of any other logistics.  The Scrum Master should also be in contact with the PO before the grooming session to make sure the stories are ready to be groomed.  Backlog grooming can be done without the SM.

The Team’s Role

Having the team involved with grooming is imperative.  While the PO has a great deal of the content identified up front, the team can help round out the technical aspects, dependencies, and other considerations.  With the team’s help, the acceptance criteria can be modified and expounded upon.  If the team has the ability to even briefly review the top upcoming items, its ideal.

What’s the potential impact of not having backlog grooming?

  • Your stories will not be prepared for sprint planning.
  • The connection of work items to big-picture vision will grow stale.
  • A dev may be looking or hearing about a story for the first time as they are having it assigned during sprint planning. This typically can increase ramp up time.

Who Should Attend Grooming Session(s)

  • Pre-Grooming: Discipline Leads (UX/Component), Product Owner, Scrum Master (OPTIONAL)
  • Grooming: Same audience as above and including all Dev members and the QA teams.

Just Getting Started?

For the initial 1-2 sprints it’s suggested that both Pre-Grooming and Grooming sessions take place.  Cadence and details below:

Pre-Backlog Grooming

(Optional but highly recommended during early stages): A more focused group review to prepare stories for the full team grooming sessions. Goals:

  • Review story scope
  • Identify blockers and agree on an plan of action to unblock items
  • Ensure the stories contain the minimum needed information to the team to be able to discuss and estimate.

Pre-Requisite: Product Owner has reviewed stories for Pre-Grooming and they are ready for review.

Timebox: Try to have 30-60 min planned each sprint for pre-grooming .

Backlog Grooming

A collaborative discussion and elaboration of user story details and estimates.  All stories on the agenda won’t always be estimated as some will require additional discussion / decisions. Goals:

  • Stories should be understood by all members of the team
  • Blockers should be closed or workable
  • Stories should be ready for sprint placement

Pre-Requisite: Product owner has reviewed stories for  Grooming and they are ready for review.

Timebox: Try to have 1-2 hours planned each sprint for grooming. For teams that are new to this you may want to plan for 2 hours and finish early if you get through everything.

Back To Basics

After your backlog begins to take on a level of refinement, you may find that it’s no longer necessary to have two separate backlog grooming meetings.  A great indicator for determining this would be to ask the following question: “Are all of the stories for the next two sprints containing enough detail that the entire team attend grooming without wasting time?”

Questions?

If you made it this far, you’ve consumed a lot of information.  Feel free to comment with questions or some suggestions you might have.