In 2006, a company named SirsiDynix in the US successfully executed a fairly large and complex project using a distributed agile approach with help from StarSoft Labs, an Eastern European and Russian outsourcer who was an early pioneer in distributed agile methods.
The project was the development of a 4th generation library server that had over 120 million users globally and generated over a million lines of java code. This project was so successful that it eventually became the headline cast study in many presentations on the subject, including Jeff Sutherland’s presentations on Hyper-Productive Scrum.
Since 2009 various surveys tell us that at least 58% of all companies surveyed are using agile practices (mainly Scrum) in a distributed environment. Most recent surveys show that number above 65%. As the outsourcing market has developed so has the interest in adapting agile across multiple teams in multiple locations. That said, despite all the success, there are still many questions and concerns on how well-distributed agile works.
We’ve learned much since 2006 and even 2009 and there are elements of past and present thinking that are worth sharing and will hopefully be useful to those in the midst of a distributed agile approach or those considering one. There are also lessons learned for those that have seemingly failed. Let’s look at some of the past thinking.
Past thinking on the subject told us that to be successful with a distributed agile approach you need to give it proper awareness and attention. In other words:
- A highly collaborative approach is required because the Traditional supplier-client relationship is often difficult and a common result is that either the client or the supplier will drive the project to a waterfall or even compressed waterfall approach
- The mantra there is no good news there is no bad news there is just news is difficult to maintain in a vendor supplier relationship
- The teams (client and/or client and supplier) must consist of key roles:
- Product Owner: shares success metrics w/supplier
- Scrum Master
- Technical Lead: domain expertise
- A “Throw over the wall” approach doesn‘t work which is why we want to get away from traditional outsourcing models that have historically failed us
- Constant attention and guidance is not the same as babysitting, which is why the Product Owner needs to be engaged regularly. If there is no one at the wheel then the car is not being driven
There are distinct differences in a distributed agile model:
- The traditional approach to outsourcing is often based on “best guess” with contingency built-in from the supplier side coupled with complex contracts that talk more about costs and penalties vs. outcomes
- Agile projects, on the other hand, are cost competitive on average
- Requirements are defined to relate to business value and not written just for the sake of cool features
- The requirements are influenced and shaped daily by the Product Owner and business (end-users)
- Waterfall projects are failing at rapid rates and the stats of failed projects is only increasing with the use of traditional methods
- Agile brings with it a disciplined approach and reduces the risk of failure
- People are working together, on multiple teams and locations, all delivering on shorter release windows and those releases deliver functionality that has been prioritized with the value it brings back to the business, therefore making it useful
There are also “must-haves” if this is going to work:
- People agree on a communication plan
- Face-to-Face planning meetings (quarterly)
- Daily stand-up meetings using collaboration tools
- Maximize team velocity needs to be determined
- Better to have 7 people for 1 month than 1 person for 7 months
- Costs of outsourcing contracts do not only relate to team size
- Set boundaries for the project that you’ll stick to
- An escalation and governance model must be agreed
- Many factors contribute to shifts in the project
- Both the client and supplier need to be very sure what “success” is
- Clearly state success indicators in the SOW
- Challenge them early and often
- When the Product Owner signs off has taken a look and given it a “thumbs up” approval then it’s done. This has two benefits;
- Ensures that the product owner looks at the functionality delivered in a timely manner
- Prevents “bugs” where the story does not meet the end user functionality but the development team have never been told by the product owner that the functionality is required
That is a good summary of past thinking on distributed agile and I’m assuming most people wouldn’t argue with any of those points being relative today as well. But there is present thinking that needs to be considered. We’ve all learned a lot through the various failures and successes.
Present thinking tells us that agile in general, not just distributed agile, is being influenced by a number of factors including:
- Stakeholders are frustrated with the slow IT development process
- Adding people isn’t necessarily enough to meet the IT development demand
- There are now many mature IT delivery practices that are not being leveraged by organizations
Some of the main differences in the thinking of distributed agile today vs. the past thinking we discussed include:
- We need to focus on maximizing the flow of value to the customer vs. maximizing team velocity
- Learning happens at the rate it can be consumed by the team, the organization and the customer
- Scrum does “Optimize the Team”
- But not necessarily the business
- Lean, for example, teaches us to try to optimize the whole (or as wide as possible)
- There are important activities to get done between the team and supplier to ensure that we are not just focused on velocity, burn-down, functions points etc… but on those things that will mature the team and deliver more value such as:
- Get to initial prioritization faster
- Improve prioritization
- Pull Requirements from Dynamic Priority List
- Reduce size of requirements
- Get to the point of writing code quickly
- Actively manage Work-In-Progress
- Enable Faster Feedback
- Enable smooth sustainable flow of work
- We need to develop “our way of working” vs. just “doing Agile”
- Taking what works best from the latest thinking, which means that distributed teams need to consider differing practices and principles and not get hung up on just Scrum or their flavor of it.
- A mindset of challenging traditional thinking that focuses on building a culture amongst the various teams and not just focused on delivering stories and function points.
- Outcome, outcome, outcome – working software is not a measure of success if it doesn’t meet the needs and value of the business and/or it’s end-users
In a previous post I discussed the must-haves for agile contracts and this lends itself to the discussion on how we shape a distributed agile strategy with our suppliers.
Some of the main highlights would include:
- A more compelling commercial model
- Ongoing dialogue about risk and reward, which has led to contracts swinging from Time & Materials to Fixed Price and back again.
- This approach can lead to sub-optimal relationships and neither party delivering the outcome desired.
- Transparency and Trust
- Mutual needs that are not articulated well upfront and then help drive the plan put relationships at risk.
- Empirical evidence shows that traditional outsourcing contracts are not fully leveraged or achieve their intended outcomes.
- Balancing innovation with the need to deliver
- Customers are looking for ideas and innovations for increased performance.
- The lack of understanding of how the shared delivery methods are going to work together in practice often results in the innovations being diminished, and the value of the relationship being reduced.
- Mutual financial reward
- Suppliers want to be paid for great performance; customers don’t want to pay for poor performance.
Even though the principles in both past and present thinking make complete sense and apply even today to our situations, we need to recognize that many organizations that are a bit disillusioned with distributed agile, or even just agile efforts, are there because the emphasis has at times slipped more on the side of measuring the success of agile vs. “how much my business has improved” by introducing agile into the equation.