03
Oct
Building Trust in Distributed Agile Programs
2 Comments Distributed Agile Development, On Agility agile chartering, distributed teams, gaining trust, people first, startup
I was listening to a webcast / podcast by Johanna Rothman just the other day. She was sharing on building trust in agile teams, with distributed teams being a focal point. Trust in this case was both within the team and surrounding the team. She mentioned 8 principles that help to guide the building of trust. They included:
- Know where (when) everyone is
- Start with yourself
- Extend trust before you demand it
- Assume “helpful” model
- Make sure the infrastructure works
- Names matter
- Start the program right
- Agile vs. Fixed mindset
You can listen to the podcast .
Some of these are self-evident, and I won’t amplify them very much if at all. But some of them resonated with me and I want to expand on them.
And please don’t get hung up on the word trust here. Consider these principles as part of your tool-kit for creating high-performing distributed agile teams.
#7 – Start the program right
Before I joined Velocity Partners, they cross-posted one of my blogs. It’s sort of bad timing because I suspect it might have gotten lost in the shuffle. It was entitled: Distributed Agile Teams – The ART of the START and you can read it here.
One of the points I made in this blog post was how crucial it is to start your projects well. It always has been whether you’re doing Waterfall or Agile. And it’s even more important when you’re operating in a larger-scale or distributed environment. It encompasses some of the following
- Establish & align your shared Vision & Mission for the project
- Establish goals for measuring progress and ultimate success
- Form your team: introduce them, training, shared space & tooling and give them the time to “form”
- Establish a clear Product Roadmap and perform cross-team Release Planning
- Teams need to ‘own’ their Product Backlogs – contributing to them, grooming them, and organizing them
- Don’t ignore the agile principles, for example: daily stand-ups for collaboration or whole-team planning and demo’s
Johanna is absolutely right. If you want to succeed with a distributed agile project, you must invest in a “Proper Start” for the effort. For you PM purists in the audience, that implies project chartering and a solid project kick-off.
#1 and #6 – People matter!
Johanna makes the important point in both of these that knowing your team-mates truly matters. The first one revolves around knowing which time zones everyone resides in – then keeping this information up to date so that everyone understands meeting & discussion dynamic constraints. In a truly collaborative environment, team members must commit to the collaboration. So know and factoring locale into the interactions is crucial. And it should never be an “excuse” for dropping agile principles.
But beyond the time zones, simply get to know the people – their names and how to pronounce them. Learn something personal about everyone. Take the time to get proper introductions and ongoing sharing around the team. Iterative retrospectives are a place where you can establish a practice of gaining ongoing insights into your team.
And if the budget ever allows for – get your teams physically together for team building, training, familiarization and fun. Your results will reflect the increased synergy.
#5, Make sure the infrastructure works!
I’ve made this mistake multiple times in my own agile leadership and coaching experience. Often the teams would come to me and complain about the infrastructure:
- Insufficient code coverage of tests; little/no test automation
- Slow builds; lack of integration testing
- Problems with our Continuous Integration & Continuous Deployment
- Lack of environments / virtualization
- The code base needed some restructuring for improved
- The distributed team tools (both development and collaboration) suffered from network performance issues
While I would listen and provide investment and prioritization around some of these things, getting our release “out the door” always trumped infrastructural improvements. I’m here to tell you that was always a huge mistake.
You’ve got to create a backlog of infrastructure strategy, issues, and impediment; then work it aggressively with your team. Why? Because it’s slowing you down!
Wrapping Up
Johanna Rothman is a true treasure to our agile software community. Nowadays she focuses quite a bit on Program-level agile advice. You can get more insights and advice here:
Stay agile my friends,
Bob.
2 Comments Distributed Agile Development, On Agility agile chartering, distributed teams, gaining trust, people first, startup
Oct 04, 2013 @ 09:05:50
I would go as far as saying investing in travel (both ways) and becoming familiar with and enjoying each others cultures will not only pay for itself but will result in gains over and above the costs. I’d also suggest using video (not just voice) when chatting isn’t working. This is especially effective if you have invested in travel and have a significant relationship with the person on the other side.
Oct 04, 2013 @ 14:12:42
I couldn’t agree more Brian. There’s a study by Mhebrian, etc. (I may have gotten the spelling wrong
from the 1960′s where they identified three aspects of communication: words, inflection, and body language. Each contributes about 10%, 35% and 55% to our understanding. Now the study IS dated and perhaps slightly off with today’s teams, but I think the point is still relevant. If you think about it then: documents, email,and text messages are only about 10% effective in getting the point across. I think knowing your audience (having met them) increases the effectiveness. I always tell agile teams to move up in this range as much as budgets and equipment allow. You’ll always get better results!