Responsibility inversion

Responsibility inversion is an extremely common management anti-pattern, present in many organisations. It occurs when a person in a more senior role (in terms of hierarchy or experience) does not delegate sufficient responsibility to those more junior than themselves, even though they possess the relevant skills, ability or experience.

With the following diagram in mind, consider a typical career progression progression path, with a manager and their report(s) as an example:

Responsibility inversion principle

In the Venn diagrams above, the upper circles represent the more senior role, their skills and experience and the lower circles represent the more junior role. The intersections represent the overlap in skills and experience.

The Responsibility Inversion Principle asserts that if you prevent someone from using their abilities they will begin to lose them (shown on the left). Whereas, when they are allowed to exercise their ability, under the guidance of someone senior, they’ll actually grow their ability.

One common example of an inverted responsibility situation you may encounter is the much lambasted “ivory tower architect“. Instead of focusing on higher-level concerns outside the logical scope of the senior developer role, they’ll spend time dictating all but the lowest-level aspects of their skill set. They do not trust or empower developers to make use of their experience – removing the opportunity for them to create or influence solutions, designs or to make any related decisions about the software they will be expected to deliver – instead they’ll be spoon fed the results of the architect’s own (isolated) activity.

If you’ve employed talented people, this inversion will be a massive source of frustration which will slowly erode their skills (through lack of use), quality of work and output if left unchecked. The more astute will leave to pursue opportunities elsewhere long before it comes to that…

Talent retention aside (although you’ll be aware how big an issue that can be), the inverted approach doesn’t scale! Taking on as much as possible and delegating as little as possible creates a huge bottleneck that isn’t always very obvious from outside the team. Time that should be invested in important areas is rushed to continue to feed work to their reports (compounding the frustration of those who could have done a better job, given the chance).

There are many potential reasons for this situation. It can emerge from a perceived lack of skills in the more junior employees – or from a lack of trust. It can also come from a desire of the senior person to (continue to) be seen as valuable or irreplaceable to the business – or simply as a result of unconscious actions (in ignorance of what they’re doing). Whatever the root cause, the result can be toxic in the long term.

Regardless of the role within an organisation, you will usually find that there is a substantial amount of overlap in the overall skills and experience required to carry out the related day-to-day responsibilities, yet many organisational structures place people in silos – as if the entirety of those skill sets are mutually exclusive. Whilst this loses some economy of scale in larger structures, some delineation is required for effective coordination of activity – “somebody’s gotta be the ensign“.

Some career paths have evolved to avoid this pitfall fairly naturally – such as the route from junior to lead software developer. One might expect to begin their career as a support developer then progress in to a senior developer role and (eventually) beyond – leading teams or perhaps moving into architecture. In a healthy organisation, there’s usually an implicit requirement in their senior development roles to support and mentor more junior developers. They’ll be coached and assigned progressively larger and more difficult pieces of work. All the work they produce is reviewed by the senior, who will then give appropriate and constructive feedback to the junior – demonstrating areas that they can improve. Over time they will grow to fill the shoes of their mentor.

It’s important to note that using the delegation approach in no way diminishes the more senior role. The skills you learn by communicating your experience, explaining complex concepts and being able to divide and distribute large undertakings of work help set you up for your next challenge.

So how does this relate to Agile software development or scaled Agile? An Agile self-governing team not only promotes the vertical progression described above, but can also provide a great way for people to expand their skills horizontally – from the additional experience gained in embedded team roles, rather than being limited by a traditional silo position. You’ll find that people naturally gravitate to areas where they have the aptitude and interest. When people are given the opportunity to grow like this, you may be pleasantly surprised how much your team starts to achieve.

Agile team communication

Encouraging good communication within a team is one of Agile’s key areas of success. From daily stand-ups to pair programming, refinement and retrospective meetings, working in an open and collaborative way is a core tenet of Agile, whichever framework or methodology you subscribe to.

No hierarchy?

Many Agile approaches attempt to instigate flat organisational structures, where everyone on a team is (theoretically) on equal terms. You’ll also encounter evangelists using somewhat counter-productive phrases, such as “no more managers” or “remove all hierarchy” or similar calls promoting the abolition of traditional reporting structures.

In reality, you’ll find that the world (and by extension, all our work) is inherently hierarchical. Even a typical Scrum team has an implicit hierarchy in the form of the Product Owner. Sure, they don’t manage the team in the traditional sense – and in more mature Agile teams, they won’t be dictating what is included in each sprint – but they do have some authority. They get to choose this feature over that, set work priorities, time-box development activity and more – they’re just not micro-managing the technical development.

Scrum of Scrums

When there is more than one team, one approach to coordinate their efforts is the Scrum of Scrums:

With this approach, each Scrum team proceeds as normal, but each team identifies one person who attends the Scrum of Scrums meeting to coordinate the work of multiple Scrum teams. These meetings are analogous to the daily Scrum meeting, but do not necessarily happen every day.

The team member from each team attending the Scrum of Scrums is generally known as the team’s “ambassador”. Interestingly, the role that attends this meeting is not fixed (it could be the Scrum Master, Product Owner or one of the technical contributors). This leaves three important issues:

1. What is the agenda and knowledge of the attendee – business and technical roles often have conflicting priorities (and an Agile coach / Scrum Master may not understand either).
2. When there is inevitably some conflict between teams (priority, dependencies, solution architecture etc.), who is ultimately responsible for making those decisions?
3. Whose responsibility is it to maintain an overall product direction for the teams? What controls are in place to ensure the Scrum of Scrums team is able to reach a (consistent) consensus?

Network approach to communication

In Setchu, instead of using the Scrum of Scrums technique, it uses a predefined two-tier hierarchy. Multiple Agile feature teams are accountable to a single control team (made up of a Product Owner and Product Architect on equal standing):

Network based communication.

Teams (and any member thereof) are strongly encouraged to communicate informally and often, in a network manner, between each other to resolve minor issues and dependencies. There’s no hierarchy between the feature teams, but they are expected to try to reach decisions both sides are comfortable with, for most day-to-day interactions. Whenever that’s not possible or when a discussion highlights a wider concern, the issue is bubbled up to their (mutual) control team:

The control team is able to offer guidance and make decisions that are in the best interests of the overall product. As this team is a split between business and technical concerns, it is able to provide balanced solutions (and assess the wider impact) to their feature teams.

In this model, each team has clear ownership of its responsibility (and authority). When there is any ambiguity, there is a well-defined, central authority present to resolve the conflict – who are also ultimately accountable for the success of the product.

Managing technical debt

One common question I hear from teams new to Agile is “How do you manage technical debt?”. Agile is often blamed for producing more technical debt than more traditional approaches – whether or not that’s true, everyone should have a mechanism for tackling it.

What is technical debt?

For anyone unfamiliar with the term, very basically, technical debt is any underlying element of your software that you should rework at some point in the future. Usually as a result of a previous decision or (in)activity that will impact the long-term value of your product, if left unaddressed.

It differs from a change initiated by the business in that it will usually be something either imperceptible to anyone non-technical and / or not involved in the technical implementation of the product (or certainly not obvious).

Ward Cunningham, credited with coining the term, describes this concept in the following way:

“Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”

He refers to object-oriented programming, but you’ll appreciate the concept applies universally, regardless of paradigm.

Unplanned technical debt

Unplanned technical debt is usually the consequence of external change, time pressures or a lack of understanding.

For example, maybe you produced a service that made heavy use of a rate-limited external API, on the assumption that your expected traffic volumes would never approach close to that value. Then, your product is a runaway success and you end up with more traffic than the rate limit allows, degrading performance.

Another example could be that your project made use of a UI library to produce your website, but now there are newer browser versions that the library does not handle, breaking layout and functionality in modern browsers.

You may have written an inefficient search algorithm, as you had to produce something very quickly at the time – but with further optimisation you could save significant server resources, needed for other processes going forwards.

From personal experience, I’ve had situations where I’ve discovered a much more elegant solution to a problem after the fact (where refactoring would improve pace of change and customer experience), towards the end of a project.

Planned technical debt

Sometimes you just have to accept that being able to produce something fast is occasionally better than (pro-actively) spending additional time on quality. For example, it’s quite valid to attempt to prove a concept in the quickest way possible, usually to answer an unknown factor (“will this work?”), over longer-term concerns.

This could result in things like a conscious decision not to include logging or perhaps you chose to skip adding any build automation, knowing that they would both be useful longer term. The key points with this approach is that the team has agreed the priorities, potential impact and any mitigation up front – the consequences of the situation are understood. As long as you address the issue later (or make a conscious decision to live with the issue), based on the business value balance, that’s fine.

When planned technical debt becomes particularly unhealthy, is when it emerges from a pressured, one-sided source – instead of as a natural result of collaborative effort. In Agile teams, this is usually the result of a dictatorial (bad) Product Owner – or someone else able to pressure the team into focusing on non-technical priorities, over the team’s overall agreed priorities. You could argue this is actually unplanned debt – but that divorces the responsibility from the stakeholders, who ultimately need to acknowledge that they have chosen this path.

The danger here is that the potential consequences of this type of technical debt are not understood. That’s a risky place to be – unbounded problems have a tendency to spread quickly – akin to spending on a credit card with no limit (and no one ever checking the balance). If your technical debt exceeds the value of the product, you’ve failed.

Balancing value

Successful software projects eventually need to achieve a level of balance between business functionality and technical architecture.

Too much focus on either side is not good. Businesses tend to focus on tactile features over practicality, while development teams want to produce academically elegant solutions that no one may actually want (or simply spend more time on it than the business value justifies).

Regardless on the cause of the debt, the way you tackle technical debt is largely the same. The team needs to prioritise effort together.

If your backlog refinement meetings are genuinely collaborative then you’d ideally have discussed and agreed your prioritisation of work to include a balance of business and technical needs – minimising debt in the first place.

While that may be the ideal, striking that balance isn’t always very successful, for a variety of reasons. Additionally, unplanned technical debt is a constant unseen threat – and it can build up at any time, even with the best of intentions.

Newly discovered technical debt should be bubbled-up (flagged) so that it can be addressed by the team. This means adding a story to the backlog with a description of the problem and optionally including a proposal to resolve it. When your backlog refinement meeting (grooming) occurs, you should have a mechanism to trigger triage of new stories, prompting a discussion about the issue. From there, your technical debt becomes like any other story being groomed:

• Flesh out the requirement – is it a problem?
• Break down any large chunks into smaller, manageable activities.
• Agree the acceptance criteria for it to be considered resolved (done).
• Prioritise based on the value to the product / feature.
• Add the stories to the appropriate sprint backlog.
• Review your balance of priorities again at the next planning session.

That’s it – when you become aware of technical debt, flag it by creating a story to represent it, let the team decide when and how it needs to be tackled – then deliver on your commitment.

Common problems adopting Agile

Agile is not a silver bullet – despite what many claim. Agile doesn’t magically improve delivery, but it can bring significant improvements if approached in the right way. Let’s take a look at how not to introduce Agile into your organisation.

Beware of Waterfall in Agile clothing

I’ve found on many occasions that when a business issues a diktat that they will now implement Agile, it can be difficult for them to make the conceptual shift. Sometimes they’ll (unintentionally) keep their existing structure and processes and simply go through a renaming exercise instead. However, as we well know:

• The Scrum Master is not a project manager
• The Scrum Team are not all developers
• The Product Owner should not be a business analyst

So, if you have simply filled new Agile roles with the nearest equivalent traditional job title, there’s a strong chance you haven’t changed much about the way you work – instead you have simply renamed your current methodology to sound more “Agile”.

You’ll also see projects become “epics”, requirements may become “stories”, meetings are suddenly “stand-ups” and planning is now called “grooming” – but has any of this your improved your output?

Evangelists cause issues

Once a decision has been made to become “Agile”, an early step embarked upon for many businesses will be to recruit an Agile specialist. There are a two important issues with this approach:

First, these specialists are often aligned to one specific methodology (we’ll discuss that later). At worst, they will apply it dogmatically, without the pragmatism required to effect change in some larger or more traditional organisations.

Second, the criteria for recruiting these specialists is often that they have a relevant Agile certification, as that is the only way they have of assessing a candidate’s Agile credentials. For any methodology to be successful, sufficient practical experience is required. This doesn’t come from books or (one-day) courses.

Don’t default to Scrum

Scrum is Agile, but Agile is not Scrum. Scrum isn’t the only Agile methodology in town (even as I often default to using Scrum terminology…), yet it’s often adopted without any consideration about what it actually provides and what limitations it may have.

Scrum may be the best-fit for your needs, but you should always perform some analysis based on the specific situation you’ll be working in. Furthermore, don’t fall into the environment / scalability trap. All too often, I’ve seen Scrum trialled isolation, with a small independent team, then it gets rolled out across a much larger organisation with several teams (and their complex dependencies) thinking that it will just work. It very often doesn’t.

Each software methodology has its pros and cons – what looks good in theory may not be as successful in the real world. Try some out.

Narrow scope limits change

The most common mistake when trying to become more Agile, is that changed practices are only applied to the technical phases (usually just build). Requirements are still gathered up front, then there is a design phase. After the now “Agile” build phase, a test and release phase follows and so on. This is a red flag that you’re actually using a sequential methodology (like Waterfall…) instead of an agile methodology.

This is a problem because you’re going to be severely limiting the potential benefits that can be realised by adopting a more Agile approach by constraining the scope of change in this way. As many businesses eventually discover, the build phase is often the least of their problems when it comes to successful project management.

Sometimes other phases are actually included in the “Agile” scope, but they will occur in an isolation fashion instead of collaboratively. The scope of a Sprint is dictated by the business and Scrum Master (in private), rather than agreed by the team.

Divorced responsibility

Another pseudo Agile anti-pattern is “pushing (problems) over the fence”. This will typically take the form of the business expecting the Agile team to deliver requirements that haven’t been articulated or even formed yet – and then not being involved in the activities designed to find them out.

Issuing requirements akin to “whatever it does now” also demonstrates a distinct lack of stakeholder engagement. The business needs to take responsibility for ensuring their team has a complete understanding of their expectations if that is what they hope to deliver. Collaboration is one of the most important aspects of Agile and can be the most difficult culture to change.