How can a CEO make software development teams deliver more features, faster?

More Features, Faster.

I recently provided some free advice on Linkedin about software development when Scrum Framework is implemented but there is lacking of Agile Leadership. A manager had recently implemented Scrum to improve their development process.

While things are better, the CEO, who doesn’t really care about what methods they use, was not satisfied. He wants more features, faster. In this organization they have a lot of legacy code, so implementing new features is slowed by the complexity of the code base.

The CEO wants a solution that will speed up development. The CEO has proposed taking the best developers from every team and putting them on one team where they will create designs and prototypes of the new features that will be implemented by the teams.

The CEO thinks this approach will speed things up. If we assume the teams in place today are competent, the CEO’s proposed approach could really damage the delivery organization’s effectiveness, morale and really slow things down. I hear this kind of thing regularly, so here is how I think about this problem.

Update: I received feedback from a reader that I should explain why the CEO’s proposal will not work. I skipped this explanation because it will take more time and take away from the point of the article. The situation is similar to a person who doesn’t understand cars trying to fix one. They can spend lots of money replacing car parts and never fix the problem.

Here is my analysis of the risks of the CEO’s proposal. Feel free to skip this specific analysis if you want focus on the solution

In this specific case the solution proposed by the CEO is to take the best developers from the current teams to create a new “super” team. The “super” team’s mandate is to create designs and prototypes for the other teams to implement. So the “super” team won’t actually deliver new features customers can use. Every design decision the “super” team makes now needs to be conveyed to the other teams. This “super team” idea increases communication overhead, slows delivery of new features, takes the most productive developers and stops them from delivering features. The “super team” also breaks the currently functioning teams by removing their best developers, making the teams less productive. The intellectual capacity of the team members is wasted because now they only follow the “super” team’s orders (designs, prototypes, etc). This reduced autonomy reduces intellectual capacity of the organization and decreases morale. The staff on the “super team” are also likely to be frustrated, since they are no longer delivering valuable software features, and the work they enjoy the most will be done by others. The people on the “super team” have little experience working together so they will be slow as they figure out how to work together and become a team. The “super team” will spend most of their time communicating instead of coding. The “super team” will likely suffer from departures as the “best” developers, increasingly frustrated with the lack of programming and increased communication overhead look for other jobs. The CEO thinks his proposal will create a team of heroes that will speed up the process. However the solution actually increases communication overhead, increases length of feedback loops (features working or not), slows down the teams, decreases morale, increases waste and creates frustration. Given the information we have today, that the main problem is a legacy code base that is hard to work with (not staff competency), the “super team” solution does not address the core problem.

The organization has a certain speed at which it can produce new things, and the CEO wants the organization to produce faster. Well, every CEO wants that, so nothing new here. The solution proposed by the CEO will not speed up delivery of features, it will slow down the system. The only way the CEO will get an organization that delivers faster is if he pays very close attention to HOW the company builds products, specifically how work flows starting with a new feature request to completed features in production. One can’t fix a system without first understanding how the system works. By paying attention to how work is done, the CEO and every manager can then lead the organization by asking for regular improvements in the process. There are many thinking tools from Lean, the Theory of Constraints, etc. that can help management and teams find problems and solutions.

Getting features out faster is usually the second thing to worry about. Most software that is built is never used. This has been shown in study after study for more than a decade. The only way the CEO will get more value delivered from the organization is to pay close attention to what is being built and ensuring that only the most valuable and important things are being built. This means really understanding what a customer needs AND what they actually use (vs what they think they want). Lean startup provides lots of practical advice to solve this problem of building the right thing.

Since the biggest fastest improvement is achieved by simply not building crap your customers will rarely or never use, I recommend the CEO and the management team together:

1. Change what you are working on to maximize value

• Learn: Watch Agile Product Ownership in a nutshell

• Read The Lean Startup by Eric Ries (they will enjoy it, written by a tech executive)
• Take a 2 day Certified Scrum Product Owner course.
• Act: Remove as many features as possible from the product backlog (nice to haves, not needed now, not sure who needs it), and harshly re-prioritize the rest of the features.

For example one management team I worked with used the following prioritization scheme:

1. We’ll go out of business if we don’t have [Feature]
2. It will cost us lots of money but we won’t go out of business if we don’t have [Feature]
3. Everything elseWith this re-prioritization the management team discovered that they could get all the 1 and 50% of the 2 priority features done by the deadline. These priorities cut the delivery time by 50% and ensured that the fraud detection system for a major U.S. bank would not hold up a very large re-platforming program. The rest of the 2 priority features were mitigated with manual processes and delivered after the re-platforming.

• Apply and Improve: Implement Lean Startup thinking to product feature discovery, prioritization and product feature validation.

2. Change how you organize work to maximize learning, collaboration, and effectiveness of the organization

Managers and leaders:

• Learn: Read and study about Lean, Theory of Constraints (TOC), Scrum Velocity
• Take a 2 day Lean and Agile for Managers course on these topics from Robin Dymond Contact Us.
• Apply: Value stream mapping and Lean tools, TOC.
  Hire a Lean Agile consultant to help management and the organization transition to Agile, Lean and TOC management principles and practices. Innovel consultants specialize in this area. Contact Us.
• Improve: Measure your starting baseline, including value stream, bottle necks, information silos and velocity. Incrementally improve the value stream, remove bottlenecks, remove silos, and improve flow.

3. Change how you practice design, coding, and testing to improve quality and speed

Teams:

• Learn: Take hands on training in Agile engineering practices and Agile testing.
• Apply: Hire a technical consultant to help teams apply Agile engineering and Agile testing practices in their day to day work. Innovel consultants specialize in this area. Contact Us.
  Allow time for new practices to be learned and mastered.
• Improve: Measure baselines for unit and functional automated test coverage, and code quality. Invest in improving these metrics over time.Teams working with Legacy code and using Agile face specific challenges. Team members and managers should:
  • Learn: Read the PDF Working Effectively With Legacy Code and then read the book Working Effectively with Legacy Code
    Read about “Technical Debt.”
  • Apply: Measure baseline technical debt in your system, long term and short term debt. Develop a strategy for paying down technical debt.
  • Improve: Implement the technical debt strategy together with teams and management and actively manage technical debt.

Metaphor for management: “Does shoving more paper into a printer make it print faster or make things worse?”

Happy New Year!!