Other So-Called Agile Practices

Pair Programming

Where in the Agile Manifesto does it mention pair programming? It doesn't.

I am a strong advocate of pairing people when one must learn from the other: put the learner in the "driver's seat", at the keyboard, and have the other - the person with the expertise to be shared - in a second seat, watching, and advising. But that's not pair programming.

Pair programming has its root in eXtreme Programming (XP). The central idea is that two people working on code together will accelerate their thinking through collaboration, and that they will catch each other's mistakes.

It seems like every time I explain my objections to pair programming to someone who is a fan of it, they say that I am "not doing it right", and they then explain a different approach. Each person describes it differently.

For example, when speaking with a pair programming fan who leads a group at Netflix, I complained that I often want to think in isolation before I code. He said that that is normal for pair programming, and then one only sits down as a pair at the keyboard when one is ready to.

Yet speaking to someone else about it, I complained that I don't think well in "real time", and that when seated with someone else, I will tend to retreat mentally and let them take over. He said that "I am not doing it right", and that I need to stay engaged all the time, and "let the juices flow" - that I need to get used to continuous dialog about a problem, driving the conversation deep.

Hmmm. Two different versions. That's okay - but it means that pair programming is different things to different people. So why can't someone be different enough that they don't pair at all?

What works better for me personally is to first think deeply, and design my approach at a high level; then discuss that with someone to get another perspective. And then code it. And then validate it through working examples. That's a kind of pairing, but it is not pair programming. And I think it is a good approach. It suits me - a top-down thinker and a "theorist" at heart. It does not suit a bottom-up thinker - an "experimentalist". And that's okay.

So being "Agile" does not mean that you embrace pair programming. The Agile Manifesto does not say anything about pair programming.

Open Team Room

Where in the Agile Manifesto does it mention an open team room? It doesn't.

The open team room comes from eXtreme Programming and from the Agile Manifesto's emphasis on verbal communication. But when I worked at a series of startups during the 1980s, which used very Agile methods, we had private offices. We collaborated continually: we would pop in and out of each other's offices. We were co-located - the entire product team was on the same floor in the same quadrant of the building. But we had doors on our offices, and were one person to an office, so if someone needed to focus, they could close their door.

What about the "osmosis" that open team room fan talk about? In truth, that could be a problem. But in the open team rooms I have been in since then, it has also been a problem. In fact, studies have shown that open team rooms actually decrease communication and collaboration! Programmers - natural introverts - react to the forced lack of boundaries by creating their own, through headphones and keeping their heads down.

So "being Agile" does not mean that you embrace an open team room. It means that you value frequent collaboration - however you achieve that.

Talking Over Writing

Where in the Agile Manifesto does it mention that one should always communicate in person instead of in writing? It doesn't. What it says is, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. "

But that is not the same thing as saying always communicate verbally. Efficiency is not always the goal - effectiveness is. And I would even take issue with this one principle of the Agile Manifesto.

The fact is, effective communication about complex topics often requires an extended conversation that includes many forms of communication: writing, speaking, listening, and diagramming.

If you want to ask someone a quick question, verbal is usually best: "Hey Susan, what is the data type of the User Id field?" and she says, "String", to which you reply "Got it, thanks!" and you get back to work.

But if you want to discuss your branching and merging strategy, and how that might work together with your integration testing approach, some people might want to do some private thinking first, and then write up their ideas and share those in an email. Others might want to start with a meeting right away. People are different, and that is okay.

Don't force everyone to meet in person about everything that needs to be discussed or decided. Be sensitive to the nature of the issue, and how some people might need to process it and communicate about it at various stages in the discussion.

So being "Agile" does not mean that you always default to in-person communication. It means that you value communication, and its quality, and seek to optimize it, no matter what forms it then needs to take.

The Scrum Master Role

Where in the Agile Manifesto does it mention the Scrum Master? It doesn't.

There are two principles in the Agile Manifesto that pertain to leadership:

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

and

The best architectures, requirements, and designs emerge from self-organizing teams. 

But neither of these says that a team should not have a team lead. The second principle above advocates for self-organization, but it does not say that one should always have teams self-organize: what it say is that when self organization works, it works really well - probably better than any other approach. And I definitely agree with that.

But it does not always work. In fact, the creator of the Tuckman model, which is often cited by Agilists in support of self organization, said clearly that self organization often fails.

The Scrum Guide defines a Scrum Master as someone who helps a "self organizing team" to adhere to Scrum. It describes a person who mainly acts as a "master of ceremonies". That can work sometimes, but in my experience with programs that have lots of teams, it is not an effective approach.

The extreme alternative is not effective either: the autocratic team lead. I have had those. They are terrible: they tell everyone what to do, design everything and hand out tasks. When they leave, no one knows how to do anything on their own. And when they screw up, they seldom take credit for their mistakes. We don't want that kind of leader.

What we want is a transformational leader: someone who keeps their eye on things, prods and nudges people, checks in on things continually, and notices gaps. Someone who has their finger on the pulse of the work, and does not differentiate between technical and non-technical issues. Someone who does not boss people around; but nor do they wait for things to happen: if something needs to be happening and is not, they get people together and say, “What about that? What should we do?” And they do not hesitate to give their own thoughts: they have cultivated the trust of their team so that everyone knows they can speak their mind, and all ideas are discussed on their merits.

And most importantly, while they expect team members to make their own decisions most of the time, an effective leader sometimes makes decisions too, and when they do, they take responsibility for it and don’t blame the team if things don’t work out. They have the team’s back.

That's an effective team lead. Some teams can self-organize, but others can't. And even among those that do, they often don't know what they don't know. An effective team lead makes it their job to stay aware of what is happening outside the team that might affect them.

Fans of self-organization will say that the team should do all these things; but in my experience, most teams don't. Things especially fall down for the things that need to span teams.

So "being Agile" does not mean being a fan of self-organization. It means that you believe in empowering the team, helping them to be as effective as they can be, and looking out for them. It also involves mentoring them, or bringing in people who can mentor the team on specific topics, such as DevOps and new tools and technologies, or security expertise, or business domain expertise.