My Take on Modern Agile

The cover version

I’ve had some good experiences using the Modern Agile model for explaining agile thinking to people. For reasons laid out below I use a somewhat adjusted version of the model (words in italics have been altered from the original), like this:

  1. Make users successful
  2. Create a setting for great teamwork
  3. Deliver value continuously
  4. Experiment and learn rapidly

If you’re interested in why I feel that Modern Agile is important and why I have adjusted it for my own purposes, please read on.

Introduction to Modern Agile

If you’re familiar with the Modern Agile model you may wish to skip to the next section.

Modern Agile (or MA, for short here) is a thinking tool/model by Joshua Kerievsky of Industrial Logic. The model is a modern take on agile thinking that has gained a lot of interest over the last year.

Modern Agile consists of four principles or values, see image below.

Modern Agile Wheel

The yellow principle, Make people awesome, informs us our job should about creating successful people through our products and services. Who cares if we delivered three new features last week if the customers didn’t find our features useful?

The blue principle, Make safety a prerequisite, points out that nobody performs well unless they feel safe, including psychological safety. And we’re not really safe at work, it turns out. Most employees are just accustomed to taking individual risks or being mistreated. This also includes technical practices that help us share and reduce risks.

The green principle, Deliver value continuously, says that we should create a continuous stream of value to our customers. We know today that stopping and starting work is wasteful. In software we include practices that make us reduce lead times for delivery; improve collaboration, build quality in, break down work into small pieces and how move them quickly and safely into production. Even more ambitious, we need to do this in a sustainable way.

The red principle, Experiment and learn rapidly, concerns our ability to conduct small, safe-to-fail experiments and learn from them. We win by outlearning our competition. This concerns both the product dimension (the outcome of the work) and the process dimension (how we work).

For more details, see the Modern Agile homepage.

Why I like it?

I think there are several advantages with Modern Agile compared to the original agile manifesto (or AM, for short here). The AM was, and still is, a fantastic summary of some important values and principles in software development. Although now a historic document, it’s still highly relevant in most corporate settings. For example, many people still believe documents are somehow more professional than “just talking”. Not to mention the importance of “having a good plan”.

But let’s face it, the group that created the AM was desperately low on diversity. Apart from the glaring fact that they were all white, middle-aged men, they were all software developers. There were no interaction designers, no UX specialists, no software operation experts in the Snowbird cabin. Hence, there was a distinct lack of knowledge around important parts of the software development value stream, which, of course, lead to their exclusion from the manifesto.

Just to name a few examples, the manifesto tells us to collaborate with customers, but where are the users? It tells us that the software should be “working”, but not usable, useful or valuable? It’s hard to avoid the conclusion that the model the signatories had in mind was collaboration with one or a few persons that knew all that was needed about what problem we were trying to solve, the users and their context, the intended use of the program, and relative priorities. Today, we know that model to be flawed. Understanding user and customer needs is a journey of discovery.

Even more obvious today, organisational functions outside of software development were not considered in the AM. This is no criticism, just an inevitable fact. I mean, how could they possibly have known that agile thinking would become so successful to spread to departments outside of IT/Development?

The Modern Agile model incorporates the missing parts of the value stream and many learnings we’ve made since the writing of the manifesto in 2001. Just think about what we didn’t have back then; no Kanban method, no Lean Software Development, no DevOps, no Lean Startup, no cloud, just to name a few. We know today that the most effective development model is to flow small pieces of value as often as possible to the users/customers and tighten all feedback loops. We know today (and we actually did already back in 2001) that we cannot simply listen to what users tell us – we need to research them to understand their needs and pains. We know now, thanks to Kathy Sierra, that our objective should not be to create a great product – but a product that makes users great. We know today we can automate, not only the building and deploying of software, but also the infrastructure, configuration, and data on which is depends. We know today that it’s actually possible to work in a way that incorporates improvement on a daily basis, not just reflecting for an hour every two weeks.

And as Agile thinking is spreading outside of the IT department, agile advocates need a common model to explain what we mean without each having to adjust ye ol’ manifesto individually – or leave it up to the listeners (not recommended). I believe Modern Agile is a nice effort to generalise the agile mindset. Having a model that can be used without adjustments when speaking to finance, HR, marketing, sales, executive teams or whatever else is wonderful.

But there are some challenges…

Just one guy

The original manifesto was created by a group of software and methodology experts (albeit a low-diversity one), many of whom were already well known pioneers and thought leaders. To me, that spoke volumes at the time. I was already into Extreme Programming when the manifesto was published, but when all these really smart people, even heroes to me and my friends, all said the same thing that had to count for something. It showed me I was on to something that would not be ignored.

However, behind Modern Agile there is only one person and no matter how wise and experienced Joshua is, we cannot escape the fact that there’s no community agreement that Modern Agile is really what we mean by Agile in 2017.

“People” is too broad

I find the word “people” in Make people awesome to be too generic a word for my taste. This principle is deliberately inclusive to everyone in the game; customers, users, managers, coworkers, families, suppliers, etc, which is nice. MA asserts we should strive to make them all great. This fits well with Jurgen Appelo’s assertion along the same vein, that we can’t focus on one or two stakeholder groups, to the detriment of the rest.

However, one could argue that by including everyone, you are also not excluding anyone. You’re not having an opinion. It’s like a product prioritisation where “everything is important”. To me, that makes it weak and not very useful.

Also, in my book there are three groups with more skin in the game than the rest: The software users (using the product or service), the customers (the people paying for the product or service, often the same as the users) and the developers (everyone involved in creating the product or service). The aim of the Make safety a prerequisite principle are primarily developers so they’re already covered, in a way, but we need to specifically address the users and customers, because losing focus of your user/customers is deadly. Perhaps less important I find the word “awesome” a bit childish and exaggerated.

Currently I lean towards using “users” instead of “customers”. My thinking here is that, when users and customers are not the same, which is typical in an internal IT setting, if we provide software that fulfil users’ deep needs and make them succeed in their job that will, in turn, create better organisation and satisfied customers as a side effect. Using “customer” on the other hand could lead us to focus too much on the person paying for it and too little on the people having to use it. If the users are also the customers, it doesn’t matter, the words are interchangable.

Summing up, I believe the original formulation of this principle was Make Users Awesome and I believe going back to something along those lines makes it stronger.

“Safety” is too narrow

On the other hand, I find the word “safety” in Make safety a prerequisite to be too narrow a word to well describe all the intricate, interlocking mechanisms and conditions needed to release people’s builtin capacity for great teamwork and joy at work. Yes, it is indeed very important, according to project Aristotle, perhaps even the most important, but there are other important factors around teams that I find hard to ignore.

There have been many attempts to capture important factors in models. Dan Pink’s book Drive popularised the Autonomy – Mastery – Purpose model. In Jurgen Appelo’s book Management 3.0 he identifies ten “intrinsic desires”; factors that contribute to motivation. Also, we have Patrick Lencioni’s popular book Five dysfunctions of a team, naming trust, constructive conflict, shared commitment, mutual accountability, and focus on results as vital for teams. To continue, one could add W. Edwards Deming’s and Russell Ackoff’s teachings around quality and systems thinking, pointing out the vital importance of setting up the system (the context) properly. Individuals or teams don’t stand a chance in a broken system.

Another aspect of safety is what one might call technical safety. By that I mean technical practices that help us share and reduce risks. Common examples of this are pairing, mobbing, version control, test driven development, continuous integration, deploy pipelines, etc. I perceive these to contribute a lot to safety, and consequently equally much to teamwork. Of course, they also contribute to the continuous delivery principle.

Moving on, also I prefer “teamwork” over “teams”. Among agile thinkers there’s a lot of focus on the team. To me, however, a team is a vehicle. What we really want is great teamwork. Chances of teamwork are probably higher in a team, but having a team is certainly no guarantee of fantastic teamwork. Also, we want to work well in the team of teams surrounding us. And of course, if we can establish great teamwork with our users and customers, that’s even better.

Summing up, in my opinion the wording around this principle should mirror that we know something about enabling people’s intrinsic motivation setting the stage for great teamwork, but that we have no definite list yet.

Final words

If you’ve read this far you know how I feel about Modern Agile and how I use it. I hope it was useful. I want to extend a big thank you to Joshua Kerievsky for his contribution to our field. Comments or suggestions are highly appreciated.

Why You Should Avoid Using Projects in Software

Summary

Organizing work around projects does not fit any form of work that is creative, open-ended, and patterns-based, relying on human ingenuity and judgement to create value. This is most notable in research, creative jobs, and development in all its forms; be it organizational change, personal growth or software development.

Projects in Open-ended Endeavours

What would the 15-year-old Jack Nicklaus, the legendary golfer, have responded if his coach had asked him for the probability that he’d meet milestone 3 for project Winning British Open as defined in the project plan as per 7th of March?

Golf ball 3

Yes it’s kind of silly to imagine this happening – yet in software this is just a part of normal life. Every day, thousands of developers and teams are asked to compare their progress against The Plan and estimate how much is left.

Now, I agree that writing software is not the same as developing your golf skills, but considering the level of craftsmanship and inherent variability in software it’s more appropriate and valuable to me to compare it to other kinds of patterns-based, open-ended activities than with production lines chugging out the same item over and over again.In these endeavours having a plan is actually less important that making steady progress and creating value.

A painting is finished when the artist says so, based on skill and experience gathered over a lifetime. But from the customer’s perspective it’s finished when it is finally destroyed. So who’s right? Both, I guess. A defined finish seems to not exist here. The same thinking can be applied to, for example, a research paper or a software program I think the common element here is that we are creating — and anything created has a life cycle, which resists being put into a project management framework.

Just to be clear, when I write project here I don’t mean a batch of work that belongs together. The latter are naturally occurring “lumps of work”. I use the term initiatives or epics for those. When I talk a about projects I mean a way of organizing work following some kind of formal or informal project model, typically lead by a project manager, with the expressed goal of delivering everything in scope on time and within budget. An initiative doesn’t need any of that.

But What About Agile Projects?

People still ask me: How should we work in agile projects? To start with, anything prefixed with  “agile” is cause for concern. Anything that requires modulation cannot possess that characteristic in itself, by nature, but must be adjusted to fit. That’s why we have “agile requirements”, “agile documentation”, “agile contracts”, “agile planning tools”, “agile processes”, “agile management”, and… “agile projects”.

So we know that projects need to be modified to fit an agile organization. And many people have written about that to explain how you should adjust your project model to work in an agile fashion. That’s fine, but that’s not my point. My point is this: Why bother?

Asking about how to do agile projects is the wrong question I feel, since it assumes that projects are the best (only?) way to work with software. A more interesting questions to me is this: How should we organize our work to create maximum value (learning) over time? And to the this question I strongly believe that the correct answer cannot be “in projects”.

Why Projects Aren’t Suitable In Software

Here’s a list of reasons I’ve compiled over the years, use it as you see fit…

  1. Projects encourages important thinking upfront, investigating problems and drawing up solutions, but… we know that we want to harness the learning built into development. Why make so many decisions right at the start, when we know the least?
  2. Projects by definition have a defined start and ending, after the project the results must be handed over to some other type of organization, but… software has a life cycle. Software is created, developed, actively maintained, passively maintained, and finally, decommissioned. Software and projects operate on different timescales.
  3. Project results are typically handed over to another group for “maintenance”, but… we know that handovers are costly and excellent quality requires ownership and continuity.
  4. To reach project goals, especially on dates and costs, quality is pushed to the background. Some projects even result in so-called “death marches”, where delivering something maintainable is not in scope, but… in software, quality is a primary success factor… because without excellent intrinsic quality, your product will be slow and expensive to maintain and have a high life cycle cost.
  5. Projects encourage us to create batches of work, being a big batch in itself, but… we know that a steady flow of value is way more effective (feedback + learning).
  6. Projects (and PMs) often entertain a narrow view of success, i.e. what’s best for the project, but… wouldn’t we rather optimize for the whole company? A project is a target to a PM and, as W. Edwards Deming famously said: “Give a manager a target and he will reach it, even if he has to destroy the company in the process“. Especially large projects tend to behave a bit like the old schoolyard bullies, taking what they feel like without asking.
  7. To acquire funding for their projects, PMs are often tempted or forced to overstate the expected positive outcomes of their projects, otherwise it won’t get funding, ending up in a never-ending spiral of silly overstatements, but… most people are decent and prefer to work in an environment where they don’t need to deceive others to do their job.
  8. Projects typically require setup, allocating people, finding resources like office space, writing presentations, holding lift-offs, agreeing on vision, mission, and how to work etc. In most settings you pull people to the project and not the opposite, but… we can do away with all that by simply letting teams already in full operation pull work to themselves instead.
  9. Projects use budgetary mechanisms to give attention to ideas and allocate funding to them, but… having funding is a very poor raison-d’être while creating happy customers is a good one.
  10. For psychological reasons (for example, ego and careerism) it is tempting to create massive projects for bold ideas, but… we know that large projects are associated with stunningly high risks and low success rates, close to zero after some point.

These observations have nothing to do with agile methods or any other school of software development. In fact, it has nothing to do with software development at all. It’s at the heart of all creative, open-ended work, including arts, craft, writing, architecture or organizational change. This also explains why having an agile “rollout” plan is silly. Change is not a project and it’s not as easy to simply “implement” it (I wish it was).

Now I don’t want to imply that if a client comes up with a project plan you should laugh in their face. Of course not. There are situations where projects can be suitable, e.g. when working with a new contractor team outside your organization. You can use the project to get to know each other and the defined end date to call things off if it didn’t work out. Just be aware of the risks that projects bring and work to mitigate them.

The Alternative

The alternative to not working in projects can be outlined like this:

  • Create and grow long-term, cross-functional development teams that create their own, smooth development process.
  • Give each team clear ownership of a product, part of a product or a few products, depending on size. Cultivate a long-term, product outlook on development.
  • Task each team with delivering value to customers (or learnings if something is unsuccessful) continuously, as often as the market can handle it, while expending less and less energy to do it.
  • Help the teams create more value to their customers using sound prioritization schemes and pull systems for work.
  • If suitable, batch larger work into initiatives, lasting a couple of months (enough to create milestone challenges to the teams), but keep scope high-level and stay open to changes and complete turnarounds as the learnings start pouring in.

You can of course persist and keep trying to make agile projects work, but seriously, why bother if you don’t have to?

When the manager’s out, the coaches dance on the table

I work as a software consultant and often in the role of a so-called “team coach” or “agile coach”. That’s basically just a hyped-up term for helping teams and departments to improve, to be more effective, and guide them on their way amongst a myriad of options. So coaching is great and many coaches I know are great, but there’s something bothering me. My opinion is that much of what I do is a kind of management – not of the people but of the work, and I’m getting more and more concerned about this. Should this really be the coach’s job?

Continue reading

Honey, let’s start over: A tale of business kaikaku

When Ian told them what he’d done, they couldn’t believe their ears. He had what!? He had erased every document in the company database concerning hiring and retaining staff. Joan’s deep thoughts on “talent management” simply gone. Gone! “Hey, what about the backups?”, Helen asked. Ian just smiled, “Those too”.

Continue reading

Recently, I retweeted an item from Neil Killick and I was surprised to see a response from Tom Gilb, legendary software methodologist. The tweets can be viewed in the picture below (read from bottom up).

Two tweets, my retweet and Tom Gilb's reply

Talking to Tom

Apart from the honor of getting some of his attention, I was a bit concerned with the response. I seemed simplistic and categorical to me. Quite frankly, it sounded like something out of a schoolbook in software engineering from the 80s. I find myself in disagreement with it. To disagree with Tom Gilb is scary so I needed to write down why.

Continue reading

Functional Scope Design: Why requirements must go and design for use should take its place

The Kanban Drama (a summary)

For those of you who don’t have time to follow along with every twist and turn in the ongoing struggle between Kanban connoisseurs and the rest of the software development world in general I would like to take this opportunity to summarize my impressions of what has happened over the last five years. It takes the shape of a short play. It’s a summary so I have taken the liberty of slightly shortening and abstracting history. Only slightly. Enjoy!

Continue reading

A User Story Template for Effect Maps

Introduction

If you are into User Experience (UX), you may be using effect maps, also known as impact maps or goal maps, to guide software development towards the intended effects. These maps are used to describe how your business goals will be achieved by helping important target groups fulfill their goals of using your product or service.

If you are using agile software development, you are probably using user stories to describe your features for development using some common template. In this post I will suggest a new user story template, specifically designed to be combined with effect maps.

Continue reading