Agile question of the month contest for December 2009

qmark1Want to win an Amazon gift certificate?  This month I am starting a new feature in the blog.  The feature is called “Agile question of the month.”  The way it works is very simple.  I’m going to put forth a scenario based at least in part on a real situation I have come across when doing work with Agile For All clients.  I won’t say what I did, but I’m interested in what others might do.  Each month I’m going to pick one answer which I believe is the best solution.  Assuming the person leaving the best answer also leaves a valid email address, I’ll send them a $25 Amazon gift certificate to use as they please.  Unlike other contests like this one, I’m not excluding any individuals from answering.  I don’t care if you are just learning how to use agile, or if you are an original signatory of the Agile Manifesto.  Everyone is eligible and everyone is encouraged to try for the prize.  With lots of people sharing ideas more people will learn how to be agile problem solvers.

December 2009 scenario:

The client organization for this scenario has 20 software development teams spread across 5 locations including 3 in the US, one in India and one in Germany.  Approximately half of the teams are in collocation situations, but the other half are highly distributed with it not being unusual for a team to have 1-2 members in each of the 5 locations.  The client has decided to do an agile pilot project using 2 teams.  1 of the teams is collocated in a US office and 1 has team members in all 5 locations around the world.  In addition, just to complicate things, this project needs to integrate with 2 teams which are not doing agile at all and are both highly distributed.  The 2 pilot agile teams have been trained in Scrum and understand it enough to begin using it right away.  Assume the agile teams are cross-functional and have a reasonable ScrumMaster and Product Owner (one for each team).  Your role in this scenario is as an agile coach attempting to help make the pilot project as successful as possible both in the short term (2 months or less) and medium term (6 months or more).  After 6 months the client will decide whether the pilot has succeeded and whether to continue using your services.

The question:

As the agile coach, what 3 things will you be doing, examining or helping with in order to make sure the project has short term success AND what 3 things will you be doing, examining or helping with in order to make sure the project has medium term success?

I’m looking for the top 3 short term and medium term items in each answer.  Please use the comments field below to give it a shot.  Be creative.  I won’t answer any questions, so if you make assumptions be sure to tell me you made them and what they are.  The contest will end on December 31, 2009 at 11:59pm Mountain Standard Time.

Good luck!

Related Articles

Responses

  1. You don’t say how many people are on each team so I’m assuming that they are of “Scrum Size” (7-10). Another assumption I am making is that the PM Tool is chosen and that Strategic and Release Planning have already occurred.

    Short Term (Months 1-3)
    1) Ensure that 2 PO’s act as one so the team has a common direction.
    2) I am ensuring that a Scrum of Scrums is being held consistently and correctly.
    3) I am watching the velocity of the distributed team as they will dictate the project length. (The perceived amount of completed functionality by the management decision makers.)

    Medium Term (Months 4-6)
    1) I am continuing the 3 Short Term activities.
    2) I am frequently communicating with the Waterfall Teams mentioned to ensure integration timings are correct.
    2) I am helping the team ensure that they are producing quality code that is automatically and frequently tested at Unit, Integration and Functional levels.

    Picking the top 3 is tough when there are so many variables here. I would also be interested in what you did and how it panned out. I hope it went well!

  2. David, the assumption on the Scrum team size is fine. However, the assumption that strategic planning and release planning has occurred may not be. The project has been approved so at a strategic level I think you are correct. How would your answer change if the team has not yet done release planning?

  3. Short Term:
    1) Establish a definitive location for project progress: select a good online PM tool, train everyone to update it religiously, show PMs to use it to view progress rather than polling developers. Waterfall teams are used to less progress updates and if the PM tool is stale, you’re in trouble.
    2) Ensure open & frequent communication: have daily meetings, move desks together at colocated team if possible, use a virtual communication tool like group chat or Yammer. Make sure that if someone has a question, they don’t wait until later, even if they’re distributed – ask it now.
    3) Identify & fix bottlenecks quickly: iterate quickly to expose bottlenecks in the process and then fix them appropriately. Assuming things will go wrong, fail fast.

    Middle Term:
    1) Ensure the PO has needed buy-in: demo the product to stakeholders, integrate feedback into the backlog, user testing.
    2) Sync up development environment with agile principles – testing, continuous builds, etc. A clunky development setup may have been business as usual but you can streamline it little by little.
    3) Teach the team to manage themselves with retrospectives. A consultant is nice for starting out, but in the spirit of teaching them to fish, show them how to identify problems in their process and work together to find solutions. Show them it’s not about doing things the way they’ve always been done OR about doing things by the agile book, it’s about doing what works to deliver great software efficiently.

    My answers are actually the same whether or not release planning has happened, except revisit release planning frequently to monitor progress & keep everyone’s expectations inline as the velocity steadies.

  4. How many consulting hours can you spent with the client each month from this point to the 6 month mark? In other words, what is my budget?

    Are you co-located with the US team?

    Have the distributed team members received training from you or from books or public scrum classes etc?

    What’s happening with marketing/product management – how are they involved?

    What is the culture/temperature of the organization? Who is positive, who is neutral and who is negative about the change effort? Who is your sponsor – who is paying?

    I have a million questions 🙂

    At a minimum I would hold a weekly call with the 2 scrum masters together to coach them on the change effort. and to help them with the many adoption related impediments. face to face would be MUCH better.

    Margaret

    1. Margaret, for most of your questions you can make whatever assumptions make sense. On the training, you can assume the agile teams were trained “well” in private courses. I don’t want to give too much more insight because I really want to see people be creative in their answers.

  5. Bob,

    If Release Planning has not occurred yet then I would change Short Term #3 to:
    3) Extending the Release Planning meeting to put more effort into planning items such as Definitions of Done, PO availability, Metrics, Risk Management, as well as Documentation/Communication and Escalation Plans.

  6. Disclaimer:
    I am not an Agile Coach and have no Agile consulting experience. I have not encountered a scenario like this. I have read through the answers and comments already given and share some of the same answers 😉

    Snarky Comment:
    I would first clarify the primary goal of the pilot project with the client. Is it to get working software out the door or is it to purposefully stress the Agile Adoption process. If it’s the former I would question the need for 4 Teams touching the project. For a pilot that’s jumping in the deep end pretty quickly when you only know how to doggy paddle. Yadda yadda yadda. For the sake of the spirit of the question I’ll assume the context of constraints given have been properly mulled over 😉

    Assumptions:
    – Teams have a good understanding of Planning, Stand Ups, Retrospectives, Backlog grooming, SoS, etc.
    – Teams could fair pretty well on their own on much smaller projects.
    – Teams are or will be working off the same code base and have or will have a continuous integration environment.
    – Customers, client and stakeholders are engaged.

    3 Short Term Items:

    1) Risk Assessment “What could possiblie go wrong?”- I would establish a comon area for the Teams to capture and prioritize risks. An Impact/Likelihood matrix could be affective. Have teams pull high priority risk items into Team iterations, find a common understanding of what it means when that risk is done (properly addressed) and get them on the Taskboard.

    2) Dependency Management and Cross Team Communication – Establish, and reestablish, working relationships with other Teams especially with the 2 non-Agile integration Teams (chances are they have other priorities). Along with cross Team Agile Ceremonies and PM Tools injecting members from dependency Teams as needed may also help ensure shared vision, ownership and accountability. Collocate those that can. Skype and Desktop share with those that can’t.

    3) Team Autonomy – Help Teams find High Cohesive Low Coupled Stories that allow them to work independently of each other but not at the cost of integration (from Stand Back and Deliver).

    3 Medium Term Items:

    1) Exposing and Attacking Organizational Impediments – Sure enough by now some kind of seemingly unmovable pre-existing Company SOP, Bureaucracy has surfaced that is constantly getting in the Teams way. I would leverage the trust the Teams have built with the Organization to help remove those impediments.

    2) Empowering Teams – For the first 3 months I’m assuming I have fallen into being the glue for the Teams in certain areas to ensure project success (see the 3 Short Term Items above). I would be testing the waters a bit to see how much I could pull away.

    3) Play Together – I would be on the look out for anything interactive the Teams could do together Online Poker, Gaming, anything fun that the Teams could do on a regular basis to strengthen their bond outside of project work.

    Thanks for letting me play!

  7. I see 3 clear entries in the contest. Comments from David Updike, Amber and Nate McMahon seem to mee the basic criteria.

    I think all 3 of you have done well! Some things I was looking for were things which seem different from a coaching perspective than they do when you are managing a team or part of a team. For example, as a coach it is more about leading and facilitating than telling the team how to achieve success. In the end the team needs to own their own success, so I was hoping to see ways to avoid just “implementing” and instead to “explore possibilities.”

    I like that Nate asked what the goals are. How can we be successful if we don’t know what success looks like? Great job in the snarky comment :-;

    I like that David concentrated on getting the teams working well together early. The Product Owners and Scrum of Scrums working well is clearly a key piece of the puzzle (assuming any reasonable definition of success), but it would have been even better if he had asked the team how they would solve the underlying problems. Well trained Scrum teams should have chosen those methods and they would then own the success of them.

    I like that Amber was focusing on team interaction, collaboration and flow. Again, those will be important elements of any sort of success. But again I wish it had been in the context of asking the team how they would like to solve those kinds of issues. You can always help guide a team to the right answer if they have no ideas, but it is sometimes difficult to get them to buy into the answer you give them. I’m especially concerned about the “train them to update it religiously” comment. I’ve not seen many situations where that has worked.

    David and Nate both mentioned the non-agile teams which is good. Again, success will almost certainly involve how well the teams all played together.

    Amber and Nate both mentioned resolving organizational impediments or bottlenecks.

    Amber and David both mentioned some common engineering practices.

    As you can see, there is a lot of good mentioned in all of these answers. In the end I had to evaluate each one against what I would personally have done and see which resonated the most with me. Thanks to each of you who was brave enough to put an answer out there. I really appreciate it. Unfortunately I have to disappoint 2 of you this time out.

    The winner of the December contest is…

    Amber

    I picked her answer because she was the only one who mentioned use of retrospectives. I believe agile is a self-correcting process when done properly. To me that means retrospectives have to be done well. Doing so can correct a multitude of other mistakes along the way.

    Well done Amber! A $25 gift certificate to Amazon will be on its way once I confirm your email address.

Comments are closed.