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.

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!

This post was mentioned on Twitter by AgileForAll: Have you answered the #agile December question of the month yet? Best answer gets a $25 Amazon certificate http://bit.ly/58rUPO...

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.

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

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.