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