How to make people do pair programming?

During one of the open space sessions at CITCON Asia in Hong Kong 2015, a question was mentioned by several people:

How do you convince people and make sure they start doing pair programming?


A short answer would be: You don’t.

Almost all developers tend to dislike idea of pair programming if they haven’t tried it before. It sounds quite weird, inefficient, and scary. Besides, any argument for starting to do pair programming by itself is weak at best.

  • “Two people deliver work of three people if they do pair programming” – Yeah, right. A very bold statement. How did you measure that?
  • “You will deliver higher quality code” – That could be, but we already do code review afterwards.
  • “You will learn faster from each other” – Yes, others will learn from me, and slow me down. I’m faster than others, and don’t want to waste my time.

There are probably many more of these reasons not to try pair programming. They will usually end up in a really awful feeling where developer feels being forced to start doing pair programming, as if he does not know how to perform his job.

A much more successful approach is where you don’t try to change people’s behaviour, but the system surrounding teams:

Reduce multitasking

Inexperienced teams usually work on just as many stories as number of team members. Number of tasks is usually even higher. The most common effect is not being able to deliver much or anything according to Definition of Done within one sprint. Team will reflect on this and start reducing multitasking. This will automatically encourage people to start helping each other and finishing stuff before starting to work on something new. Helping each other often means sitting together behind a machine and making sure things are finished faster and better.

Stop fixing bugs, and start preventing them

Create awareness in team how wasteful it is to fix bugs or have dirty code. Those bugs should not be there in the first place. “Let’s talk a bit about our bugs. What kind of bugs do we have? Let’s do root cause analysis on them.” This process often leads to lack of knowledge and practice for less experienced guys. Most experienced guys are the ones who are most annoyed by dirty code and bugs. At that point they are more likely to see the advantage of sitting together with less experienced guys.

Stop measuring individually

Any individual KPI and objective is killing pair programming from the start. Instead, the outcome produced by the whole team should have the focus. By focusing on the outcome, potentially releasable increment, team will naturally realise how much they depend on each other and the need to work together more intensively will emerge.

Value continuous learning

People love to learn new things. In fact, most developers will remain in a team for a long time if they are continuously able to learn new things they choose themselves. That could be a new technology, or simply how to talk or explain things to others in an effective manner.

At the end, pair programming is just a mean to an end. Trying to sell a practice because you know it is good, is never a good idea. No developer really loves pair programming practice itself, they love working together, learning new stuff, writing great code very fast, and being appreciated for help they give to others. One way to achieve this, is by doing pair programming among many other possibilities. By emphasising the real things, you might discover that pair programming might not be a good idea in your situation.

Velocity increase is evil

The practice of story points in combination with velocity and burn down charts can be a very powerful tool to make predictions for planning purposes. If teams know their velocity – based on actual experience in the first sprints, and have estimated story points for all requested items, team can make quite useful predictions about amount of time and therefore budget. This simple practice actually works in reality as described. It can be used for release planning and budgeting. The main difference with traditional way of planning is not relative estimation aspect, but continuous nature. Even story points practice that uses baseline of previously gathered experience will give imprecise calculation of work that still need to be clarified, and we therefore know so little about. It is important to regularly reestimate items on the product backlog, foremost for better understanding, and also improved predictions and better planning.

In fact, you could also measure team’s performance with this practice, as so often explained by Jeff Sutherland. “A good team should have velocity increase of about 10% every sprint.” If team’s velocity increases, it means that team has improved productivity, right!?

Measuring productivity based on velocity is illogical at best. It would be interesting to notice how one makes release planning and budgeting based on 10% velocity increase every sprint.

Using velocity to measure team’s productivity is wrong. Actually, extremely wrong. From all possible reasons for velocity increase, actual productivity increase is least likely. Let me give you the actual reasons for velocity increase:

Continue reading

Discover own or use existing practices

We, Agile Coaches, preach experiments, inspect and adapt / short feedback cycles, and that early failure is good (although we don’t really mean “failure” in this context). In this way of working we discover new ways of delivering software, forever improving our profession.

On other hand, most of the daily challenges we encounter in software development are already solved by some previous team. In fact, these solutions are already documented in many great books and articles. So, why don’t we just read these patterns books and simply apply the solutions for any of our problems? Why experiment if somebody has already done it for us? I can assure you that your current problem and experimental solution has already been solved by somebody else in an enough similar context.


This dillema can be summarized by a frustrated developer who said to me once:

Why don’t you just tell us what to do, so we can get over this and just do it?!

Continue reading

LeSS framework and architecting

LeSS framework is basically Scrum, only scaled-up. It is more an additional set of rules and a really good explanation on how to apply Scrum in a scaled situation and still remain effective, than a framework on its own. This is especially evident when compared to other scaling frameworks. LeSS can be used to work effectively on a single product with multiple teams, and even thousands of developers.

less_frameworkA particularly interesting part is the emphasis on technical excellence. It is one of the extremely important aspects often neglected in Agile introductions. Among things like clean code, TDD, continuous delivery, the framework also describes the way we should deal with Architecture & Design in a very refreshing manner. Instead of creating additional organisational structure, roles and artifacts, Craig and Bas give a number of tips.

Think ‘gardening’ over ‘architecting’—Create a culture of living, growing design

This metaphor is intended as replacement for the building metaphor, which is usually used to describe what architecture means. The software systems are grown by incremental development, not built.

The rest is a large set of useful tips and direction of thinking when dealing with large scale Scrum. Here are few of these:

It is so important that every act of agile modeling and programming for the life of the system should be treated as an architectural act.

Standard whiteboards are possible but not usually sufficient–and in fact are often an impediment, because modeling is best done on vast open wall spaces without borders.

Encourage everyone to question and challenge all these assumptions [early architectural choices] and decisions, and to find ways to apply the lean thinking principle of decide as late as possible or defer commitment.

Technical leaders teach during code reviews.

Communities of practice (CoP) are an organizational mechanism to create virtual groups for related concerns.

Internal open source with teachers—for tools too

Don’t use stubs to delay integration

This should be captivating enough to make you visit the site.

Can we introduce real Agile mindset in a large traditional organisation?

The one million dollar question right!? A real answer is probably worth a couple of millions. 🙂

As often before, I’m “encouraged” by friends to explain better some of my statements. This time by Roy van Rijn. You should also visit his blog.

Let’s assume you are working in a multinational and a traditionally structured insurance company. A business request goes through many departments and it takes ages to get them in production. Business does not trust IT anymore and vice versa. This ends up in “sellling NO” or postponing behavior of IT people or creation of complex IT projects. CIO is a 40-year old guy who just bought a second hand Porsche 911 as a result of his midlife crisis. In other words, he is in the mood of trying out something completely different. He heard about Agile thing multiple times already. It seems that everyone is “doing it”, so he wants it too. Besides, he hears about these amazing stories where speed of delivery and quality have dramatically increased.


There is only this annoying small problem: his organization is a very traditional one, so introducing Scrum seems extremely disruptive or even impossible. As much as he is inspired by stories, changing so drastically seems very unwise. He invites several different “Agile” consultants / coaches and asks for advise. The one with most attractive approach will get the assignment and start with organisation-wide Agile transformation.

Continue reading

Teams in the driving seat

Two weeks ago, InfoQ published our article about many experiences with Scrum at Port of Rotterdam. Several people contacted me afterwards with questions and one of them was an IT manager in a large organisation. He made a very short and interesting summary:

So, developers / teams are in the driving seat!

This characterisation is pretty good and can be used as a test for knowing how Agile your teams really are.


Very often, “being Agile” is confused with having teams following some set of practices “correctly”. That could be XP practices, Scrum practices (3 roles, 4 meetings), or something else.

“Teams in the driving seat” means that in a large organisation, information and artefacts are pulled instead of pushed. In a big enterprise, business has some need, which is usually pushed to IT management or product owner, translated by (business) analysts, pushed to Agile teams, which deliver a product in increments.

In case of really effective Agile teams, the need is much more pulled than pushed. The business still pushes the high level idea, with its very limited definition. After this, the initiative is taken over by teams. This switch may happen with a statement from the product owner:

My need is ….. Please enlighten me if this is sensible and what more you need from me so you can pick this up.

From this moment on, teams are in the driving seat and request or pull everything they need in order to deliver value. They are the ones actually deciding which information needs to be gathered, questions answered, artefacts delivered, process followed, and so on. They may request assistance from domain experts, BA’s or architects.

For large organisations with strict processes where first architects and business analysts are involved, direction actually set by IT people instead of business, different levels of management approval is needed, this is a major change in behaviour.

So, next time you hear someone telling you about their Agile teams, ask them who is actually driving the car and who is giving directions.