Archives for May,2015

You are browsing the site archives by date.


Shake Up Your Daily Standup

The Scrum Guide says the following about the Daily Standup:

The Daily Standup or Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. The Daily Scrum is held at the same time and place each day to reduce complexity.

During the meeting, the Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Agile Daily Standup-breaking out of the mold

We all the know the importance of the Daily Standup, but how many teams are actually gaining real benefits from the Daily Scrum or Daily Standup?  This ceremony is not meant to be a ‘Status Report’, but in reality that is exactly what this meeting has become.  If you have fallen into the ‘Status Reporting’ trap, then you may want to consider cancelling your Daily Standup all together or making some simple changes to shake it up!

5 suggestions to shake up your Daily Standup:

1. Extend the length of your daily scrum

Yes, you read that correctly.  If a team of 8 people all have to give an update at a 15 minute Standup, that is less than 2 minutes per participant to provide valuable information.  If someone has a question, then forget about finishing in 15 minutes.  Given the time crunch, team members will hesitate to provide all the information needed in order to allow the team to gain the full benefit from the meeting in favor of meeting the 15 minute deadline.  Stretch a little; give the team some extra time to collaborate – isn’t that what it’s all about?

2. Stop answering the three questions

We all know that a team should be limiting the Work in Progress (WIP).  Let’s say your team should be working on only three stories at a time: review each WIP story in-depth.  Allow each person who is contributing to that story to provide their insights.  Address all issues or questions, or put them in the parking lot for ‘Post Standup’.  (See number 3, below.)  Once you have completely discussed the WIP stories, ask if people are working or need to work on other stories.  This should avoid the schizophrenia that occurs with the round robin approach.

3. Create a post standup meeting

As the team is reviewing each story they will have in-depth questions, concerns, and ideas.  Use the time right after the Daily Standup to pair program or swarm around items from the Standup.  I like to keep a white board at hand and I write down  ‘Post-Standup’ items as they come up.  This gives everyone an opportunity to participate, including Developers, Product Owners and Scrum Master. There is no set time-box for Post-Standup-it is all about collaborating and getting stories to completion.

4. Allow the product owner to participate

If the Product Owner (PO) has questions about the story or wants to provide insight – let them.  Why Not? This is the time when the team is trying to make sure they are meeting the objectives of the Product Owner.  If the PO asked a detailed question that will take more that a few minutes, move it to Post-Standup.

5. Have fun

Banter a little! Life is too short to just jump into the heavy details of the Daily Standup or Daily Scrum.  Take a few extra minutes (see #1) to strike up conversations with your teammates.  Use it as an opportunity to do a little team building and get to know each other. Come prepared with an interesting topic and throw it out to the group such as “Name three things that you think will be obsolete in 10 years”. You will be surprised how far a little fun will go!

Talk to Us Today

Agile isn’t something you do, it’s something you become

I would not dub myself the queen of anything.  But if I were to dub myself the queen of something, I would be the queen of abstract logic.  That’s a thing, right?   I love speaking in metaphors and analogies.  (And it’s totally not annoying at all.  Usually.)

It comes in handy when I’m asked questions about fitting Agile or Lean into situations one doesn’t normally consider when thinking of Agile and Lean practices.

There are numerous examples I could give where I’m asked about applying Agile methodologies in areas where typical Agile practices we focus on need to be thrown out.  In many of these situations, Agile development tools and processes don’t apply.

pile-of-booksFor example, I was recently approached by a woman who, along with her children, runs a mail order second hand bookstore from her home.  She wanted to know how Agile could help her become more efficient.  (This is where after explaining what Agile is, I go into Lean processes and get giddy about Kanban.)

topicHomeschoolTeaching_smallIn another example, I homeschooled for 14 years.  In the homeschooling community there is a constant strain toward making the most of your time, accomplishing certain milestones, and struggling with the balance of “the way things should be done” versus “how things work best for our family”.

Situations like these are where I get to talk about Agile as a principle.  I love it.

Agile is not an instruction manual for success.  It is a principle.  The processes and tools we use – such as Scrum, XP or Kanban – have been created to assist us in applying Agile principles in areas that require some kind of team structure and standardization.

But “Agile” is not a process.  Until you can wrap your mind around that, it will be hard to truly bring “Agile” into your situation.

I find myself often saying to people, “Agile means pretty much what we all picture when we hear the word:  the ability to move quickly and easily.”

Very often in life as well as in business, we lose agility because we get bogged down by routine.  Things we do out of habit because that’s The Way it’s Always Been.

To become Agile means that you begin to analyze your own actions and change the way you do things if those ways are making you slower.

Agile does not mean you throw out all standards and structure.  Agile means that you only have standards and structure that work to push you toward your end goal.

One simple example I use involves kitchen organization.  Do you make coffee every day?  Is your coffee maker in one part of your kitchen, your mugs in a cabinet across the room, and your coffee in the pantry?  Why?  Because “dishes must be in the dishes cabinet” and because “coffee must be with the food in the pantry”?  Who made that rule?

1As far as that goes, who said your coffee maker has to live in your kitchen when you spend your morning in the bathroom?

If you’re Agile, you stop and question the way you do things.  You are free to move the mugs and the coffee so that they’re within reach while you’re standing at the coffee maker.  (Or heck, put them on your night stand if that’s where they work best for you.  Just don’t tell people I suggested it.  They already think I’m weird enough.)

You don’t stop and question if that is the “right” way to do things.  You simply realize that it makes you more efficient, and you adjust to make the change.

“Agile” isn’t the part where you move your coffee mugs.  “Agile” is what made you stop and question where the coffee mugs were in the first place.

“Agile” doesn’t care where you keep your mugs.

“Agile” only means that you continue to review your own process and make improvements when you need to do so.

Many times, people get stuck on this and think that “Agile” means you’re following some sort of standardized plan.

Agile is exactly the opposite of that.

When I think of great examples of agility in this world, I always think of monkeys.  There are few things more demonstrative of agile than a monkey who quickly and expertly moves from branch to branch in a tree.  They’re agile little suckers.

Monkey-On-Tree-50Monkeys aren’t bogged down by wondering what is right or wrong when it comes to grabbing branches and moving themselves along to their destination.  They trust themselves.  They adjust as they go, quickly grabbing which branch makes the most sense and moving on to the next.  Rarely will you see monkeys following the exact same climbing pattern on four different trees.  They adapt quickly to their current task and they move fast.

I once saw a monkey fall during his climb at the zoo.  I don’t know if his grip failed or if he missed his mark, but he aimed for a branch and ended up falling about two feet before he grabbed a lower branch and continued his climb.

He didn’t stop.  He adjusted his climb without pausing – skipping that tricky branch his second time around – and made it to the top of the tree seconds later.

That’s agility.  That’s being agile.

Agile isn’t a method.  It’s a principle.  It’s not something you do.  It’s something you are.

Because this is so hard to understand sometimes, artifacts like the Agile Manifesto have been made to put it into terms that apply directly to our industry.
agile manifesto
But when I’m asked by a homeschool mom or a college student, “How can Agile help me?” – there is no manifesto.

That’s when I get to talk about coffee mugs and monkeys.

Talk to Us Today
post =