Is future developer a jack of all trades?

Developers in large projects with a complex organizational structure (many roles, management layers) have rather specialized jobs. They work on a single application / component with maybe few 100K lines of code and most of the time deliver a component based on provided specs. Developer is usually involved in some testing and requirements gathering, but it is limited. Even coding part is often specialized. A CPP developer only writes CPP code. Infrastructure configuration is done by a specific person, database also, etc.

In other words, a highly specialized work. From a local point of view this feels very efficient. The developer’s thinking: I spend my time most efficiently when I write code.

Continue reading →

How do we pay people in a LeSS adoption?​

In a LeSS course and a LeSS adoption, the question is asked how do we pay team members, Scrum Masters, and even managers. The reason why this question is raised is due to significant reduction of organizational complexity. The number of roles, layers, positions is much less to choose from or grow towards. This seems to create some kind of communist system :-). Nothing is further from the truth.

Screen Shot 2018-08-16 at 09.34.44

Let’s go through what is already known and described by others. Continue reading →

Dependencies, teams and microservices

The Candidate LeSS trainers mailing list is a place where passionate people have interesting discussions. This post is a result of one of those discussions.

An assumption in agile community is that scaling agile is mainly about managing and reducing dependencies; either between teams or with others outside of a product group. This is used as a reason to introduce additional structures and roles, such as architecture owner, program / project manager, integration or a system team. These groups will manage dependencies and have overall picture.

An alternative is presented: microservice-driven teams organization. Each team works relatively independently from other teams, and owns set of microservices. Well…let’s see.

Just like embracing instead of managing changes (one of the Agile principles), this post explains why we should embrace dependencies instead of trying to avoid or “manage” them.

Therefore, LeSS doesn’t have roles, structures or architectural solutions to manage or reduce dependencies.

Of course, dependencies do not magically stop to exist in LeSS. There is something else going on. Let’s go through common types of dependencies.  Continue reading →

Do 12 Agile Principles scale?

Do you remember those 12 Agile principles written a loooong time ago? Well, the whole Agile thing is kind of based on them.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Of course, after such a long time these could be outdated. Since we love continuous improvement, the same could be applied to principles too right!? Well, a funny aspect of really good principles, is that they do not change easily.

I don’t have a good reason to suggest any change. Although there are few words here and there that could be different (e.g. overemphasis of projects instead of just product development), the reason to suggest Agile principles 2.0 would be too weak.

Nevertheless, a lot is written about how Agile Manifesto is outdated, something that was hot in 2001, but world has changed in last 10+ years. Therefore some improvements are suggested.

So, this is all great. Good discussions. But, what really bugs me are the compromises.

improvements_vs_compromises Continue reading →

Scrum, dogmas, and actual results

The following statements are often mentioned:

  • Scrum-but is bad. You should stick to Scrum rules, otherwise you are doing it wrong.
  • Scrum coaches are often dogmatic.
  • There is no right or wrong way to do Scrum. It is all about inspect and adapt, even for Scrum rules.
  • My Scrum-but way is working very well.

I could continue, specially when talking about certain details. Such as, does it make sense to have 5 Scrum teams with 5 Product Owners delivering a single product? Continue reading →

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 Bol.com 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?

pairon

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.