Uncategorized

Team Roles Visualization Exercise

chriswmoody1 Comment

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

Advertisement

Tips for an awesome daily standup

chriswmoodyLeave a comment

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!

The Great Delivery Debate

chriswmoody3 Comments

AAEAAQAAAAAAAAJNAAAAJDgyMGI1ZDczLTAwYTAtNDA4YS1iNGM1LWYwZGUyN2JiODE1Mg

Dr. Winston Royce first described a model for working with large software systems in 1970, which we’ve grown to know as “Waterfall”.  Interestingly enough what many never read in his writings on SW development, is the following quote: “I believe in this concept, but the implementation described above is risky and invites failure.” (Source: Dr. Winston Royce. Proceedings, IEEE WESCON, August 1970)  Why could he have said this? Could it be that many times requirements are emergent? Perhaps it’s that estimating large and complex bodies of work based on a requirements document can be incredibly inaccurate?

While I have a large bias towards Agile methodologies, as a consultant it’s my responsibility to evaluate what truly is the best solution for a client.  I was recently on a project in a marketing organization, and while there certainly were some opportunities for Agile principles to be utilized, a framework like Scrum or Kanban just would not have been possible. I’ve heard some waterfall purists sum agile up to a bunch of people who want to get out of documentation and commitments to timelines.  Ouch.  But I also hear a lot of criticism from agile truthers about anyone who leverages waterfall as being clueless and archaic. Can’t we all just get along?  Yeah, we can actually.  But we have to start to recognize that Agile and Waterfall have value in different ways.

I’d love to have some discussion about what is seemingly a great divide between Agile and Waterfall methodologies. To help those in each “camp” understand why a specific method has value towards solving their business problems. What are some examples where you think a Waterfall process was truly the best solution for a project?  What were some of the identifiers you had to come to that conclusion? Have you had success with using a “ScrumerFall” model where the Requirements, and design is all done up front, but Execution is done in sprints?

Do You Lean Coffee?

chriswmoody1 Comment

Have you ever used the Lean Coffee format for a meeting?   It’s a tool I’ve been so pleased to use in a variety of formats in recent years.  I’ve used it for governance meetings, team retrospectives, and open agenda meetings where there is no pre-existing agenda other than to do Lean Coffee.

What is the Lean Coffee format?

The following content is copied from http://leancoffee.org/  “Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.”

1. Set up a Personal Kanban

Simple Personal Kanban for Lean Coffee

In this Personal Kanban we have the items to discuss, what we are currently discussing, and the discussed columns.

This provides a structure for the conversation. Next we populate it

2. What to Discuss

A Populated Backlog for the Personal Kanban

People all get pads of post-it notes and a pen. They then start to add their topics for conversation into the “to discuss” column. These can be literally whatever people want to discuss or follow a theme. Right now, we want to encourage as many unique ideas as we can.

When the ideas start reach a certain point (an you’ll be the best judge of when that is), each topic gets a 1 to 2 sentence introduction. This way people know what to vote for.

3. Vote and Talk

Stockholm Late Night Lean Coffee

Each participant gets two votes. You can vote twice for the same thing or for two different topics. Simple put a dot on the sticky you are interested in. Tally the dots. Then you are ready to have a conversation.

The power here is that you now have a list of topics everyone at the table is interested in and is motivated to discuss for real.

End of content from leancoffee.org website.

Some benefits of using the Lean Coffee format:

  1. It’s highly collaborative!
  2. It supports the discipline of being a self organizing team.
  3. It helps to crowd-source the agenda. People have skin in the game because they got to vote about what is being discussed
  4. Time boxing helps to keep the meeting from getting stale and boring.
  5. The proof is in the pudding. Some of the best conversations I’ve every been a part of have been while using the Lean Coffee format.

Examples of when Lean Coffee may not be the best idea:

  1. You have a very specific agenda that needs to be adhered too.
  2. There’s only 2-3 participants in the meeting.
  3. You are talking with customers or the participants may have never heard of lean coffee.
  4. Your participants are knowingly “anti agile”.
  5. If you know the majority of the participants of the meeting are not typically not inclined to talk in a group. Dominating personalities will control the conversation and others could become bored and find it a waste of time. (with the right coaching this risk could be avoided)

Need more info still?  Here’s a great video showing a sample lean coffee meeting.

“That’s Not Agile”

chriswmoody3 Comments

right_way_and_wrong_way_sign-other_zps8c090af3

If you work in an organization that utilizes one of the many agile methodologies, you have probably heard the statement “that’s not agile”. It could be about a proposed process change, or a critique of an existing way of doing things. It baffles me to no end when people get lost in the weeds about if something they want to try as a team is agile. This is unfortunately very prevalent in Agile Coaches and Scrum Masters who have a lot of experience.  Since agile is an emerging idea that is really starting to catch some momentum, some who have been advocates for a longer period of time can be standoff-ish about how to do things.  This should be a huge red flag, because there are so many variations of agile and not every organization is the same. You can know all the right things, but completely fail at helping a team adopt agile. That is why it is very important to be flexible, and not have a “better than” mindset.  The principles of agile/scrum are meant to be a guide, not a law that must be perfectly adhered to.  I’m not suggesting you should throw all caution to the wind and try any and everything, because “everything’s agile!”  No.  What I am primarily addressing is the way in which this topic is approached.

So, who’s right?  Maybe saying “that’s not agile” can be valid.  Or maybe we’ve lost sight about what agile is all about.  Let’s just take a quick peek at the Agile Manifesto for a refresher on what it’s all about:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

To be brash: If someone tells you “that’s not agile” and it’s something that could enable one of the 4 agile main points of the manifesto, I would seriously question how well they truly understand agile.  And agile by nature is something that I believe will continue to evolve as people uncover better ways of doing things. (sound familiar?)

If your organization is looking for an Agile Coach or Scrum Master or you are just trying to improve your skills in that realm, here are some suggestions for what not to do, and what to do.

  1. Don’t try to impress anyone with your agile credentials.  Do try to identify things that have been successful on similar teams/organizations.
  2. Don’t be preachy when trying to present new ideas.   Do suggest ideas with a humble and flexible attitude.
  3. Don’t rely solely on past experiences of what worked for other teams.  Do spend a lot of time listening to people’s needs an challenges.
  4. Don’t react when people are critical of agile.  Do find a way to tie what people want back to agile principles and show them how they could enable those things.
  5. Don’t press your own agenda.  Do thoroughly understand how you can support management’s vision.
  6. Don’t treat the agile principles as a law.  Do use them as a guide for making continual improvement.
  7. Don’t be too critical of a team’s existing processes. You never know how much hard work they have put into building what’s there. Do make a point to try to build on existing foundations, and position it as an improvement rather than tearing down.
  8. Don’t be too quick to judge what will work best for  a team.  Do ask a lot of sincere questions and follow the breadcrumbs of how things became the way they are.

 

Hopefully the next time you want to say “That’s not agile” you can remember the big picture and help your teams find the very best solution.  What things are important to you as an agile proponent in these regards?  Do you have any good stories to share?

Agile Certifications…What’s The Value?

chriswmoodyLeave a comment

Scrum certs

Last week I attended an agile training seminar for the Certified Scrum Master (CSM) certification. It got me thinking about what is really the value of going to an agile training session.  Having already attended the Certified Scrum Product Owner (CSPO) training last year I was curious as to how much I would benefit.  When I attended the CSPO training the trainers take was that you needed to learn almost as much about the scrum master role as you do the product owner to be able to understand better. I have to say I was pleasantly surprised with the amount of new knowledge I walked away with. I’ve noticed that each trainer has had a deep background leading and coaching agile teams, and with that comes different nuggets of wisdom. While the first 1-2 hours were mostly review, after that it seems that each session had a life of its own and had tremendous value.

Do you really need an agile certification to be effective on an agile team?  Technically no. But if you are someone who is looking to make a role transition or have an extensive background in waterfall environments, it could be a great tool and demonstration of your ability to make that transition. Obviously time and experience with agile is more valuable, but if I were going to make a statement in the same format of the agile manifesto it would look something like this “Working experience over training seminars and certifications.  That is, while there is still value in certifications, there is more value in working experience.”

Why should you keep going to training seminars like this? For me I realized that when you work in an agile organization you can start to get used to the way you are doing things.  And being with a room full of people talking about what they do gives your copious amounts of inspiration for what you are doing. I was furiously writing out sticky notes with ideas for things to try, and now the challenge will be slowly introducing some of those ideas to the team without being “that overly hyped out conference high let’s change everything” guy.

Something else I was pleased with is that after attending the CSM training I was required to take an exam (open book), that required me to prove my knowledge. It didn’t sit right with me that I could attend a 2 day CSPO training and leave with a certification.  The CSM exam was actually pretty challenging, even with the internet at my disposal.  It was a good exercise all in all.