A couple of weeks ago there was a lot of heat and noise on Twitter and the blogs about Bob Martin’s foreman articles [1][2]. I think the powers of the foreman as described are somewhat draconian and excessive but when I think of some of the situations I have found myself in over the years I feel some sympathy with the motivation. This troubled me since it feels like a step backwards towards top-down, command-and-control development which is a complete anathema to me. Additionally, many people who I like and respect in the agile community came out vehemently against the whole idea of the foreman, saying they could not see why you would ever need one. So why did it resonate with me at some level?

Responsible adults

After mulling it over for a few days, I concluded that it resonates because I’ve been on teams, and more saliently, been responsible for teams, where the behaviour of some team members has fallen short of what I would expect from a responsible adult. Now, before people start throwing things I will readily acknowledge that:

• some of that behaviour has probably evolved as a defence mechanism in response to bad experiences of the system within which they find themselves (for example being outsourced by their employer, then insourced again, then…)

• I have exhibited almost all of the traits I list below at some point in my career in software development so I would like to apologise to my co-workers at the relevant times. If I haven’t done it myself then I have at the least been cowardly in failing to try and address such behaviour.

So what do I mean by “responsible adult”? To some degree it is hard to describe but something you recognise when you see it. However, some behaviours would be that a responsible adult…

• Does whatever is currently needed to deliver business value (as long as it is within their capabilities). This includes, but is not limited to, coding, testing, fixing the build pipeline, chasing a release slot, working out what customers  really want, diagnosing bugs, improving process and practice, etc. It is understood that all of this needs to happen and it is a whole team responsibility. There are no sentiments expressed like “this is getting in the way of coding”

• Willing to ask questions without fear of being wrong.

• Willing to address behaviour that threatens the team, such as one or more people not following agreed ways of working.

• Will accept the compromises needed to deliver business value within a reasonable timeframe.

• …

You know, the more of these I write down, the more they sound like people actually following the XP values. Funny that isn’t it.

Based on my experience, in order to succeed, agile/XP requires responsible adults both inside the development team and in the wider organization in which it operates (more of which later). I think that the reason why some of the people expressing vehement opposition to the foreman would never see a need for anything like it is because they have become accustomed to working with a higher percentage of responsible adults (whether by accident or design).  If you try to introduce or operate agile/XP without a cast of responsible adults then you will struggle.

So, how do you know if you have this problem? I have often had evidence staring me in the face of behaviour that does not meet the responsible adult criteria and have managed to ignore it (call it a cognitive bias, conflict avoidance or maybe mortgage-driven development). To help myself as much as anyone else, below is a list of associated behaviours that I think will cause an agile effort to struggle.

Before going further, it is worth pointing out that many of us are culpable. It is not just the team members who are pretending to do agile nor the business representative who wants all the benefits but none of the hard work but also the members of the wider agile community acting as  consultants, coaches and mentors who see that the context is not right for  implementing agile and don’t call it out.

CAVEAT: If you currently work with me or have worked with me in the past, none of these behaviours are based on a single person. I’ve seen them in at least several places. Also, they are not intended as a damning criticism, simply an observation that these behaviours can damage the team. If you think you exhibit one or more of them then maybe consider this further.

In search of responsible adult behaviour – inside the development team

Behaviours you might encounter within a development team that fall short of the responsible adult bar include, but are not limited to:

• The technical perfectionist. Trying to build a cathedral of perfect code disconnected from delivery. The enemy of “good enough”, incremental delivery and system level refactoring. Paranoia about any form of re-work. Takes on the parts of XP they like, e.g. refactoring and code-level TDD, but not the parts they don’t, e.g. pair programming and a fail-fast attitude. Sometimes treats everyone else as if they are an technical weenie or at least makes them feel that way.

• The framework builder. Things would be so much easier if you had a framework to avoid duplication and make things faster. Of course, building the framework will take some time but everything will be faster after that. Except it isn’t because the only person who really understands the framework is the framework builder and it is never finished because their initial assumptions about the solution are usually wrong. Takes up huge amounts of time that could otherwise be spent delivering business value (sub-optimally in their view). Related to the technical specialist.

• The absent leader. When the team is changing their way of working it needs the senior technical team members to lead from the front. However, sometimes you get a technical leader who is detached from the team, usually because they are externally focused. They see this as “protecting the team from the outside world” but maybe that’s not the most important thing at this point in time. Maybe you need to muck in and lead by example day to day.

• Han Solo. The individualist for whom asking sharing their keyboard would be akin to wanting to move in with them. They also usually have a phobia about meetings seeing communication as being a necessary evil to be minimised. Their favourite phrase would probably be “aren’t you facing the wrong way to be coding?”

• Maverick (named after the Tom Cruise character in Top Gun). They believe they can save the world through their own brilliance. If only they could do all the coding it would be done in half the time. The stakeholders are stupid anyway, the Maverick understands their domain far better than they do. Similar to the technical perfectionist but they will dismiss agile practices as unnecessary. As Ed Yourdon said of this type of personality in Death March, “God bless you; maybe you’ll succeed. In any case, nothing that you hear from an old fart like me is likely to change your mind.”

• No brainer. Doesn’t engage with the job. I’ll just do it the way I saw someone do it last week. It’s just a job. “Whatever”

If you are faced with a preponderance of the behaviours above I can see why you might feel that you need to employ a foreman or take on the role yourself, but the foreman is a self-defeating over-reaction. Either you need to help the people displaying the these behaviours to become responsible adults or you need to change jobs.

In search of responsible adult behaviour – the wider organization

The lack of good agile delivery is also usually a result of business stakeholder dysfunctions caused by lack of responsible adults in those roles including, but not limited to:

• Fire and forget. They don’t want to commit the amount of time needed to get a good result, leading to no real customer representation. But they will still get really angry when the delivered system is not what they wanted. With an amazing lack of self-awareness.

• The hollow stakeholder. The stakeholder representative for this team (often the customer representative) does not own the business function or process that they are representing so cannot take decisions. They must continually validate them with the real business owner who is mostly absent.

• Happy in chaos. The business function or process is essentially chaotic and consists of years of spontaneous decision layered on spontaneous decision. Answers from the business function owner are inconsistent and/or change over time. There is no appetite to make things better and in fact any efforts to do so, or even to point this out, are met with hostility.

• I want it all and I want it now. No sense of prioritisation. In their mind they can’t see why it can’t all be delivered. If you ask them to rate their hoped-for functionality on a scale of 1-10 (with 10 being the most valuable), everything is a 10.

Also, there are some easily identifiable team/organization patterns that you can spot if you step back from the detail of the day-to-day activities of the team. Some examples of which are:

• Cargo cults. Probably the most common pattern. The team does the agile stuff like standups, retrospectives, pairing and TDD without really understanding the principles they embody and the benefits they are trying to achieve through them.

• Shallow agile. Agile practices while retaining strong traditional roles (PM, BA, QA, dev lead, coder). Telltale signs are when people say “doing X is their job”. The developers usually end up essentially as code monkeys.

• Imposed agile. Agile comes in as part of a top-down transformation. Lots of agile books are lying around unread. Groups of expensive consultants are wandering around dispensing the knowledge they gained on their certified agile course.

There are often multiple of these in play at the same time.

In search of responsible adult behaviour – the wider community

Most people who have worked in agile for any significant amount of time, have seen or been part of failed agile efforts and have reflected on the dynamics in those efforts will probably have come to the conclusion that agile has a sweet spot in terms of the context in which you practice it such as:

• there are a large number of responsible adults in the team and the wider business
• there is an ongoing relationship between the team and the wider business
• the value being delivered mostly consists of adding new functionality rather than replacing big chunks of existing functionality like-for-like

If you consider yourself one of the reflective practitioners in the agile community you should know that context defines what constitutes good or bad software development practice. If your context differs from the sweet spot then you might well be sending the organization backwards and not forwards. We – the supposed cognoscenti – who know, or think we know, what good agile software development looks like, are as much to blame if we try to apply agile in a bad context or don’t put the work into making the context more agile-friendly before trying to implement the practices. This can sometimes require difficult conversations with the people who pay the bills or may ultimately need you to walk away from the consulting/training revenue.

Give us a clue

So, what do you look for if you want to avoid ending up part of a bad agile implementation? Well, the most common blocker to running a project in a truly agile ways is the that environment or wider organization in which they operate is often hostile to agile software development (a topic I explored a little with Allan Kelly at XP Day a few years back). At the next level, the teams and individuals often don’t help themselves. If you want to get an idea of whether agile is really happening or on the size of the effort required to make it happen then ask some telling questions of the team and its stakeholders. Generating some suitable questions based on  your own experience or on the behaviours as described earlier is left as an exercise for the reader. If you don’t like the answers then it’s up to your conscience and your appetite for hard work to determine what you do next.

Good luck!