top of page

Optimizing Distributed Agile Development

In 2007 the topic of offshore distributed agile was front and center in the outsourcing community. There were lots of differing messages regarding the validity of actually using agile across two or more teams in two or more locations. We can say we've come a long way since 2007 but there are some key messages that haven't changed and then some that have.

I had presented at a venture capital forum that year on the topic and recently pulled out some of the content to contrast what we are saying today. I was interested to see how our learning and thinking has changed. Here are some of the things that haven't changed since 2007.

Past thinking included messages such as:

  • Highly collaborative approach required

  • Traditional supplier-client relationship is difficult

  • Result: client will drive the supplier to waterfall

  • Client must provide/support key roles (Product Owner, Scrum Master) and shares success metrics w/supplier

  • Constant attention and guidance is not the same as babysitting

  • The traditional approach is often based on “best guess” with contingency built-in

  • Agile projects on average cost competitive

  • We’re not just writing “cool code” but rather…

  • Requirements that relate to business value

  • Shaped daily by the Product Owner and business

  • High profile projects are canceled/written off

  • Proven and successful approach to reducing risk

  • A framework, metrics, and measurements are critical to ensure quality and support the team

  • Work to understand the roles needed to support the effort required

  • Maximize your budget by choosing the optimum team size.

  • Going slower isn't safer and can cost you more

Current thinking has changed and called out some distinct differences:

In looking at some of the statements being made by enterprises today we hear that stakeholders are frustrated with slow IT development processes. We've also come to realize that adding more people doesn't necessarily equate to meeting the development demand on IT. If you are someone who is reading this and thinking that you already get this concept then just know it is not prevalent thinking across most large organizations. There is still a very real mindset that more people get more done. While true in some cases, it is proving not to be the case in many IT projects.

Outsourcing is still a very good strategy and not in question, rather it is how we best use our outsourced teams to optimize the entire supply chain that is in question.

That said, IT is also realizing that there are many mature processes that are simply not being leveraged. There isn't a single answer to the problem but there are many narrow approaches companies take to solve problems or to try and deliver projects vs. leveraging a wider set of practices that, when combined, can provide outstanding results.

In terms of extending agile capability in the organization, especially as it relates to distributed teams here are the messages that are relevant today:

  • Maximizing the flow of value to the customer vs. Maximize team velocity

  • Learning happens at the rate it can be consumed by team, organization, customer

  • Increasing value, improving flow and advancing quality far outweigh the "staffing up" approach

  • Understanding which practices and approaches are fit for purpose:

  • Scrum, as a core agile practice, does indeed “Optimize the Team”...

  • But not necessarily the business since it is often limited to application development

  • Lean, as an overarching process, teaches us to try and Optimize the whole (or as wide as possible - as far left and as far right in the P/SDLC)

  • Kanban, as a tool, is more relevant today - touching the integration into the PDLC in terms of Brand, Marketing, Sales, Operations and all things business being flowed to the customer

  • What do the business really want

  • To connect with their customers

  • To serve them with the right things, at the right time

  • Innovation and creativity that creates differentiation

  • To create new customer experiences based on new technology

  • To move faster - Stop being bound by the legacy of traditional IT

  • An engaged organization (including suppliers)

  • More value

Some considerations in closing out this topic:

  • Invest in an Agile “Enablement” strategy not just Scrum

  • Understand the impact that can be made across the organization

  • Enablement vs. Consulting

  • Emphasize a culture of learning “to do the work” amongst your employees and the extended supplier team

  • Education vs. Training

  • Develop a learning path for key roles and teams that can include your supplier team

bottom of page