Descaling organisation with LeSS

Scrum is a successful and widespread framework, but at some point almost everyone started to talk about scaling. Large organizations want to spread this miracle and Agilize everyone. Many consider agilizing large organisations as bad, and some say it is inevitable. In any case, opinions are often negative about “big Agile”.

But what exactly is being scaled when we talk about scaling in Scrum or Agile software development? It seems that most imagine growing something larger, usually the number of people, or painting everyone in fake Scrum colours. “I see task boards, task boards everywhere!”. 🙂

Naturally, this triggers negative reactions from the Agile community.

Why would you want to deliver and support a product with multiple teams, when one team is so much more effective?

The first purpose of LeSS (Large-Scale Scrum) is actually descaling through organizational change. Descaling the number of roles, organizational structures, dependencies, architectural complexity, management positions, sites, and number of people. LeSS is not about scaling one team into multiple teams. LeSS is about scaling up Scrum itself in order to achieve organizational descaling. Just to be clear, looking for a scaling framework to “buy and install” and to organize lots of people for the sake of “painting agile or Scrum onto our big group”, is just plain wrong. Continue reading

My impression of LeSS practitioner course

Last week, I participated 3-day LeSS practitioner course by Bas Vodde.

Why LeSS for me?

Agile software development, XP and Scrum gave me a number of fundamental answers in how to improve my profession. Scrum is a simple and truly great framework for delivering working software. On top of Scrum, in the past years I’ve learned many practices, which fit really well with Scrum and help me solve many common challenges.

Nevertheless, throughout all these years, some fundamental questions remained: How does Scrum fit in large companies with strong hierarchical structures, and theory X way of thinking? Is the ultimate goal to Scrumise the whole company and everything will be great? Is this achievable, and does it make any sense?

I have seen some really nice examples where Scrum is applied throughout whole organisation in a certain way, like in The Netherlands. The reason why it worked in this, and other organisations have not much to do with Scrum, but already existing context and culture. This organisation embraced the fundamental Agile values and principles, and throughout continuous improvement they’ve naturally managed to be very effective with Scrum.

principles Continue reading

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