Over time, the real competitive edge is an organization’s ability to improve continuously. It’s like paddling upstream on a river. If you stop paddling (making small incremental improvements), you’ll soon start drifting backwards towards the waterfall.
Agile has shown us the importance of regular retrospectives and continuous improvement at the team level, but improvements need to happen throughout the entire organization. Just like there is an organized way to improve in an agile team, there should be an organized way to improve at every level.
Let’s take a look at three steps to expand the improvement culture beyond the grassroots team level:
- Be strategic about your capabilities
- Install escalation paths
- The improvement mindset is for everyone
Following these steps will help you build the (organizational) system that yields the desired business results.
Be strategic about your capabilities.
The steering wheel & engine
Strategic business goals set a direction for a company. We describe where you want to be in the future as a business. To get there, we carve out a strategy that guides you along the way.
Let’s compare this to travelling from Stockholm to Barcelona. Barcelona is the goal, but we won’t get there in one go, so we roughly plot a route (a strategy) through several countries and expect to reach the goal in five days.
What would stop us from reaching our goal in time? If we drive a well-serviced car, there will be no problem getting there. But if we drive a vehicle that hasn’t been serviced in the past five years and hasn’t been properly cared for, we might not get far before we run into trouble and run out of time.
As a company, we can set the best strategic goals and have the best strategy to get there (turn the steering wheel in the right direction), but if we lack the capability (the well-serviced engine) to get there, that doesn’t matter.
When setting strategic goals for an organization, they typically fall into two categories: business goals and capability goals, which ensure you can achieve the business you desire. The strategic insight is this: A capable company can competitively reach almost any business goal.
So, what are these capability goals? It depends on what your business goals are. What capability does your company need to have to reach your strategic business goals in time to be successful? Often, the types of goals have to do with.
- Lead time (time to value)
- Quality
- Agility and Flexibility (ability to deal with variation)
- Competence and skills (outsmart the competition)
- …
Set the standard
Having self-organized teams that execute all the essential work in a company doesn’t mean they do whatever they want. There has to be a direction (goals and strategy) that tells us where we’re heading and constraints (rules) that describe what’s expected behavior.
Compare to a soccer team: They know where the goal is, who the opponents are, and what is meant by winning. They also see the playing field and understand the game’s rules. Knowing all that, they can play a fair game in a self-organized way, where the team handles defense and attack on their own in real time.
For agile teams in a company, it means we have to define a bar that they must stay above. Standardization is a good way to do this. Define what is expected from any team in the organization. They are allowed (and even encouraged) to exceed these expectations, but they should at least do some basic things. Here are a few examples:
- Every team should have a mindset of continuous improvement and have at least one improvement in flight at any time. Improvement isn’t optional, it’s expected.
- Every team should benchmark against itself using the metrics described in my previous article “Part 4: Don’t scale with underperforming teams”.
- Every team should have regular retrospectives or some other well-defined way of improving their motivation, quality, and speed.
- Every team should know and be able to name their stakeholders (you’ll be surprised…)
- Every individual should have a learning plan to deepen and broaden their skill set.
- Every team should have 1-3 objectives in focus and prioritize their work accordingly.
- The company’s objectives should be supported by the team’s objectives.
- …
Rules like this not only set the bar but also provide transparency, ensuring that people have the information and tools they need to make wise decisions at every level.
I often find that organizations talk about having things like this, but they don’t enforce them as company rules. In my opinion, it’s a mistake to be passive about this. Although managers should remove themselves from the playing field to the sidelines (let the teams self-organize), they should not move up to the spectator seats. We want managers to coach their teams actively, and to do that, you have to be close without being in the way.
Operational excellence
Driving business strategy and increasing the organization’s capabilities can be spearheaded by the C-level executive team, but some companies establish a dedicated team focused on operational excellence. That would be similar to what Jeff Sutherland calls an Executive Action Team in his Scrum@Scale framework.
The operational excellence team is the top level of company improvement and capability building, serving as the final escalation point for issues that cannot be addressed by teams at lower levels (see below about escalation paths).
Sometimes, a group like this is called a transformation team and is created when a company decides to adopt new ways of working in a focused approach, such as transitioning to Agile, SAFe, the Product Operating Model, Scrum@Scale, or a similar approach. Since continuous improvement never ends, it’s always my advice to make this constellation permanent and continue serving the organization even after the transformed state has become the new normal.
Most members in an operational excellence team also have other jobs within the organization. It’s beneficial to have change agents from multiple corners and levels within the company. Not the least a strong representative from the C-level team.
The operational excellence team sets capability goals and objectives at the company level, as well as funds, launches, and follows up on improvement initiatives executed in other parts of the organization. They serve more like product owners or stakeholders than an implementation team.
Don’t become a victim of your own success.
Startups and scaleups are usually less strategic than more mature companies. They are focused on generating cash flow and growing their business in any way possible.
This is understandable, but if you don’t think about “servicing your engine” and things take off, you might end up with problems caused by demand. Thanks to your success, you have more users and more feature requests, and you need more capacity to keep up. This may lead to:
- Poor system performance. Your system was designed with dated specifications and can’t handle exponential growth.
- Rapidly rising technical debt. It’s too complicated to add new features in a proper way (not just patching them on), and re-architecting is not on the table.
- Productivity drops despite hiring more people. When you become four times bigger in a short time, only 25% of the staff have been there from the beginning and understand the business and the system internals.
- Onboarding takes an unnecessarily long time, as there is little documentation, the old team members are busy, and the system has become a patchwork of solutions.
- … and so on
With some foresight, this can be avoided. If your business projections (the ones you use when attracting investors) indicate a 10x increase in usage, global presence, and a roadmap with some fantastic features that need to be built you should make sure you have a well serviced and well tuned engine (organization, architecture, skilled staff and processes) to get there.
Set capability goals that align with your business ambitions, so you don’t become a victim of your own success.
Install escalation paths
We want to make being a fast organization a permanent state. This means that the leadership has to build an environment where people can perform and have a system for identifying things that suck and fixing them when they can’t be addressed on the team level.
Here is where escalation paths come in. If a team’s worst problem is something they cannot resolve on their own because it requires managerial powers, affects a larger part of the organization, or has its cause higher up in the decision-making hierarchy, there must be a way for the team to escalate this issue and get help.
In many organizations, the “next level up” is typically the closest line manager, but this may vary. Some companies have a team of discipline managers (for programmers, testers, and product managers, respectively) overseeing a cross-functional team.
It’s the duty of the closest management level to help the team. Any manager who doesn’t help their team with its worst problem is not doing their job. However, it’s possible that this manager also lacks the power and influence to resolve the issue, so there must be a way for them to escalate one more level. And so on…
The responsibility ends with the operational excellence team. As mentioned above, they serve as the final point of escalation for issues that cannot be addressed at lower levels.
Transparency is key. The available escalation path should be visible and transparently show what issues each level is currently working on to resolve.
A colleague of mine implemented this with a client a few years ago: Each manager for a group of teams had a small whiteboard outside their office, with space for up to four sticky notes. On each sticky note, a problem that the manager was helping a team to resolve was described. Any team could put a sticky note on the board, but the total number of issues could never exceed four. If there was no more room, the teams could negotiate with each other and replace one note, relieving the manager from that work. When an issue was resolved, it was up to the team to remove the item from the board, not the manager.
This experiment turned out to be successful. Due to the WIP limit of four, managers were not overloaded with issues to fix for the teams, and the teams had to be careful not to use up space with unimportant items. Between the managers, there was a bit of prestige to keep their board as empty as possible.
The improvement mindset is for everyone.
When was the last time your executive team had a retrospective? Does it happen every two weeks, like in most development teams?
The habit of regular retrospectives and continuous improvement should apply to all teams in an organization, not just “worker teams” such as development, operations, and support teams.
Actually, it’s not uncommon for some of the worst teams in an organization to be leadership teams with low psychological safety, poorer-than-average collaboration, and only sporadic deliberate learning and self-improvement. Learn from the agile teams in your development organization. They can show you how to do it!
Don’t just focus on improving others – take a look in the mirror as well.
Summary
Continuous improvement concerns the whole organization at every level, not just contributing teams.
Like in agile teams, company-wide self-improvement needs to be structured and deliberate. I have suggested some ways of achieving that.
When setting strategic business goals (turning the steering wheel), ensure the organization has the matching capabilities to get there (a well-tuned engine and a mindset of constantly improving it).
This is the fourth part of a blog series about speeding up your organization. Previously published parts are: