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.
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