Planning Archive

0

Top 10 Negative Personas of a Daily Standup Meeting

standingAll Agile teams should be holding a daily standup meeting.  Don’t think of it as a daily planning meeting. Think of it as a daily opportunity to have a shared understanding of what is getting done and what lies ahead.  During a daily standup meeting, participants sometimes exhibit negative behavior that will detract from the meeting.  As an empowered team, it is your job to self-manage and encourage good behavior. Some of these behaviors are so common, we don’t even realize people are doing them. So, I’m giving them some names. Next time you hold a daily standup, see if anyone (including yourself) exhibits any of these 10 behaviors.

Rather than using the list as a means to label others, use it to reflect on yourself. How might others be perceiving you? Is the persona you are projecting counter to your goals? 

If you think of some behaviors that should be added to the list, I would love to see them.

Daily Standup Meeting Negative Personas

 

10. Pat Decker the Obsessive Phone Checker

This person does not always pay attention and is constantly look at her (or his) phone. Did a BFF just like something? Did someone on Twitter just favorite that pic of the team board? In addition to checking her phone, she likes to share what she sees with others during the standup. “Pssst, Bob, check out this Vine video or pic on Instagram”. She’s not so loud that she’s overly disruptive but now Bob missed what someone else said during the standup.

9. Stephen Craig who is Always Too Vague 

This person can get stuck on the same task for days but doesn’t want anyone to know. When speaking to the team, they are crazy vague. Stephen will offer very few details until the team pushes for a deadline. He (or she) will use language like “Yesterday I was working on task 123 and today I will be working on it some more”. No other information is volunteered. When asked if they need any help, they clarify they have no blockers or risks.

8. Bobbie Bainer the Team Complainer

When the attention is on Bobbie, get ready for the positive energy to be sucked right out of the room. Bobbie complains, complains, and complains some more. Management, teammates, or the technology is all fare game. Everything and everyone sucks and no one knows just how bad they have it. Don’t bring up religion or politics unless you want Bobbie to go right into a 20 minute tirade.

7. Jess Jewler who loves the Water Cooler

Jess comes to the daily standup to talk, but not about what needs to be done today. Instead, he or she will talk about just about everything else. The next 15 minutes is dedicated to the water cooler. Did you see the last episode of House of Cards or The Walking Dead?  Are you going to watch the Ravens play this weekend?  My son plays Minecraft and constructed this totally awesome building with redstone. Anything is fair game, as long as it’s not about work.

6. Billy Platitude with the Bad Attitude

Billy is a leftover from a bygone era. He was the best of the best mainframe developers and all he needs is a DLD and he’ll give you what you need… in a few months. You want any changes between now and then? Forget it!  He thinks all things agile are stupid and just plays along begrudgingly. You may catch him make cynical “funny” comments at standup to point out how right he is about how stupid agile is.

5. Will Funky the Non-Committal Junkie

Will does not want to be painted into a corner. Typically, he uses language like try, maybe, pretty sure, I’ll get back to you, we’ll see, would like to think, soon, almost. You’ll also see Will be the last person to comment on something and will usually go with the crowd.

4. Tom Mater the Specialty Updater

Tom only gives vague commitments, usually understandable only by those in his discipline. The overall team gains little value from the statements. If you ask him for details, he’ll either tell you to look it up in a tool or he’ll be very technical in his response. Half of the team doesn’t understand what the hell he’s talking about.

3. Drue Gru who thinks he’s Better Than You (and the team)

Drue has been around for a long time. He’s better than you and he knows it.  If you need him, you know where to find him. He either arrives to the standup meeting late or he doesn’t come at all.  He has little to say because you wouldn’t understand what he’s talking about. He already knows everything so what is he to gain by slumming with you and the team for 15 minutes? Let him know when something important happens. *sarcasm*

2. Pearl Revolver the Problem Solver

Pearl means well but she lacks a sense of time. She wants to have in-depth problem solving discussions on obstacles identified during the standup meeting. She’s very curious what issues others are having because she’s going to want to talk it out and fix it right then and there. Even if there is a reserved 15 minutes after the standup, Pearl figures there is no better time than the present to tackle a challenge.

1. Ian Krumpter the Interrupter

Do you listen or do you wait to talk?  Stop and think about that. There is a difference. Ian waits to talk. People can be binary in that way. If you’re talking, you’re less likely to be listening. He wants to prove just how awesome he is so you’ll see him interrupt even if the topic doesn’t really apply to him.

 

Thank you to the other coaches at LeadingAgile for their contribution to this post. The original post was dated March 17 over at the LeadingAgile blog.

Image Credit: Pictofigo

4

Favorite Project Management Quotes

Favorite QuotesThere isn’t a week that goes by that I don’t hear some awesome quote or analogy.  I put as many as I can into my mental back pocket, hoping for an opportunity to pull one out at a moments notice.  When you’re stuck for a quote or analogy, to help someone understand what you’re trying to say, do you ever ask yourself what’s that awesome quote that I just heard the other day?

Here are 10 that I keep handy.  Are there any quotes you would like to share?  Please add them to the comments section.


  • Because the needs of the one… outweigh the needs of the many.Star Trek III: The Search for Spock, Captain Kirk.  I like to use this quote when explaining the contrast between egoism, utilitarianism, and altruism (servant-leadership).
  • The more they overthink the plumbing, the easier it is to stop up the drain. – Star Trek III: The Search for Spock, Scotty. I’m admittedly a Star Trek geek.  I’ve used this once when trying to articulate Lean thinking.  I also segway into the untrue but compelling story of the Million Dollar Space Pen.
  • The thing is, Bob, it’s not that I’m lazy, it’s that I just don’t care. – Office Space, Peter Gibbons.  I like to use Office Space quotes, particularly when referring to empowered teams and while drinking from my Initech coffee cup.  Mmm’kay? Greeeeat.
  • Luck is not a factor. Hope is not a strategy. Fear is not an option. - James Cameron.  This quote was on the back of the LeadingAgile t-shirts we all wore at Agile 2012.  I still have strangers walk up to me and ask about its origin.
  • That which does not kill us makes us stronger. - Friedrich Nietzsche.  I think of this quote during almost every run I take.  After taking an inventory as to my physical condition, I have a mental debate as to stopping or keep pushing forward. I keep pushing forward.
  • We keep moving forward, opening new doors, and doing new things, because we’re curious and curiosity keeps leading us down new paths.- Walt Disney.  I’ve told my son over and over again to challenge the status quo (I don’t call it the status quo because he’s seven) and when given the choice, try new things.
  • When we go into that new project, we believe in it all the way.  We have confidence in our ability to do it right. - Walt Disney  The power of positive thinking and an empowered team.
  • Plans are of little importance, but planning is essential – Winston Churchill.  Another almost identical quote came from Dwight D. Eisenhower: Plans are worthless, but planning is everything When I talk about the Agile Manifesto and how we should be responding to change over following a plan, this becomes one of my most commonly used quotes.
  • Stable Velocity. Sustainable Pace - Mike Cottmeyer.  This quote appears on the back of the LeadingAgile running shirt. It has become the unofficial motto of my life, as it applies to work, family, and running
  • We don’t need an accurate document, we need a shared understanding - Jeff Patton. I was attending Jeff’s session at Agile 2012, when I heard him say this.  It really resonated with me.  I don’t know if the quote was scripted or impromptu.  Regardless, when I recently quoted him at a Project Managment Symposium in Washington DC, I saw over 400 project managers nodding their heads.

This post was originally published on LeadingAgile

1

What is Agile, anyway?

The parable

Ever heard the story about the blind men and an elephant?  In various versions of the tale, a group of blind men touch an elephant. Each man feels a different part, but only one part, such as the leg, the tail, or the trunk.  They then compare notes and learn that they are in complete disagreement.

Agile, my friends, is an elephant.

The first blind man

I just completed an initial engagement with a client, for LitheSpeed.  Some of the people I interacted with were newly minted Certified ScrumMasters, some experienced developers, and some executive management.  In the mix, I met UX designers, architects, and more functional roles than this blog post should list.  The catalyst of this post happened on the first day of the engagement.  To set the stage, the organization was very clear the team is to “do” Scrum.  Due to user stories not being quite ready, the team pushed back at Sprint Planning and refused to estimate or commit to the work to be done.  I recommended the group visualize the workflow and maturation of user stories by way of a Kanban. I’ve made this recommendation before and it worked out quite well.  The response from one of the newly minted ScrumMasters was, “That sounds like waterfall!”  When I corrected him, confirming that it was not a waterfall approach,  he came back with an even better response.  “Well, it’s not Scrum.  If it’s not Scrum, it’s not Agile”.

If it’s not Scrum, it’s not Agile

A few days ago, I read a really great post by Joel Bancroft-Connors titled A Gorilla Primer: What the heck is Agile? Maybe this question is more common than I initially thought!  What I liked about Joel’s post was it exposed the fact that Agile is different for so many people.  When asked what Agile is, I tend answer the question with a question.  Are you being Agile or doing Agile?  If you are being Agile, then how?  If you are doing Agile, then how?  Before I even attempt to answer the question, I want to know your perspective.  Why?  Because as with the parable and also reality, it’s going to depend on your touch points.

Go read Joel’s post.  I think you’ll enjoy it.  When you’re done, I’m sure you’ll agree that if it’s not Scrum, it can still be Agile.

Image Source: Pictofigo (Go get one. They’re free)

0

Free Sprint Planning Guide and Agenda

As part of an Agile assessment, I sat in on a sprint planning meeting.  Though many out there are having sprint planning meetings at the beginning of every sprint, are they getting the most out of the time and effort?  As part of the services to my client, I will be providing a free cheat sheet for sprint planning.  It is both a guide and an agenda, to help keep them focused.  If you want a copy, just click the link at the bottom of the post.

What is Sprint Planning?
The purpose of the sprint planning meeting is for the team to agree to complete a set of the top-ordered product backlog items. This agreement defines the sprint backlog and is based on the team’s velocity or capacity and the length of the sprint timebox.

Who Does It?
Sprint planning is a collaborative effort involving:

  • ScrumMaster – facilitating the meeting
  • Product Owner – clarifying the details of the product backlog items and their acceptance criteria
  • Agile Team – defining the work and effort necessary to fulfill the forecasted completion of product backlog items

Before You Begin
Before getting started we need to ensure

  • The items in the product backlog have been sized by the team and assigned a relative story point value
  • The product backlog is top-ordered to reflect the greatest needs of the Product Owner
  • There is a general understanding of the acceptance criteria for these top-ordered backlog item

Backlogs
The product backlog can address both new functionality and fixes to existing functionality. For the purpose of sprint planning, product backlog items must be small enough to be completed during the sprint and can be verified that they were implemented correctly.

Right Sizing Backlog Items
Product backlog items too large to be completed in a sprint must be split into smaller pieces. The best way to split product backlog items is by value not by process.

Plan Based on Capacity
Mature teams may use a combination of team availability and velocity to forecast what product backlog items can be finished during the sprint.  New teams may not know their velocity or it may not be stable enough to use as a basis for sprint planning.  In those cases, new teams may need to make forecasts based solely on the team’s capacity.

Determining Capacity
The capacity of a team is derived from three simple measures for each team member:

  • Number of ideal hours in the work day
  • Days in the sprint that the person will be available
  • Percentage of time the person will dedicate to this team

The Planning Steps

  1. The Product Owner describes the highest ordered product backlog item(s)
  2. The team determines and prioritizes what is necessary to complete that product backlog item(s)
  3. Team members volunteer to own the work
  4. Work owners estimate the ideal hours they need to finish their work
  5. Planning continues while the team does not exceed determined capacity

Download the free 2-page Sprint Planning Guide and Agendadownload-flashcards

Drawings by Pictofigo

3

Empirical or Definitive

Ever heard of the cone of uncertainty?  The cone shows the historical error at certain time periods in a tropical cyclone forecast.  What happens today and what has happened in the past is pretty much all we know.  We can certainly use all kinds of scientifically proven processes or models to try to predict the future.  But, in the end, we won’t know what tomorrow will bring until tomorrow.  If you are dealing with machines, you should be able to predict upcoming events with relative certainty.  If you are dealing with people or something like mother nature, the odds of predicting events with certainty are slim to none.

We need to assume that baselines may change significantly during a project or in life.  In unpredictable environments, empirical methods should be used to monitor progress and direct change, rather than using definitive methods to try and predict progress and stop change.

Definitive

You work and work and work, trying to lock in your scope, your schedule, and your budget before the project even begins.  You do everything you can to lay it all out, attempting to account for every possible variable.  Unfortunately, you don’t know what tomorrow will bring.  So, the further out the schedule goes, the greater the risk something is going to change.  What’s it going to be?  Is scope going to change or maybe the schedule will slip?  With the cone of uncertainty, whatever foreseen changes are ahead, there are going to be exponentially more unforeseen the further out the schedule goes.

Empirical

In reality, you begin with the greatest unknown.  Even some of the unknowns aren’t even known.  Just accept it!  You’re not the Amazing Kreskin.  You can’t predict the future.  The only thing that is guaranteed is something is going to change.  So, plan for that change.  Know the goal you’re trying to reach.  Keep your eye on that goal.  Now, do what you do.  Develop, lead, manage… it doesn’t matter.  What does matter is you see where you are right now, know where you want to go, and then at a measured time, see where you are again.  Make some adjustments and repeat.  You will find if you just accept the change, you can use it to your advantage to get closer and closer to your goal.

Summary

You can not predict the future, only plan for it.  You can not steer a hurricane, only plan for it.  You can not prevent change…  Can you guess what comes next?  That’s right, you plan for it.