Auto racing is a fascinating sport dedicated to the pursuit of speed.
If you’ve ever watch a NASCAR or Indycar event on TV you get a small taste of the immense speed of these purebred race cars.
One of the fastest oval circuits for the Indycar racing series is the 1.5 mile Texas Motor Speedway where the 2016 average speed was 191 miles per hour for a 600-mile race.
A typical car at 70 miles per hour completes 1.5 miles in 77 seconds.
An Indycar at 190 miles per hour completes 1.5 miles in 28 seconds.
Thus the Indycar travels 2.75 times faster than a car at highway speed.
If the race is 600 miles, the average car completes only 218 miles while the Indycar completes all 600 miles.
What is the speed of your software delivery to your customers?
Racing speed or highway speed?
Racing speed produces value faster
As an agile leader, you are a professional and you desire to serve customers and deliver value just like an IndyCar teams desires to win races.
Faster value equals more wins for the customer and hence more wins for you and your company.
When you are transforming an organization, one of the most powerful steps you can take is institute consistent 2 week deployment cycles. In some organizations, 3 weeks works best. Scrum originally suggested 4 weeks. Through experimentation you can see what is best. One week cycles for teams new to agile can be exhausting. Similar to jumping into a Crossfit advance class from a sedentary lifestyle; the amount of fitness required is high and burn out is likely.
A chaotic environment typical operates by delivery the most urgent things and seldom executing the most strategic thing. A 2 week cycle will force some of the strategic things to be completed and also include some of the urgent things. When moving an organization from chaos to agile delivery, a shorter cycle time is better because there is an expectation in a chaotic environment that customers will get valuable deliveries quickly.
If you face a Waterfall cycle, the long-term cycle is probably even harder to break down than the chaotic cycle. With the chaos, the team usually knows what is minimal and can leverage that knowledge to deliver minimal working products in a two-week cycle.
Waterfall minded teams are challenged by a 2, 3 or even 4-week iteration cycle because they tend to focus on a bigger deliverable and in order to create that bigger thing they include all the complexity and infrastructure for a mature product.
The agile leader needs to enforce delivery of working software at the sprint iterations and this will require a significant effort in helping the team break down the deliverables into small chunks.
If you are a scrum master in this situation and you don’t have technical background to help the team creatively break down the deliverables into smaller working chunks, you will likely need to do your homework and to get more technical (e.g. take an online class on the topic) or look to a technical agile-minded colleague who can brainstorm on how to incrementally deliver the system.
I find that some team members are better at this than others, but the team will need to learn how to think differently so when they are asked to break down the system into chucks they can say, “Yes we can do that,” instead of “That can’t be done.”
At Speed you find problems quickly
Having watching many Indycar races I’ve identified a few root causes of crashes.
1. Driver’s colliding with one another
2. Driver mistakes (e.g. Driver going into a corner too fast and slides into the wall)
3. Equipment failure under stress
I want to explore the third failure category of equipment failure as an analogy for software development teams.
In racing, drivers are pushing their cars to the absolute limit. When something breaks in a high-speed corner such as a suspension linkage or tire puncture occurs the result is an abrupt crash into the nearest wall.
These kinds of failures do not occur under normal driving, but only under the stress of a race pace.
As an agile leader, you can begin to see more problems when the team is pushed to faster pace in their deliverables.
It is recommended to do iterations before you think the team is ready. Waiting won’t help you find the problems. Executing will be a great magnifying glass to see the issues.
Finding team process issues
Speed will magnify the flaws in your team’s development process. You might see the following issues when you start.
- Too many stories left unfinished
- Bugs in delivered product
- Slower than expected team velocity
Turning failure into learning
As an agile leader, you must be willing to accept and praise failures as learning opportunities. If you demand perfection from a team from day one, you might create the wrong type of environment where risk taking and experimentation is considered good only if success is achieved.
This means that people will continue to be cautious and only attempt risky things if they think the chance of success is high and that’s not agility that’s poisonous. That pattern of behavior is going to achieve much less innovation.
To prevent your team from feeling like a failure is a bad thing, twist your brain and accept failure points as positive and state that out loud to your team. Explain the details of how the current failure is a learning lesson and verbalize the change that might be necessary to avoid the same mistake in the future.
Here are a couple examples that recently happened at my office.
Finding a flaw in a design choice early
A particular feature was requested and the developer found an open source tool. After one sprint it was looking promising for the first demonstration. After the second sprint, the flow of the application found a gaping hole in the open source tool.
On this project, as the agile leader, I have been insisting on early integration. Finding out the open source solution’s weakness after two sprints was painful (because we spend 4 weeks total on this path) but fruitful in that we understood we needed something different after 4 weeks instead of 4 months.
Finding a mismatch in expectations early
During a recent daily stand-up meeting, I was surprised by a comment from the Product Owner when she said in frustration, “This isn’t the solution I was looking for.” My ears perked up and I immediately said, “Great. That’s the kind of feedback we are looking for so we can stay on the right path.” This resulted in a discussion and finally updates to the product backlog to better represent her desires.
Good racing is controlled racing
At the track, it’s not just speed that matters, it’s mastery of the speed. Winning races or even finishing races requires substantial expertise in handling the car.
So it is with software.
Chaos and speed result in a snowball of complexity and fragility.
As an agile leader you strive for controlled speed by insuring the team achieves the following:
1. Consistent quality (e.g. bug free) deliveries
2. Integrity of the code and the architecture
3. Clarity on the customer wishes.
With these controls in place, you can achieve race speed and create wins for your customers.
What is the biggest struggle you see in creating a consistent and speedy delivery for your teams?
Please leave a comment or send an email using the contact tab.