How about Portfolio Management?

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.

There are two common kinds of Portfolio Management: project and product.

Project portfolio

It is by far the most common form. Project portfolio management is a continuous process of decision making when to start / stop a project, and budget / people to assign.
Project portfolio is based on idea that you have many projects and you need to manage them. Idea is that Project portfolio is useful since projects tend to become expensive and miss deadlines. It is a way to somehow gain control of projects, whether they are waterfall or so called Agile.

The reasoning behind the need is based on centralized decision making, otherwise everyone starts projects without any control. Once people are assigned to a project, they shouldn’t be reassigned to something else. Top-level management knows what is best for company, therefore everyone becomes restrained by projects. The only place where decisions are revised is Project Portfolio workshops.

So, what are the problems in this way of working:

  • Everything in project portfolio management is about projects. Many dysfunctions related to projects become even bigger:
  • The goal is to finish as many projects as possible. Value creation is only implicitly part of portfolio management process.
  • Emphasis on managing projects tends to create two separate realities: One of actual value created and effectiveness, and other is concerned with project budgets, resources, when to start or stop one. Successful project is one that is finished on time and within budget, regardless of value / risk created. In other words, the focus is on “work”, and not the actual “thing” (product) that provides direct value.
  • Trying to fix a fundamentally broken system of complex project management by better management from outside of the system, without actually doing something about the system itself.
  • Tightening the control drives people to become ever more creative in gaming the system. E.g. fake project reporting that is just good enough to keep management happy, and still keep things going with longer deadlines / more budget.

From big to smaller projects

Big, long and costly projects are a bad idea. Nowadays, everyone seem to agree on this. Therefore, some would say, inspired by agile development, we should have many small projects and manage those in so called “agile portfolio management”.

When looking closely, we see tremendous number of projects and they get finished maybe faster. There are so many of them that people are assigned to multiple projects at the same time. In fact, many of these projects when finished, don’t produce any value yet. In order to produce actual value, concept of “program” is introduced. Each of the projects has a project manager, a program has a program manager, there is PMO office, etc. I think I would rather have long and costly projects🙂.

A deeper and less visible problem described in the new LeSS book that will be published soon is the problem of big-batch requirements prioritization. This results in big upfront prioritization and planning related to work for each product. Therefore, although we seem to have removed the problem of big-batch prioritization of a large project, it is largely replaced by complex portfolio management.

Move people faster from project to project

Another form of so called “agile portfolio management” is where teams potentially work every iteration on a different project. This is even worse than small projects approach. Why? Not only there is no focus for people, there is also misunderstanding what iterative and incremental development means. Business agility is NOT the ability to move people or teams around as pleased.

In some cases, “agile portfolio management” is explained as a way to assign people instead of teams to work. It means that individuals work one iteration with one group of people, and next one with a totally new group. This results in very wasteful tracking, reporting and task-switching and complete disregard of human need to belong to a stable and safe group, a team.

The project portfolio management is trying to solve a problem by fiercely treating the symptoms, and sometimes making whole situation only worse. It is focussing on the process for managing work, and not work itself.

How does LeSS deals with Project Portfolio Management?

In LeSS, there is one Product Backlog per product, managed by one Product Owner regardless of size. LeSS organization does not need projects in order to deliver a product in iterative and incremental manner. Teams are stable and receive all work from Product Owner. This work is for the benefit of a single product and all teams have whole product focus.

Work regarded as portfolio management, such as choosing what to do and what not to do, is part of Product Backlog prioritization.

Therefore, if there are no projects, then there is no need for Project Portfolio Management.

But, what about delivery of multiple products in combination as part of a program?

In such case, the product is incorrectly defined. If there is a big dependency between parts we wrongfully call “products”, then those parts together would be a better definition of a product.

What if one product suddenly becomes much less important?

Since a product is broadly defined, we are talking about a big shift in organization’s strategy. Even huge enterprises have limited number of products as perceived by customers. Nevertheless, teams could be moved from one to another product. This is something teams are not likely to experience often.
Organization that encounters such problem has already achieved rather high level of business agility. It is a luxury problem.

Product portfolio

Product-based portfolio is almost a completely different story. Although both are called portfolio management, there is little similarity between the two.
As mentioned before, an organization has at best a handful of products. Managing this portfolio is part of strategic planning. It is less complex and intrusive into product delivery than Project Portfolio management. The main participants are Product Owners together with management concerned with strategy. Each Product Owner will explain own Product Backlog, share the vision and target for next few sprints. The outcome of this workshop is re-alignment with company strategy with possible changes in Product Backlogs.

The focus is also on measuring value created. Every Product Owner uses own or shared business value model for assessment. When strategy changes, so does the value model. Value model is a concrete representation of strategy, used to assess product achievements and product backlog.
E.g. “How many active customers do we have with this product?”. Number of active customers is a value model, and this aspect might become more, less or not relevant in time.

In turn, this information drives decision making for not only product backlog, but possibly also how many teams should be involved in product delivery.

Teams will typically not notice much since they are already accustomed to continuously changing Product Backlog regardless of the reason why it changed.

We are running so many projects and programs, how can we ever switch to this model?

Start refocusing towards product delivery and value creation. Don’t accept to have this only at the end of a project / program. Value those more than encompassing projects. I’ve noticed that once customer keeps getting value, management starts to transform this limited project or program into one which runs longer and has more budget. And this is great! Who cares if a project is not within time and budget anyway?🙂

The next step is that people speak less and less about project / program stuff. There is less or no need for project and program management anymore. LeSS adoption will naturally drive this process.

DevOps principles

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.


Whole Product Focus

  • Customer is interested in continuous value (less of negative one – issues, and more of positive one – features), not development vs. support
  • Product is finished when it is retired from production

No Silos

  • Team that delivers customer value has capability for development and support
  • Cross-functional and cross-component team owns the product and has full responsibility for everything related to the product
  • Team defines and continuously improves working agreements regarding development vs. operations

Automated feedback

  • Before production – highest quality and early discovery of problems
  • In production – built for fast analysis, resolution and low impact (not roll-back)
  • Development in service of operations (built for easy operations), operations in service of development (root cause data to solve and prevent repetition)

Perfection goals

  • Product runs itself, doesn’t require support
  • Deployment is instant
  • All issues discovered and solved before production
  • Every team member does both operations and development

Happy to hear any feedback.

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_compromisesThere is usually an implicit assumption that above principles do not scale when tried to be implemented in a large project / organisation. What I mean with “scale” is multiple teams working together to deliver a product within a large (complex) organization.

A friend of mine participated a SAFe training where trainer tried to teach him that many of the Agile principles cannot be scaled. The reasoning behind such teaching is that since they don’t scale, complex organisations need a complex framework such as SAFe. In other words, SAFe explicitly brakes with many of the above principles in order to accommodate the needs of existing organisational complexity.

Just to provide one example among many. About principle 12, this is a quote from SAFe website:

As Agile practices matured and became adopted by larger teams and teams of teams, however, there comes a point at which emergent design is an insufficient response to the complexity of large-scale system development. Simply, it is not possible for teams to <summarized: deal with architecture>

Since the above principles are the best reference we currently have what Agile development means, we should ask ourselves if SAFe can be called Agile.

How do principles work in a scaled context?

Since answering this question could lead to a whole book, and not a blog post, I will provide only clues and references. A very short answer is Large-Scale Scrum (LeSS) which deals directly with organisational change required to make above principles a reality. Nexus framework has a similar approach, although it deals with organisational change implicitly through explanation how teams work together.

So, the 12 principles definitely scale, therefore stating otherwise is at best an opinion. One I disagree with.

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.

These strongly relate to frequent feedback loops directly between customer and teams that deliver software. Also, early and continuous delivery translates into making sure that lead time is weeks or shorter, and not 3+ months. Therefore, having translators between teams and customer, gatekeepers, approvals, management layers, silos / functional departments (Architecture, BA, Dev, QA, Operations, etc.) is not an effective organisational form. This requires restructuring into cross-functional teams that are capable of delivering features autonomously in order to achieve continuous delivery and capability of any team member to talk to customer directly, and inspect and adapt. In other words, it requires organizational descaling, reduced complexity where self-managing, cross-functional, long-lived team is the basic building block.

Business people and developers must work together daily throughout the project.

A large organisation that applies this principle will distinguish between decision making on priority and who talks to who, since a major worry in a corporate world is a mess if the collaboration between many teams and business is not “controlled”. The applied framework and/or practices should encourage people to work as closely as possible, while prioritization (what shall teams deliver and spend money on?) is centralised in form of a product owner, which has to come from business.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This principle requires Theory Y way of thinking, where management changes behaviour, where people who collaborate and deliver value are placed at the center. The processes, roles, and responsibilities become secondary. This implies reduction of roles and complex so-called supportive structures such as PMO, program and project management. Different way of dealing with portfolios and budgeting (e.g. Beyond Budgeting), work is assigned to stable long-lived teams and not resources assigned temporarily to a project or program.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Obviously! Nevertheless, large organizations have often resourcing model (available people are assigned to a project), and not teams model. This produces so called teams that are dispersed, sometimes over multiple continents. Face-to-face conversations over internet is at best very cumbersome, especially with timezone differences. A large organisation needs to switch from this resourcing model to stable long-lived colocated teams model. Also major projects are assigned to already existing teams, and not anymore other way around (resources found and assigned to this large project).

Working software is the primary measure of progress.

This principle is probably one of the most compromised of all. “What does ‘working’ even mean anyway?”. Well, it means going “all the way”. Working means it works in the hands of a user and / or produces actual value for the customer. A product that is so called “finished” by a team, but still needs to go through e.g. final testing or integration with some other product is not “working”. If we compromise with this, then basically any piece of software can be called working.

Therefore, development teams that deliver their stuff (e.g. a component or not completely tested product) is secondary to a really working product. In order to embrace and implement this, a large organisation requires system thinking. Seeing the whole, the end result is the primary focus. Continuously improved Definition of Done is a powerful tool in this process.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

This one implies:

  • Long-lived teams instead of resource pools
  • Development stops only when product is no longer valuable.
  • Overall quality and operations are integral part of Agile development. It is otherwise not sustainable.

Continuous attention to technical excellence and good design enhances agility.

For large organisations this means a craftsmanship culture. One where career path includes continuously growing technical expertise. Where highly skilled developers are respected, valued, and paid accordingly. A culture where these teams with these highly educated people decide how much time is required to do things properly. Also a culture where to perform also means to learn a lot, learn what good design means, since software development is essentially a knowledge creation process.

Simplicity–the art of maximizing the amount of work not done–is essential.

This principle encompasses much more than what we often assume. It is  challenging to achieve this in large organisations. At the same time, reducing complexity in organization, requirements, development process and architecture results in one of the biggest waste reductions typically encountered. This requires lean and system thinking tools, lean startup practices. Also, feature teams (instead of component teams) that are at least much more capable of looking at combination of components in order for simplification to start to happen. A team that deals with a single component might see the problem, but it is not empowered to resolve it.

The best architectures, requirements, and designs emerge from self-organizing teams.

There is a tremendous amount of articles and blog posts related to tension and compromise between these two worlds. At the same time, there are also large companies that do embrace this principle and in the process have discovered nice practices. Many of them are explained on LeSS site, and none of them requires someone outside to define and deal with architecture:

  • Initial, overall, and per team Product Backlog refinement
  • Design workshops with whole team (not only tech leads or architects)
  • Multi-team design workshops for broader design issues
  • Architects and engineers are regular team members and write code
  • Tiger team
  • Design / architecture community
  • Component mentors
  • Product vision workshops (with everyone)
  • 1-hour decision making
  • Architectural concern wall
  • Spike
  • etc.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In case of multiple teams, representatives of teams have an Overall Retrospective together with ScrumMasters and managers. They discuss cross-team and system-wide aspects.


While many tell me that something is not possible, I prefer making things happen especially if they seem impossible. In this case, it is not even a question if it is possible or not. It happens already!

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?

I’m usually placed in the camp of religious-like zealotry. That is interesting, since I don’t believe in any religion. I do believe in proper arguments and evidence-based information. Therefore, above statements and accompanying explanation don’t provide any meaningful information.

Instead, it would be much more interesting to properly explain why certain aspects in Scrum do not work in certain contexts. We could all learn from that. I would be the first to embrace such improvement or alternative to Scrum. In such case, I still reserve my right to open-mindedly judge whether argumentation and evidence makes sense. The usual questions I would ask:

  • What is the actual result of your Scrum-but? Are you continuously improving, delivering really done high quality increment with useful features in few weeks or shorter to real users? What is the lead time (time from a request to usage by a user)?
  • Are you sure that the reason why Scrum is not working at your place has nothing to do with organisational dysfunctions?
  • If your Scrum-but is working very well, please define “working very well”.

These questions are NOT meant to defend Scrum, but to defend result of doing Scrum properly. In fact, this could be applied to other frameworks too, and therefore judge their value. Unfortunately, in all of the discussions and posts I have seen so far, either explanation or the actual results are lacking. It is interesting to observe that discussion is either stopped or sidetracked whenever actual results are questioned. A typical example is teams and coaches claiming to do Kanban with a lot of fancy columns on their Kanban boards:

How long is your maximum lead time? A: We don’t know exactly, but it is about 6 months and slowly improving.

How long is going to take before you get to 4 weeks or less? A: No idea.

I have nothing against Kanban, but I have everything against taking the easy road for the sake of calling yourself Agile, and somehow neglecting actual results in the process. I do have something against some other frameworks and methodologies which lack evidence of being useful and still use words as “proven” as if it actually means something.

Another pattern in these discussions is the argument of being practical. It is often said: “Our organisation is not yet capable of following Scrum in a proper way”. I think that probably no traditional organisation was judged as being capable of doing Scrum 15 years ago. Nevertheless, today many of them bare the fruits of this seemingly impossible goal. Despite this fact, today others still compromise a lot with minor or no actual improvement as a result.

One can only be named dogmatic if one is not open to possible improvements. Embracing Scrum framework in most situations, simply because it provides tremendous improvements relatively fast, has nothing to do with being dogmatic. Also, sticking to rules has to do with evidence-based strong correlation between lack of actual results and compromising with already simple rules.

For me, “our Agile implementation is working just as fine” is a meaningless statement. Is your organisation achieving something great (and what is it?) or just being mediocre as always?

So, I’m fine with being called dogmatic, religious-zealot or sometimes completely opposite of both, but let’s get over that and talk about real achievements unless you are ok with mediocre. I’m not.

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.