Part II: Some Solutions
Continued from Part 1, with the same disclaimer applied.
Collaboration and Distributed Scrum
If you’ve been in a successful Scrum Team with geographically distributed members, I would really like to hear from you, O Venerable Master. After all, team effectiveness has been known to diminish with as much as 2 meters of physical separation. If you must do Distributed Scrum (hopefully as a transitory step), then here are a few tips that will (I hope) save you the trouble of learning the hard way:
- Obviously, ensure everyone on the team is fully aware of language and cultural differences, especially the Power Distance Index (if that sounds familiar, it’s from Malcolm Gladwell’s Outliers)
- Email is only 14-17% effective as a medium of communication (Videoconferencing helps)
- Further, information is lost exponentially as a function of distance and overhead of tools used (simply put, people are inherently lazy…)
- …Which may prevent you from achieving fully cross-functional teams without specialists
- Agile at scale requires trust at scale
- Everyone needs to have access to the same infrastructure (at the same latency) and an identical development environment
- Get Agile Evangelists (SM, Coaches, stakeholders) at every location and get them to agree on your organization’s Scrum process
- Eliminate mixed signals, possibly by having a Proxy Product Owner
- Empowerment and Autonomy are useless without Feedback
- Establish an Exchange Program where [at least some] developers from different locations get to experience the reality of their counterparts (This will probably be your best investment)
The most important consideration, given all the specific limitations of your situation, must be that whatever arrangement you come up with, is sustainable. Create success stories and replicate the model. And note that Distributed Team can very well exist without Distributed Scrum.
Why Are You Doing Scrum, Anyway?
One day I’m going to be an Anti-Agile Coach. Because I’m convinced they’re so many people getting it wrong, that there’s a lot of money to be made from it. But first, some free advice: You should really consider if Agile or Scrum is really applicable to your Organization, Industry and Business Context. A good starting point is the following thought process:
You would like to adopt Scrum (or Agile) because…
- …Your scope/specifications/customer commitments change often (If not, you might be indulging in WaterScrumFall)
- …Your market changes often, requiring quick adaptability (e.g. Competition pops up out of nowhere overnight)
- …You need to deliver (or release) continuously (As opposed to a one-time deployment, followed by maintenance)
- …Your technology stack can/will change often (i.e. you haven’t invested tons of $ in license fees, and/or you will evaluate multiple options)
- …You have the flexibility to experiment/take risks, and your organization rewards failure (or at the very least, doesn’t penalize it)
- …Your dev team is nascent, so you expect dev processes to evolve
- …Your industry is neither mission-critical nor heavily regulated (although there are exceptions as Nancy Van Schooenderwoert explains)
- …You have metrics to show that Scrum would be more effective
- …Your Admin/HR/IT teams have Daily Standups (yes, I have seen them happen)
- …Everyone else is doing it
If you scored low on the above checklist, please consider that Iterative Software Development is still a thing, especially if you’re dealing with hardware or manufacturing. It’s not Waterfall, but it’s Scrum with a bit more commitment.
On the other hand, you might be in a field of work where you’re ready to treat software development more like Surgery than Civil Engineering (as Dan North explains in his talk).
Whatever you do, don’t indulge in Reverse Waterfall: Convincing yourselves that what you delivered is in fact what you intended to deliver.
(Please share your thoughts and experiences as a comment or connect with me on Twitter: @survivalcrziest)