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

Put Practices in Context: #NoBestPractices

There is no such thing as a “best practice”, except perhaps from a marketing point of view.  All practices (and strategies) are contextual in nature.  In some situations a practice works incredibly well and it other situations a practice can be the kiss-of-death.  Two of the philosophies behind the Disciplined Agile (DA) tool kit are that choice is good and that you should understand the trade-offs of the options available to you.  In short, practices are contextual in nature and you should strive to adopt the ones that work best for the situation that you find yourself in.

Let’s work through an example.  A hot button for many people are strategies around cost estimation, typically used for budgeting and forecasting purposes.  In DAD initial estimation is addressed by the Plan the Release process goal, the goal diagram for which is shown below.  As you can see with the Estimating Strategy factor there are several options available to you.  We’re not saying that these are all of the potential estimating options available, but we are saying that this is a fairly good representative range.  The arrow on the left-hand side of the strategies list indicates that the strategies towards the top of the list are generally more effective for initial planning than the strategies towards the bottom of the list.  Your mileage may vary of course.

Plan the Release process goal

The following table summarizes the trade-offs involved with two of the estimating strategies, in the case formal point counting (such as function points) and an educated guess by an experienced individual.  One of the reasons why Choose Your WoW! is so thick is that much of it is tables like this communicating the trade-offs of the hundreds of practices and strategies encapsulated by the toolkit.  As you can see, there are advantages and disadvantages to both strategies.  You can also see that there are situations where each strategy potentially makes sense.  Although you may not like a given strategy, I personally abhor formal point counting, you should still respect the fact that the strategy is viable in certain situations (perhaps not yours).

 

Strategy Advantages Disadvantages Considerations
Formal point counting
  • Fulfills contractual obligations in some situations – for example, the US Government often requires function-point based estimates.
  • Provides a consistent way to compare projects and team productivity.
  • Often increases the political acceptability of the estimate due to the complexity of the effort to create it.
  • Greatly extends the Inception phase effort.
  • Provides a scientific façade over the estimation activity, even though estimation is often more of an art in practice.
  • Reduces team acceptance of the estimate because the estimate is typically produced by a professional estimator.
  • Historical data won’t exist for new technology platforms or development techniques, requiring you to guess the value of some complexity factors.
  • Provides a mechanism to compare the productivity of development teams, which can motivate them to over estimate and thereby decrease comparability and the value of your historical database.
  • Total cost of ownership (TCO) is very high as it motivates questionable specification practices, which in turn motivate change prevention and other poor behaviors by the development team.
  • Overly long estimation efforts in an effort to get the “right answer” often prove to be far more costly than the actual benefit provided.
  • Beware of misguided desires for “accurate” or “consistent” estimates which prove costly to produce in practice yet don’t improve the decision making ability of senior management to any great extent
Educated guess by experienced individual
  • Very quick and inexpensive way to get a reasonable estimate.
  • Requires that you have an experienced person involved with your project (if you don’t, then you should consider this a serious risk).
  • Explicitly reveals to stakeholders that estimating is often more art than science.
  • Some stakeholders may be uncomfortable with the fact that you’re guessing.
  • Beware of estimates by people who are inexperienced with the platform or domain or who do not know the abilities of team.

 

There are several reasons why DAD’s goal-driven approach is important:

  1. It makes your choices explicit.  If your team wants to truly own your process then it first needs to know what choices are available to it.
  2. It makes it clear that practices are contextual in nature.  No practice is perfect for all situations, every single one has advantages and disadvantages.  Are you choosing the ones that are most appropriate for your situation?
  3. You can have more coherent discussions of the trade-offs that you’re making.  We have endless religious battles in the IT industry around process-related topics.  This often happens because people choose to focus on the benefits of their favorite practices and to downplay the disadvantages (or worse yet are oblivious to them).  To help your team move to more effective practices it’s important to recognize the trade-offs involved with each, to then discuss them rationally, and then decide to adopt the strategy that is most viable given your situation.  Note that this doesn’t necessarily mean that you’re going to adopt the best practice from the start, but that instead you’ll adopt the best one that you can right now.  Later on, perhaps as the result of a retrospective, you’ll decide to make improvements to your approach (in the case of process factors where the strategies are ranked by effectiveness, your team may choose to adopt a strategy higher in the list).
  4. Improves the effectiveness of retrospectives.  During a retrospective it is fairly straightforward to identify potential problems that you’re facing, what isn’t as easy is identifying potential solutions.  You can improve retrospectives by having these process goal diagrams available to you to suggest potential strategies that you should considering adopting.
  5. You can avoid reinventing existing practices.  Many very smart and very experienced people have found ways to deal with the same challenges that you’re facing today.  Furthermore, many of them have shared these strategies publicly.  If you don’t know that these strategies exist you are at risk of wasting time reinventing them, time that could be better spent adding real value to your organization.
  6. It enables scaling.  Teams in different situation will make different process decisions.  Although teams at scale, perhaps they are large teams or geographically distributed, will follow many of the same practices as small co-located teams they will also adopt a few strategies that make sense for them given their situation.   DAD’s process goals provide the insight that teams need to understand how they can address the challenges associated with the scaling factors that they face.

For a more detailed discussion about the challenges around “best practices”, you may find the article Questioning Best Practices to be an interesting read. 

Posted by Scott Ambler on: March 05, 2015 05:16 AM | Permalink | Comments (0)

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)
ADVERTISEMENTS

"A classic is something that everybody wants to have read and nobody wants to read."

- Mark Twain

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events