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.
Let’s go through what is already known and described by others. Continue reading
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
An organization that adopts LeSS (Large-Scale Scrum) does not need portfolio management in the form we usually know it. Organizational descaling that comes along with LeSS removes the need for project, program and portfolio management.
Let’s explore in detail how that works.
So, I got this question about what kind of principles did we follow when introducing this thing called DevOps. I have destilled the principles here.
They are somewhat based / inspired by a Gavin Davies blogpost.
Do you remember those 12 Agile principles written a loooong time ago? Well, the whole Agile thing is kind of based on them.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- 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.
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
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