Project Management

Disciplined Agile

by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog

RSS

View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes
Kashmir Birk
Klaus Boedker
Mike Griffiths

Recent Posts

The Disciplined Agile Enterprise (DAE) Layer

Disciplined Agile (DA)'s Value Streams Layer

The Disciplined DevOps Layer

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

Effective Daily Stand Up Meetings

Standup

A few weeks ago one of my customers asked me for advice about daily standup meetings (also called Scrum meetings, morning meetings, or better yet coordination meetings).  Her feeling was that her teams could become more disciplined in their approach to coordination meetings so she asked if it would be possible to see how teams in other companies run their meetings.  I indicated that there are a lot of good videos on YouTube and that I would write something up soon in a blog posting.  So here goes.

  1. Put your meeting strategy on the wall.  Put the rules (see below) on the wall in the space where you hold your coordination meetings.  If you have virtual meetings online, capture them there (in a wiki for example).  We call things like this information radiators in agile.
  2. Coach people.  It takes time to build up effective meeting skills.  At first you’ll want to coach people publicly within the team so that everyone can learn.  After awhile, if someone is still struggling (perhaps they’re often late to the meeting or aren’t sufficiently focused) you may want to coach them privately.
  3. Call it a coordination meeting.  Terms such as “stand up meeting” or “Scrum meeting” aren’t very clear, but “coordination meeting” is.  By using clear terminology you make your expectations regarding the purpose of the meeting crystal clear, thereby reducing the chance for confusion.
  4. Set some rules.  As a team, discuss what how you intend to run these meetings.  Potential rules you should consider adopting include:
  • Arrive on time.  ‘Nuff said.
  • One person talks at a time.  There shouldn’t be side conversations going on, not only is that disrespectful it results in those people being distracted from coordinating with the rest of the team.
  • Come prepared.  As a meeting participant you need to know how you’re going to answer each question before you get into the meeting.
  • Define what you want to discuss.  There are many different questions or issues that you can discuss in coordination meetings.  Scrum suggests “What did you do yesterday?”, “What will you do today?”, and “What’s blocking you?”.  Other questions could be “What did you learn today?”, “What will potentially block you?”, “What value did you deliver since the last meeting?” and many others. 
  • Someone different leads each day.  A common strategy is to rotate the responsibility of running coordination meetings between team members.  This is a great learning experience for some people and certainly helps everyone to recognize how these meetings could be run more effectively.
  • Stay focused.  The goal is to coordinate as a team, and the easiest way to do so is for everyone to focus on that goal.  So stay off your phone, don’t be reading email, don’t be holding side conversations, and only focus on the issues/questions you’ve agreed to as a team.
  • Stand at first.  Having people stand up tends to keep meetings short but can prove to be artificial (I’ve been on coordination calls where people working from home or other locations have been asked to stand, yikes). 
  • Coordinate around a task board.  When you gather around a task board much of the status information that you may want to communicate to the meeting is provided by the task board itself.  This provides opportunity to streamline your meeting process.

Here’s a few interesting videos that I found on YouTube:

  1. How to Hold a Daily Standup. This short video provides several good tips for holding a standard “Scrum meeting”.  It suggests that people answer the three standard Scrum questions so take that advice with a grain of salt.  And the background music is a bit cheesy although fun.
  2. Agile Simulation Part 20: The Daily Standup.  This video is interesting because it starts with a dysfunctional version of the meeting and then shows an effective one.  The common mistakes the video shows include running it like a status meeting instead of a coordination meeting; people coming to the meeting unprepared; discussing inappropriate issues during the meeting; showing up late to the meeting; having side conversations; one person was basically checked out and was lying down on a bean bag chair; and a non-team member started driving the conversation at one point.
  3. How a Lean Thinking Company Runs a Morning Meeting. This video overviews the approach taken by an organization’s leadership team to their morning meeting.  They look at their task board, a whiteboard with stickies.  They’ve tailored their meeting to reflect the needs of what they need to coordinate, and in the video they discuss how they came to putting this meeting together.  It’s interesting to note that they are in multiple locations, so they video conference daily.
  4. Lean, the Morning Meeting at Fastcap. This is another non-software development example.  This team explicitly changes the leader of the morning meeting each day to help them grow their skills.  One of the things I like about this video is that their focus is to share critical information with each other.  This includes mistakes, learnings, and any improvements that they made.  The overriding goal is to focus on learning, team building, and to celebrate their successes.
  5. Dodgy Scrum StandUp. This video was purposely put together to show many of the bad habits that people may exhibit during daily stand ups.  These bad habits included not staying on topic; getting into details that most people don’t need to hear; and asking questions around implementation details instead of taking the discussion offline.  One person even threw something at another person, thereby distracting the group.  Another person showed up late, disrupting the discussion.  The team also didn’t refer to their task board (I assume that it was the task board behind people on the left hand side of the screen).

 

 

 

 

 

 

 

 

 

 

 



Posted by Scott Ambler on: April 02, 2014 02:29 PM | Permalink | Comments (0)

Good Practices Are Small, Cohesive, and Loosely Coupled

Categories: Practices, scaling, Scrum

lego1

A few people have commented that Disciplined Agile Delivery (DAD) promotes a wide range of practices, which they like because it makes their options explicit but which they also potentially dislike because there’s so many practices to choose from.  This then leads to the question of why do we need so many practices?  First, there are a lot of practices out there to begin with and our philosophy is to help people know that they have options and help them to select the right ones.  Second, our experience is that for a practice to be easily consumable it should be:

  1. Small.  Small practices are generally more straightforward than larger practices.  As a result they’re easier to understand and to adopt.
  2. Cohesive.  A good practice addresses one issue and one issue only.
  3. Loosely coupled.  Good practices, like good software modules, have minimal dependencies on other practices.

Practices that are small, cohesive, and loosely coupled are easier to configure into more interesting solutions.  For example, the practice of test-first programming (TFP) is combined with refactoring to form test-driven development (TDD).  The practice of (writing) executable specifications can be combined with TDD, or TFP for that matter, to give you behavior driven development (BDD) or acceptance test-driven development (ATDD).  The combination of iteration modeling, model storming, look-ahead modeling, and BDD can give you a strategy for addressing emergent requirements and design during an iteration.

Of these three aspects, we’ve found that coupling has the greatest impact on your ability to tailor your approach to meet the unique situation you find yourself in.  Just like highly coupled software is difficult to maintain and enhance, processes built from highly-coupled practices are too.  For example, consider the way that Scrum describes product backlogs.  A product backlog is one of several strategies that agile teams may use to manage their work.  In the case of Scrum, the strategy is to prioritize requirements by business value and then focus on implementing the highest priority work at all times.   Unfortunately Scrum has coupled many important practices to the product backlog concept.  For example, initial requirements modeling is often referred to as populating the backlog.  Prioritization of new requirements and exploring upcoming requirements is referred to as grooming the backlog.   There are several potential problems to consider:

  1. The term “populating the backlog” masks the fact that not only are you writing initial functional requirements (for example user stories or features) as part of your initial requirements modeling efforts you’re also sketching things (processes, screens, data structures, …), identifying non-functional requirements, holding modeling sessions, and many other things.
  2. It makes it harder for people new to agile to understand how it works.  Think of it like this, what’s a more descriptive term, “populating the backlog” or “initial requirements modeling”?
  3. It makes it harder to combine practices.  If you wanted to swap out the product backlog for something a bit more sophisticated, such as a work item list, or something leaner like a work item pool, what do you do with the practices coupled to product backlog?  Do you  rework “backlog grooming” to be “work item list grooming”?  Do you rework “populating the backlog” to be “populating the work item pool”?  Even if these things are easy to do, seems like needless effort to me.

In conclusion, we have found that adopting small, cohesive, and loosely coupled practices enables you to adopt and tailor a process strategy that better reflects the context of the situation that you face.    Not only is high cohesion and loose coupling great strategies for software, their great strategies for software process too.

Posted by Scott Ambler on: September 05, 2013 11:47 AM | Permalink | Comments (0)
ADVERTISEMENTS

"To generalize is to be an idiot."

- William Blake

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events