Power Models and Method Affinity

a.k.a. why are some people SAFe oriented, others DAD biased, yet others LeSS enthusiasts, and not forgetting the DSDM gang, the Nexus collective…and I’m running out of terms.

I’m sure there are a whole host of reasons, but during my time observing people, and knowing a bit about their past and what they’re like, it has led me to form an interesting (to me anyway) hypothesis. It’s to do with power.

A Brief History of Power

Without digging too far too much into Taylorism or others, there are a handful of basic power models that can theoretically exist in an organisation (heavily simplified for illustrative purposes, as real life is never this “simple”).

  • Power in the hierarchy, the higher up you go, the more power you have
  • Power in the middle management – sometimes disparagingly called the permafrost
  • Power on the edges – people on the ground in front of customers

These can manifest themselves onto a project context in a few ways (note for want of better options, I’m labelling these categories with overloaded terms)

  • Power lies with the “planners” – e.g. project managers, PMO
  • Power lies with the “architects” – EAs, Solution Architects
  • Power lies with the “developers” – developers, testers, BAs

Human nature is such that we flock towards things that are like us. Planners are more likely to favour other planners, and work using systems where the balance of power is in their direction. The same sort of thing is true for the Architects and the Developers.

Methods

And now we get to the Methods part of this blog. I’m going to focus on agile methods, and agile scaling frameworks. And in particular, how these methods and frameworks are perceived, at least initially. That bit is key. Most of this “natural affinity” stuff is emotional in nature, and not fundamentally driven by rational thinking (hint: there’s a lot of religion in this area). As there are lots of them out there, I’ll just pick the three major ones (based entirely on how often clients talk to me about agile at scale, and nothing remotely scientific).

SAFe

The overall guidance is dominated by the navigable map. It has several terms that will be comforting and reassuring to hierarchical type organisations with traditional reporting lines and financial controls – Programme / Portfolio Management, Enterprise Architect, as well as some guidance on mixing waterfall and agile deliveries. This looks to be solidly planted in the middle of the “Planners” camp.

Based on the hypothesis, likely proponents and allies are to be found within PMO, Project Governance,Configuration Managers, hierarchical organisations with a centralised power model, and organisations that perceive themselves to be traditional with a rich history / heritage.

DAD

The first thing that strikes you when you first look at DAD is that it’s rammed to the rafters with choices. It has a risk-value lifecycle (but you can choose others), many options on how to achieve pretty much any delivery related goal that you may have – from big ticket items such as considering the future – how much architectural insight do you need, to very focussed options like the right level of modelling to use. And that’s just part of the “Identify Initial Technical Strategy” goal. This resonates well with those with an architectural bias – architecture is mostly about decision making and communication.

Likely proponents and allies are to be found in technical leadership – Architects, DBAs, and organisations with a strong technical bias.

LeSS

The navigation map for LeSS in contrast to the previous two, looks relatively uncluttered. There are large concepts identified (such as Systems Thinking, Adoption) but these are all located around the periphery of the diagram. Slap bang in the middle is the engine, and those are feature teams. This puts the Developer at the centre of the universe (as it were).

Likely proponents and allies are to be found within teams and individuals using Scrum and XP on a regular / daily basis, and organisations that “have a small company vibe”, which may be startups on a growth spurt, or organisations in a highly fluid environment with significant localised decision making.

The Goldilocks Solution

As the heading suggests, I think the right mix for any given organisation is somewhere in the middle. Power isn’t solely contained within a single area (though granted, in many cases, the vast majority of the power is indeed concentrated that way), and any scaled agile adoption strategy will need to understand and accommodate that to increase the chances of tangible benefits being felt by the organisation.

 

Feedback

As this is just a hypothesis I’ve got, I’d love to hear what you think, whether you’ve observed things that support this theory, disprove it entirely, or somewhere in between.

A culture of learning

It’s no secret that teams that have a “culture of learning” outperform similar teams that don’t care about that sort of thing. The Internet’s full of articles extolling the virtues of such a culture, along countless articles offering suggestions on things to do that would help you develop your learning culture. There’s a lot of good sense out there, but in my experience, it’s not really possible to develop (or introduce) a “learning culture” as a discrete thing. There is no carrot & stick solution that’s resilient to real life.

The best I’ve been able to do is make it possible for my teams to believe that it’s worth learning new things, growing and sharing. Mostly because it’s more fun that way. As a species, we are if nothing else, driven by emotions. Hopefully positive ones.

Learning new things is a risky business. For a start, if it’s something difficult, or requires lots of practice to master, then you’re going to get things wrong. A lot. Making a mistake is often seen “in the corporate world” as a bad thing. With penalties like “poor performance ratings” if you’re an employee, and terminated contracts if you’re self employed. Ironic really, as we tend to learn the most valuable stuff while making mistakes. So another thing that I do to help my teams, is make it OK to make mistakes, to break things. On one project, that was a counter – everyone was allowed 3 epic fails. On another project, it was “as many as we needed to in order to do the right thing by our customers” (we were very user need driven so we had lots of empathy with our users).

On an explicit front, we introduced “Lunch and Learn sessions” – once a week, for 30 minutes. The list of topics was on a (Product) Backlog – well, a whiteboard with a load of post-it notes on it. Anyone could add things to the backlog, and re-order things as they saw fit, with a deadline of the morning of the lunch&learn day. It started off as me giving the talks, which after a couple of months, saw others offering themselves up as speakers for a subject they were keen on. It wasn’t limited to digital development either. One speaker wanted to talk about macro photography. We were able to round up guest speakers from other projects, and they were usually delighted at the chance, and in payment, we would give a talk to their team in exchange.  One session was a live demo – our accessibility specialist brought in a blindfold and some headphones, and we were to try and use the website that we were building, but from the perspective of a blind user. Talk about an eye opener!

On a subtle angle, we used lots of pairing and collaboration techniques to spread the knowledge about, as part of “doing the day job”. We tried to get the default model for solving a complex problem into one where a person finds a teammate with some time and they work it together. So by necessity, we introduced a little slack time to help with this. Irrespective of role, seniority or time on project, we all tried to treat each other as equals (part of our team charter that we signed up to when joining). That made it “OK” for information to flow around, and made it part of being in this team.

If you think all of this sounds like hard work, well you’re spot on. We had to invest heavily into creating the conditions that would make a learning culture more likely to happen, and we had to do it in a way that didn’t completely alienate us from the rest of the world (though there was a rumour that we laughed more than everyone else in the building put together! And despite such frivolity, we were easily the most effective team in the building). We had to sustain the effort too, as we were looking to build a lot of good habits (once an activity becomes a habit, it becomes significantly easier to do as there’s no longer the need for conscious willpower).

 

No can be a great response

Fear. The desire to please. To not look stupid. Bravado. Saying no is hard. It might be confrontational. You might upset them. The world might end. Aargh! Better to say yes and suffer in silence. Martyr yourself.

  • No to a feature request when your team’s already got a hundred.
  • No to a suggestion that clearly doesn’t make sense with everything else you’re doing.
  • No to another task in your in tray that you won’t get to for ages.

Learn to say no. But say it graciously. You’ll build integrity that way. It’s better than leaving your customer hanging, believing that you’ll do something you’re not going to.

 

Hiring Developers

“We need 6 developers to start in 2 weeks!”

“We have to have 2+ years’ experience of everything in the full stack”

“We’ve not got that much development work for the next couple of sprints, so another project can pay for 50% of our developers’ time and get some work done, and we save money”

Any of these sound familiar? If so, you might be trying to have your cake and eat it. “Agile” ways of working move the centre of power into the delivery team, which can be hard to deal with, especially if you’re in a more “traditional position of power”, like a Project Manager or the Head of Department.

One of the lesser understood principle in the agile manifesto is the subject of websites such as http://12thprinciple.org/

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

What does that mean in practice when your teams begin to detect a skills shortage? If you’re in a leadership position, you might be tempted to try and fix this – after all, that’s what you’re supposed to do right? Deal with those pesky blockers. You might need to know what the scale of the problem is, and seeing as you recruit in whole numbers, you might need to translate the size of the problem into a “number of developers”. What sort of skillset should they have? Your team’s trying to do some complex stuff, so you’ll need someone who could do all of it right? Your management structure or your client is complaining that work isn’t going fast enough to meet a key date so you’ve got to increase your capacity somehow?

It’s worth taking a step back to think about just what the team is responsible for. It’s pretty obvious that they’re responsible for doing the actual work. What can sometimes be overlooked, is that they’re also responsible for how they do the work. And that includes who does the work – part of the team’s responsibility is to make sure it has all of the skills needed within the team. If they’re detecting a skills shortage, they’re best placed to try and find the right fit.

As a leader, you’ve got to worry about your organisational recruitment – pay and conditions, legal requirements, that sort of thing. But don’t let the mechanics of recruitment be your only process – make sure you’re recruiting the right person for the team. You’re not looking for a generic skillset, you’re looking for someone to fill the very team specific hole they’ve got. And they know exactly what that hole looks like. I’ve had the most success when I’ve let the teams recruit their team members, and the leaders sort out the paperwork.

And as for the third example at the beginning – my only real advice is to avoid doing that. Teams are entities in their own right and it’s well worth thinking about them as atomic units. Chopping and changing internal team structures is generally only really good for disrupting the work. If your team’s got a little slack time, use it productively – pay off some technical debt (there’s always some). If you’re in the ideal situation, then why not just reward the team with some R&R? They’ve probably earnt it.

Building credibility

There are a lot of approaches to building a good relationship with your client. All the ones I’ve seen boil down into a couple of basic themes:

  • Option A: keep telling them to trust you and believe you. Maybe one day they will
  • Option B: Keep your promises and do stuff for them. Let the evidence do the talking

Most of the projects I’ve seen that end up with a confrontational relationship between supplier and customer have used a variation of Option A. For a long time. Customers get frustrated when they think they’re being lied to. And not doing what you say counts as lying.

One of my recent clients had been burnt badly by the curse of large failing IT projects. Their operational units were disengaged with their IT Department as they’d been let down for the best part of a decade by cancelled projects, cost overruns and major defects. Like many others in that situation, they’ve done what they could to work around their “substandard” technology. You’ve seen this too – businesses running on strange Excel spreadsheets with even stranger macros.

What we did could be considered by “old fashioned IT Departments” to be tantamount to treason – we integrated with the business. So much so that we requested that at least one representative of the business be part of our delivery team and be part of doing the work. And we wanted regular access to the operational unit so we could run workshops, run demos etc. Sadly, they had to draw the line at the delivery team being located on the operational unit’s floor (no desk space).

And we did stuff. Iterative development models have an end-of-sprint demo event, so we demoed what we’d built to the business. They’d give us feedback, and two weeks later, they saw the effects. They saw us listening to them and doing what they asked immediately. Their voices mattered. We never told them to believe us or to trust us. We never had to. We just demonstrated that we were trustworthy and they took the initiative. Part of being trustworthy was saying “no” (with a good reason) when we needed to.

And when we launched the first version of the system, trust was even more important. Because now their customers (the public) would also see the system, what we’d built had an effect on how the customer perceived the business. So, when demo after demo we showed them the changes we’d been making because of what their customers found difficult or confusing, the goodwill that created was simply huge. We’d shown the business that not only did we listen to them, we listened to the people they thought were important – their customers.

That’s a lot of credibility.