Come to the Science Fair

Remember that thing we folks that practice Agile call the Agile Manifesto.  You know the thing that where 17 smart folks got together and came up with a set of four values and twelve principles to help guide and shape the behaviors of those involved in software development.  Everyone might not be able to rattle off the principles, but most of us understand and appreciate the common sense of the four values.  At the core of all the Agile Manifesto values is a well maintained relationship between the delivery team and the customer (or Product Owner).  And this is where challenges have emerged and often things start falling down.  Here’s a common scenario that often plays out:

An organization starts making a shift to use an agile related process, let’s say Scrum.  They train the delivery team and the product owner, then kick it off with a team or two.  Everyone starts to work and they start seeing productivity gains right away.  And the teams are seeing vast improvements in communications and building products that customers like.  The organization then says — let’s have a few more teams start drinking from the Agile fountain.  Things are going well, but what starts happening is that during this scaling process — people start competing for meeting rooms during the sprint planning and review cycles, and the product owner’s time quickly becomes a constraint. Thus, teams start alternating their sprint schedules to deal with the room/resource issue and the product owner spends less time with all teams and seems to only focus on those teams that work on things that are not doing well or they like.

Now you are asking, what’s the problem?  Well, one of the best things that you’ll find when you start working in small incremental delivery cycles is that the teams form a rhythm (or cadence).  This helps for predictability that helps the organization in planning and more importantly, helps the team members in planning their lives.  Most people like repetitiveness and everyone is habitual (or at least most folks involved in software development), so by having multiple teams on different rhythms — organizations lose the natural state of “steadiness” that comes with shared cadence.

The other big problem with the scenario above is that the face time and feedback with the customer (or product owner) is critical to having success with all four of the agile values.  When teams start realizing that time with the product owner is being a challenge, they tend to simply give the product owner a pass on attending any of the iteration planning and or review — and they just ask for his or her time for stories and acceptance criteria.  This means that they lose out on the critical feedback that comes out during the reviews and demos.

Does this sound similar?  If so, here are some ways to help overcome these common time constraints that appear when you start scaling out agile.

  • Introduce a Gap. If you are using an iterative approach, introduce a gap between your iterations.  The idea is to get everyone on the same iteration schedule and rhythm and by adding the gap, you’ll give time for folks to juggle room schedules and stakeholder time to ensure participation.  During the gap, the team will have time to properly plan the  upcoming iteration, work on a design/research spike, and or work on an item from the team’s technical wish list backlog.  The gap also can afford the team a quick breath and might also be an easy period to squeeze in some personal business time.
  • Go Short. This may seem to be non-sense; however, if you are using an iterative process then trying working in shorter cycles.  Although it takes some adjustment, shorter cycles reduce the time it takes to iteration plan and review.  The end result is a tighter focus and that focus is generally on what is needed next.  Similarly, move to a lean or continuous flow process (give this a read to learn more).
  • Lunch-and-Collaborate. Schedule meetings around lunch and, of course, have food.  Lunch is generally less formal and can be perfect for brainstorming, story workshops, demos, and team building.  Although team members some times need a break from work, most team members don’t mind meeting when food is involved :)
  • Record Your Demos. A meeting that you don’t want to miss out on getting feedback is the demo; however, this is a meeting that for some reason the product owner and other key stakeholders will often miss.  This meeting is not only about showing off and having the team get some positive feedback — it is more about just getting feedback.  Try recording the demo.  Make the video less than 10 minutes, don’t worry about it being Oscar quality, just get it done and sent out to all those that can give input.  Solicit feedback within 24-hours of sending out the video, re-enforce the need for the feedback and participation.   In addition to the value of getting feedback from the stakeholders, the recorded demos are great timeline artifacts that can be used for retrospectives.
  • Science FairConduct a Science Fair.  Often when scaling agile, there will be a product owner that works with multiple teams and making time for reviews and demos for all teams around the same time is near impossible.  So to get around this, conduct a science fair — have teams assemble in a meeting room and demonstrate their latest accomplishments.  This is not only a fair for the product owner, but this is a great time for teams to get together and see what the other teams are up to.  This is an event that the whole organization can be a part of and it is a great way to get an organization excited about capabilities forth coming.

So if your teams have had some challenges with face-time with the customer, difficulty establishing a cadence, or you are just not getting valuable feedback — try one or all of the approaches above.  These approaches can not only improve the collaboration, but they can be fun and challenging which will show up in improved team morale.

This entry was posted in Agile Adoption, Agile Management, Agile Project Management, Agile Teams, Enterprise Agile, Scaling Agile. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>