Optimize for People, Not Processes with Project Management

In my experience, most companies start to get serious about project management at a certain point in their growth, and that’s usually when they observe a slowdown in output — either because of team size, code size, size of the user base, or some other challenge. Often this means reaching for an established methodology or framework to keep the work flowing, and I don’t think it’s too controversial to say all of these methodologies create their own challenges when they’re either poorly applied, or too narrowly focused on certain metrics.

Sadly, there’s no one perfect solution for everybody, and I’m sure everyone reading this who works alongside engineers will not be surprised to see yet another software engineer mentioning trade-offs, and uttering the famous maxim: it depends.

My goal is for you to find ways to blend your teams with the right process, in the right way. So I’ll cover three of the main methodologies in the software industry — Agile, Kanban, and DevOps, all of which have been hugely successful, and still provide a great deal of benefit to a great many teams — and give you some of the tensions I’ve encountered along the way. Consider me a lighthouse looking to ward your team’s potential away from the devastating rocks of inefficient process. And, of course, 8th Light is a fine software consultancy that would love to talk about these problems with you.

Agile

The most accurate description of agile I’ve encountered is trauma. The movement was conceived in 2001 by a group of developers as a response to inefficient company management, but I’m going to step back and define my use of agile to mean the various and copious amounts of approaches, instances, and methods that use the phrase “agile” to describe themselves. I’m doing this because the whole agile world is basically a difficult and confusing soup of buzzwords and flimsy certifications. It has — if not in spirit or technicalities, but in reality — been somewhat plundered by the very bad management that it was designed to overcome.

Agile is a mindset. You do not implement Agile, you become it. But what is “it”? If you ask me, it’s comprised of three primary factors:

• Continuous Delivery: A total, all-encompassing drive to regularly and incrementally deliver working software to customers.
• Small, Accountable Teams: A push for teams to organize into smaller, self-organizing teams who work in small cycles.
• Eliminating Waste: A neverending focus on reducing top--down hierarchies, needless management, and chafing bureaucracy.

Agile the mindset, however, often is brought to life in businesses, with varying levels of success, by popular agile frameworks. We’ll cover three: Scrum, Extreme Programming, and SAFe.

Scrum

Scrum is the most synonymous implementation of the agile methodology — if you’ve “done” agile in the workplace then you’ve most likely seen scrum. Scrum teams are made up of 10 or fewer people, and are comprised of a:

• Product owner, who is accountable for the value of the work delivered by the scrum team.
• ScrumMaster, who is accountable for running Scrum and removing impediments affecting the rest of the team.
  • … and everybody else.

The team learns to embody an agile mindset while practicing a series of formal events:

1. The sprint is a fixed-length event of one month or less, and most commonly two weeks. The point of a sprint is to achieve a small, actionable product goal within its time frame.
2. Sprint planning most commonly manifests in a long meeting designed to take items out of a backlog and place them into an upcoming sprint.
3. Daily scrum, previously known as standup, is a 15-minutes-or-less check-in meeting where the team discusses its progress toward the sprint goal.
4. Sprint review presents the outcome of a sprint to key stakeholders and its progress toward its goal is discussed.
5. Sprint retrospective involves the participants of the previous sprint to discuss ways to improve its effectiveness in the next sprint.

As an aside, I think the most obvious anti-scrum red flag sits at the sprint review. If there are regularly no key business stakeholders at this meeting — or worse, they’ve pretended that they’ll watch a recording of this meeting — then whatever your management team says, your company does not at all believe in scrum.

When done with a team supported and invested in the idea, the effects can be significant. Sadly, there’s a good chance you’ve never observed this in the workplace.

Extreme Programming

Behind scrum in popularity, Extreme Programming is another agile framework that differs from scrum in a few areas. It’s largely more amenable to change during a development iteration, but it’s more prescriptive with software development practices.

Extreme programming requires more effort to implement than scrum, and that level of buy-in might cause teams to be more successful while adopting it.

SAFe

Then, last and least, there is SAFe — the Scaled Agile Framework. I am sure this has worked in some contexts, but most commonly I see it in large enterprise companies who have been told they can fully and successfully adopt agile by changing virtually nothing about their business whatsoever. Who could say no?

Out of all three of these frameworks, the journey of a business from where they probably currently are to where they want to go involves the least amount of change with SAFe.

There are other frameworks available for implementing agile, but the key thing here is that they generally prescribe a series of practices and events as ways to embody the mindset of the agile manifesto.

Kanban

The Kanban board itself has become synonymous with software engineering, but it’s applicable all over the place — this example is from the perspective of a content marketer.

Cycle Time

Kanban is a light-touch philosophy compared to scrum, but its key component is called cycle time — the time it takes for a card to go from the beginning of its active development through to being released into the world.

Sometimes, however, I also think it would be nice if we tracked the overall lead time — which starts the moment a card is added to the backlog — which would encourage product owners to not just let their kanban backlogs swell to a rough average of approximately infinity.

Kanban is one of the most recognisable workflows associated with lean manufacturing, a movement that was largely credited to Toyota starting in the middle of the 20th century. Lean was a response to the mass-production manufacturing model popularized by US companies like Ford and General Motors at the start of the 20th century. Lean went gangbusters in 1990 when it was introduced in a best-selling business management book, which I recommend reading, The Machine That Changed The World.

Lean manufacturing is fundamentally about the elimination of waste, which is broadly defined as anything that does not deliver value to a customer. This, applied to software development, often manifests itself in things like developers with nothing to do, or the time they’ll be bogged down by hefty context switching.

Essentially, Kanban and Lean are intermingled together, and truly adopting kanban means more than just having a nifty board. My topline interpretation revolves around three main principles:

1. Identifying value, where you work out exactly what your requirements are and do not commit to unnecessary or unneeded features, even if implementing Kafka would be super cool.
2. Creating flow, which means that the cycle time of your cards runs neatly and smoothly through your process and cards do not get stuck in review for 14 days.
3. Establishing pull, where work happens only because there’s a demand for it.

Continuous Improvement

Put all that together, and you once again achieve that much-desired state of continuous improvement. I think, all things weighed up, adopting kanban requires less overall investment for a team while still being able to deliver noticeable results. If you’ve only used the kanban board, I’d encourage you to give the overall lean philosophy a go and see where it gets you.

One of the potential downsides of a kanban philosophy in software engineering is that it’s very easy for hygiene work and quality of life improvements to forever be pushed to the end of the backlog, whereas with a scrum sprint you can — theoretically — define a percentage of your sprint to these kinds of tasks.

DevOps

DevOps is the most recent framework that’s joined our buzzword pantheon, partially in response to on-the-ground learnings from teams implementing scrum. One pain point was the difficulty in living up to scrum’s focus on delivering updates to customers when there were frequent bottlenecks when it came to actually deploying, maintaining, and running the software being created.

And so, the foundational principle of DevOps was born: You build it, you run it.

You Build It, You Run It

Teams that would have previously been categorized as developers or operations become cross-functional in the DevOps paradigm, boosting a sense of autonomy, ownership, and helping eliminate bottlenecks that would crop up on both sides.

One of the most exciting and, in some ways, radical elements of DevOps practice is that the DevOps Research and Assessment team (DORA, recently acquired by Google) spent years investing in empirical research and identified four key metrics to indicate high-performing teams. These metrics are:

1. Deployment frequency: how often your team can successfully get code into production
2. Lead time for changes: how long it takes for your commits to your main branch to reach production
3. Change failure rate: how regularly your releases to production cause problems
4. Time to restore services: how often it takes to restore normal service after production has exploded

I can say with reasonable confidence that if a team at a mid-sized company and above, doggedly pursues continuous improvement — yes, there’s that phrase again — on these four metrics, they will automatically find themselves pursuing, adopting, and embodying many of the other principles I’ve mentioned.

Adoption of DevOps has, in my experience, found itself stymied by organizational charts. Companies who shape their org chart with a ”Head of Operations” and a “Head of Engineering” will forever be too subsumed by internal politics to integrate, and I’m sure we’ve all seen a place where the operations team just rebadged themselves as the DevOps team and nothing changed whatsoever.

Alas.

Values, Practices, and Principles

One of the ways I’ve learnt to process and digest all of this internally in my own psyche is to wholesale lift the concept of principles, practices, and values from extreme programming. This particular model succinctly captures much of my frustration with the application of these frameworks and methodologies in the wild.

Values

Most companies have values, and they’re usually things like honesty and transparency. Values are good, but they exist at a somewhat abstract level — there’s usually enough wiggle room that you can do pretty much whatever you could possibly want and claim it respects the spirit of your values.

Practices

We do our practices on a day-to-day basis. Much of what we’ve discussed so far has been a practice. We go to standup meetings. We move tickets across a kanban board. We do or do not choose to write tests for our code.

Adherence to practices does not automatically denote embodiment of values.

Principles

Extreme programming presents principles as the bridge between values and practices. Principles are specific to the domain of your team and your work.

As extreme programming wonderfully puts it: “Values bring purpose to practices, practices bring accountability to values.”

The most common breakdown I see in teams is a values and practice mismatch.

I categorically believe that bringing in a certified Lean Agile DevOps ScrumMaster® and turning many practices into rote chunks of everyone’s day won’t help your company achieve the values it says it wants. In reality, it’s probably the opposite.

What’s Best for Your Team?

Let’s quickly talk about incentives. Many companies, including 8th Light, tie compensation and titles to the outcomes of performance reviews, and the vast majority of performance reviews are judged almost entirely on individual performance. As long as this is true, there will always be a slight, tangible mismatch between business reality and any of these frameworks and methodologies — which frequently proclaim the importance of a team.

Quality of work is important, but I believe people will largely self-optimize for compensation and increases in responsibility, too.

It has also always seemed counterintuitive to me that a core tenet of these frameworks is actively anticipating and embracing change, and then working in organizations that have attempted to implement one of these frameworks in a way that teams feel forever bound to a fixed process at all costs. Businesses regularly prioritize predictability over encouraging change, though of course that’s not inherently unreasonable in and of itself.

Optimize for People Over Processes

I believe energized teams that actively work to implement any of these frameworks can see enormous, gratifying success. I implore you to do so if you are in a position to do this at your company.

But, even if your management has forced you to subscribe to something that’s agile-, kanban-, or DevOps-in-name-only, I encourage you to use the opportunities that these frameworks can provide.

For instance, SAFe should provide the passengers of its Agile Release Trains semi-regular opportunities to get face time with key stakeholders as part of its program increment meetings. That’s probably going to be really hard to get if you’re working in an organization big enough to look at adopting SAFe to begin with. In short, you’ve got to take the opportunities where you can get them.

Each of these frameworks and practices is a product of its time — a response to something else that, at one point, was enormously successful and the way things were done. They are all hugely successful and important advances in how we organize, and they all remind us that change is inevitable. But to have a high-performing team today and for the foreseeable future, you’ll need to optimize for people not process.

About 8th Light University

8th Light University (8LU) is a virtual event series curated by 8th Light, a global software consultancy that partners with clients in creating software solutions. Topics focus on improving the craft of software product, design, and development. Software professionals of all skill levels are welcome! Watch past event videos on YouTube, join us at our next 8LU event, or sign up for our newsletter to to find out about upcoming events.