Learn more about Velocity Partners offshore software development company
I was reading an article by Scott Ambler on Distributed Teams in Agile contexts. If you don’t recognize the name, Scott is a long time author and contributor to the software development community. His focus has been on larger scale development and he worked for IBM for a number of years.
He’s also the Father of DAD or the Disciplined Agile Delivery framework that “sort of” competes with SAFe the Scaled Agile Framework and others. Yes, I know, I know too many scaling frameworks indeed.
In , Scott does a really nice job of sharing some relevant surveys and his own insights on distributed agile development. Here I want to focus in on two strategy recommendations that he makes in the article:
Strategy 2: Get the Key Team Members Together at the Beginning
Strategy #4: Do a Bit More Up-Front Planning
And then tell you a story that underscores the importance of these two ideas. So please go and read Scott’s article and then come back and finish my story…
The Beginning
Several years ago I was requested to help a large division within an even larger enterprise to go agile. I had spoken with some of the managers and executives at a few conferences and they liked what I had to say about agile adoptions at-scale. So they asked me to come in and deliver “jump start” training and coaching for several project teams.
The first project was a new initiative for them and it would include about 3-4 Scrum teams. The teams would be split across their Midwest headquarters and India. From my perspective, I proposed one of my typical jump-start programs for them.
In those, I run a few days of training. Then we pull a backlog together via cross-team release planning and start a sprint as soon as possible. I can usually get teams “sprinting” in no more than 3-4 days. The idea is to get them iterating, collaborating, and learning quickly.
Surprise
A few things surprised me when I arrived for the kick-off.
First, the class was packed with around 40 folks. It was a little over my maximum class size, but they were trying to include all team members in the kick-off. The second surprise was that an entire team from India had been flown in for the class. They were staying for the initial jump-start training and for another two weeks afterwards – to execute the first sprint locally as a collection of teams.
The plan was to leverage this time to gain cohesiveness as a broader set of four teams working on an integrated project.
Backlog, Backlog, Where’s the Backlog?
The next surprise came in the form of not having a backlog to work with. You see, one of my prerequisites for running a kick-off like this is that the organization (the teams really) comes prepared with a rudimentary Product Backlog. It doesn’t have to be perfect, but we DO need a list of work for them to do.
As part of the workshop, we do Agile Release Planning as a longer-term activity. I’ve found that it not only teaches the teams principles and tactics, it also gives them a framework for planning a holistic release.
Lacking a backlog, I had to leverage the release planning to include a story writing workshop and creating a mass of user stories (work) on the fly. In hindsight, this worked fairly well as it got the entire team engaged in the envisioning – story mapping process.
The Workshop
Before the group came into the workshop, they hadn’t aligned into teams. Sure, there were some views as to how many teams were needed, skill sets and who might work with who, but the ideas were ill formed. I remember we left it up to the teams to form, based on the mission and vision for the project, which they did by self-directing, forming four teams, and starting to build their individual backlogs.
I also recall the management team being amazed at the insights and balance that the teams exhibited in creating a team-based ecosystem to attack the challenges of the project. While they provided some feedback and guidance, the teams really came up with a sound structure on their own.
This teamwork then led to sound early-stage backlogs that we could use in our release planning exercises. Effectively in a little over a day and a half, we created a holistic backlog for the first release of the project AND a release plan that envisioned each teams efforts in addition to the overall integration across teams.
Believe it or not, those early release plans turned out to be thoughtful and realistic. They were less than a ½ sprint off for the content needed in the initial release. When you consider the amount of ambiguity and the newness of the teams, this was amazing accuracy.
Forming
I often tell this story in my workshops because it’s such a unique and successful example of self-organization.
You see we wanted to have the actual teams work together in the story writing and release planning activity. So as the teams left the workshop and started sprinting, they had already begun the process of successfully forming as agile teams.
Not only on each individual team, but they understood the parts each team played in the overall project. I see this often happening in my workshops, but the experience never ceases to be magical and priceless.
Retrospect, About a Year Later
About a year later I happened to be visiting this client to run another agile jump-start for a set of teams. They had some really good successes with the first few rounds and the recipe we had used for getting a new set of teams focused and moving forward on an agile project.
I happened to sit in on a series of daily stand-up meetings with the original teams, including the offshore Indian team. It struck me immediately that this was not your “normal” offshore, distributed agile team. There was seamless collaboration and communication, with respect and trust being freely given. If I hadn’t known the team was in India, I would have thought it was a local team. That’s how focused, collaborative, and productive the stand-up was.
As I reflected back, I realized that the start-up that we conducted was a primary factor for the teamwork I observed. While the initial costs in flying folks over was high, they were still reaping the benefits of that investment over a year later. Talk about ROI!
Wrapping Up
I want to emphasize the two points that Scott made in his article:
Strategy 2: Get the Key Team Members Together at the Beginning
Strategy #4: Do a Bit More Up-Front Planning
Bringing the teams being together reinforced initial teamwork and collaboration. There’s nothing like going through “basic training” together. And the shared planning allowed for a shared understanding and a unified vision for the project direction.
Quite awhile back I blogged on the importance of Agile Project Chartering and creating a “proper beginning” for agile teams. If you found this article useful, that one may be of interest as well.
I hope that you begin your future agile projects with distributed teams with this advice in mind.
Stay agile my friends,
Bob.