agile transformation

Futurespective: A Retrospective 6 Months In The Future

chriswmoodyLeave a comment

“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
Advertisement

A Guide To Backlog Grooming

chriswmoody4 Comments

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.

I want to use agile, but my organization doesn’t want to

chriswmoody2 Comments

tumblr_n4ef3ynCZP1st5lhmo1_1280

Fear not agile warrior, you are not alone and help is on the way.  They are many situations where someone just knows that agile could help or even change the face of the entire company if utilized…yet someone or many people within an organization are opposed to the idea.  So what should you do?  First off what are some reasons someone would be against agile?

  1. The’ve been on a team where agile was used, and failed.
  2. They don’t know enough about agile or have misconceptions.
  3. They don’t believe agile is right for their organization/product.
  4. They’ve worked with an Agile Coach/Scrum Master/Consultant that was not very good at their role.  Yes, not everyone does their job well…even in the wonderful agile community.
  5. They are from the past (I kid…I kid! That was an IT Crowd reference)

Now for the part you really came to this blog post for: What are ways I can help my organization adopt and/or support agile?

  1. Start emphasizing agile principles in whatever work you are doing. As a consultant that works on a wide array of projects with a variety of methodologies, I’m often tested with how to apply principles on a personal level. Getting out of the theoretical and nitty gritty practical application is a great exercise towards see if/how agile could work at your organization. If this is something you feel is “out of your league” or you just don’t have the time to do, it’s OK.  There’s other ways to makes strides towards becoming more agile.
  2. Propose solutions to problems from an agile perspective but without using agile lingo. Some people are just turned off to agile terms and immediately roll their eyes when you say “backlog grooming” or “daily scrum”. But if you are able to problem solve using agile principles you could begin to win over even the harshest of critics.
  3. Create a mini scrum board for tracking your own work. I heard a story of a person who was trying to advocate for their company to adopt agile, and started doing a scrum wall in a shared space.  Pretty soon scrum boards were up all over the company.  Some were labeled “Inspiration wall” or “Wall of vision”.  Everyone from IT to Sales was using them. Baby steps can be better than no steps, right?
  4. Contact consulting companies. See if they would be willing to share about agile within your organization.  Some consulting companies will do this for free because it’s a great way for them to help your cause, as well as demonstrate their expertise in this area should you need their services down the road. Or see if they are willing to just share free resources with you.
  5. Join user groups and contribute to the agile community. There have been times where my primary daily function was far from an agile focus, but I was able to stay energized by attending local groups or writing blog posts in my personal time.  Also, sometimes effective reflection comes when you are looking in from the outside.
  6. Find a new opportunity.  (Please take this with a grain of salt as it’s just my opinion.) This for many reasons isn’t the first option anyone would like, but it may be the right solution. As the industry seems to be moving more and more towards adopting agile, it’s less likely that a company is just flat out rejecting agile. It could be that they proclaim to use agile but it’s very broken or dysfunctional. These kinds of situations can cause stress if you are a firm believer in the agile principles. But is the disappointment or stress consistently outweighing the rewards or satisfaction experienced? If yes, it may be time to look for new opportunities.   Robbie Bach wrote a relevant article you may find useful called “Knowing When To Walk Away“

What about you? What advice would you have for someone in this scenario?  I’d love to hear what other people have done or are doing.

Stay Agile My Friends

chriswmoodyLeave a comment

ckv31a

This is mostly meant to give you a chuckle, but there is some validity to it as well.  In my last blog post I talked about how we need to challenge the limits of what we understand agile to be.  Can you be agile and waterfall at the same time?  Probably not if you look through the lenses of what we typically view as a waterfall process.  But it’s possible.

One thing I’ve noticed as an agile coach is that people like to gravitate towards what they know and are more comfortable with.  One way this can play out is when helping a team adopt agile, you can get a strong pull to keeping things in the box of a waterfall process. This happens both at the individual contributor level and management level. Management can sometimes want waterfall type metrics but without the changes needed to realize the true benefits of agile. It’s ok though.  Be patient, and see if you can find a way to meet somewhere in the middle. Waterfall isn’t bad.  In fact it has tremendous value in the right context.  So, as an agile enthusiast make sure you aren’t always negative about waterfall especially when it could be used to your advantage.  However, what you don’t want to do is fall into the trap of using the buzz words from agile/scrum but keeping things pretty much the same.

I’ve found it is helpful to ask people questions about why they want to do something a certain way. “What do you think will be the benefits of trying it this way?” “What are you hoping to accomplish by doing it this way vs. that way?” If you say things like “You are just stuck in old thinking.” or “That’s not agile.” you can build walls instead of creating bridges. If they are pushing for trying something, maybe just go with it for 1-2 sprints.  Then evaluate the impact it is having.  After all, I’ve always found that I am continually learning from the teams I work with, and surprise-surprise I DON’T KNOW EVERYTHING!  😉