As of 2023, companies hire job titles such as “full stack” web developer, mobile application developer, data scientist, UI/UX (user interface, user experience) designer, database designer, DevOps engineer, business analyst, and a similar array of managers for these functions. People spend years becoming experts in these areas. I can still remember how insulted I felt as a young server-side developer the first time a manager asked me to do a client-side development task

Let’s call the application of previously-learned knowledge and skills routine expertise.

I hope I am not the first to tell you that machines are rapidly gaining the ability to apply routine expertise. Routine expertise will be (or has already been) automated by generative AI and Language Learning Models. Job titles like the ones I listed above will be obsolete in 3-5 years. They will continue to exist in uncompetitive organizations.

What can’t machines do?

Training ChatGPT is energy and computationally intensive, plus the human effort required. For now, humans are better at learning and adapting than machines are.

A human may be more able to defy convention. For instance, while a language model might suggest UI/UX designs based on historical data, a human might invent a novel solution that breaks conventions.

For that matter, conventional wisdom is sometimes wrong or limiting, requiring the insight of a nonconformist human. And the trainers themselves have biases. If ChatGPT had been trained on the prevailing orthodoxy of Copernicus’s day, it would have said that the Earth was the center of the universe.

We’ll call all this learning expertise to distinguish it from routine expertise.

What does GLAD stand for?

Craig Larman has proposed the acronym GLAD to stand for Generative AI LLM (Language Learning Model) Assisted Development. (I guess GAILLMAD contains more capital letters than he can stand.) Craig describes himself as a junior GLAD developer.

What will work look like in the future ?

From The New New Product Development Game by Takeuchi and Nonaka (1986):

Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.

With a focus on learning expertise, a small team of product developers will move from problem to problem much faster than your lumbering overstaffed departments do it today. In LeSS we have always emphasized multi-learning to eliminate queuing and handoffs. Soon the economics of this will be unavoidable. A team that’s serious about learning will also try mob programming.

Organizational designs (structures and policies) will have to be simplified to adapt to more complex work.

Will these super-teams do 15 minute daily meetings and estimate work in Fibonacci numbers?
I hope not! But the spirit of Scrum described by Takeuchi and Nonaka will live on.

Please view Craig Larman’s lecture on this topic below.

There’s a reason I stopped calling myself an Agile Coach years ago.

What is Organizational Design Consulting?

To quote Craig Larman:

what am suggesting is NOT a “method” or “process” or “way of working”. rather, this is about org design – the remit of senior mgmt – to be consistent with Adaptiveness (low switching cost (low cost of change), low transaction cost) in the service of learning/discovering what is most high-impact in your product, through an org design with strong feedback loops and a culture of intellectual humility and the scientific method applied to product discovery, rather than through speculation and “we know” and “delivering predefined projects.”

We want to help people discover principles of organizational design, (the organization’s policies and structure), and how to optimize that organizational design for adaptiveness. Does our organizational design promote out-learning our competition about our customer’s needs? Does it allow us to constantly adjust our direction? Everything else flows from that. Failing to address organizational design means the impact of an Agile Coach will be temporary and superficial.

This is rarely what a company expects – or gets – when it hires an Agile Coach. More often than not, management and the Agile Coach are playing a game Eric Berne² would call “Look How Hard We Tried.” Agile Coaches push processes and ways of working on teams while trying to “change management culture.” Upper management, middle management, and workers rarely share the same system optimization goal. And who needs a clear system optimization goal when Agile has been sold as something to just make everything better? (Spoiler alert: It doesn’t make everything better.)

What is Coaching?

A respectable coach named George writes:

That doesn’t sound like coaching to me.

Indeed. “Agile Coaching” is not coaching as we learn from Gerry Weinberg, Edgar H. Schein, or Roger Schwarz. Pure coaching is a legitimate profession with no agenda. Tacking on “Agile” corrupts it with an agenda.

What To Do Instead?

Hi Michael - Your post caught my eye since I’ve been wrestling with the challenge of how to improve the agile operations of a couple of our teams. They’ve had a hard time adopting best practices, so my thoughts went to agile coaching. I took a course with you a number of years ago and got a ton out of it, so I value your opinion. If agile coaching is a fool’s errand, what would you suggest?

I would suggest starting with a clear system optimization goal stated again and again from upper management, including what attachments we’re willing to let go of. Also we usually need to broaden the product definition. If these things are done properly, it will imply an organizational design and the desire to learn practices that suit your situation. Practices that are consistent with a system optimization goal of broad adaptiveness include things like Test Driven Development, continuous integration, and mob programming. But calling those things “best practices” does not promote worker ownership of their own methods and tools, or any understanding of why we should learn them.

Unfortunately these gaps often get filled in with things that reduce agility, see Things Ken Schwaber Intentionally Omits From Scrum.

Here are some things beyond Scrum that can increase agility:

• Test Driven Development (TDD)
• mob programming
• Continuous Integration
• Lean Startup

Try Test Driven Development

Try Mob Programming

Remote Mob Programming

Working remotely? Try remote mob programming

In an outsourced Scrum project how can we know the end-product is of the same value of what was originally promised by the contractor (noting the features might be different due to re-prioritisation of the Product Backlog) ?

The track record of outsourced software development is so bad that I would nearly always bet against getting the expected value and acceptable total cost of ownership (TCO) in the long run.

Are they really doing TDD?

Your vendors may cite their Scrum certifications as evidence they are Agile. If they are not doing Test Driven Development (TDD) (or something similar) the code will not be maintainable. How do you know the effectiveness of their technical practices if you’re not doing it with them? By now you know the tools that try to measure test coverage and code quality are easily gamed.

You lose the knowledge

Also, please understand that software development is knowledge-creation work. The value produced is the knowledge, not just the ones and zeros the vendor delivers. Outsourcing leaves valuable knowledge with the vendor instead of with your agency.

Expensive, late, and defective results

Over the years I’ve seen the outsourcing of software development attempted with various federal, state, and local government agencies. It nearly always made me cringe. It is not just that the long-term costs are so much higher than an agile approach would be. It isn’t just that it’s slow. Perhaps worst of all, the solutions have more defects than you’ll be able to find in time.

Try this instead

The only time I’ve seen this work reasonably well was when we mixed the vendor contractors in with the government employees on the same teams at the government location. This brought its own problems, but was still better than the typical project-based approach. See also FBI Sentinel, where the FBI finally got results by bringing a much smaller team right into the building, working with them directly each day. Small and skillful – connected directly to the customers and users – beats huge and clueless every time.

If you have no other choice but to use outside contractors, please at least read the Agile Contracts Primer to learn more sensible ways of doing it.

A frequent question is whether Scrum should be used for “infrastructure projects.” Then they get vague when I ask for specific examples. We’ve already talked about how the “project” construct can be harmful.

basvodde:

@mj Yeah, I’ve covered that question in two ways, which seems to make people satisfied: Define infrastructure as two things (a) putting computers on desks and put cables in new offices, (b) supporting product development.

Then for (a) I say there is probably no Scrum.

For (b) I suggest that DevOps ideas might work, then define DevOps as having three meanings/stages:

1. Use Dev practices in Ops (increase automation in Ops).
2. Have some Ops people join Dev teams.
3. Merge Dev and Ops, no more ops/infrastructure group.

It is vague enough for me to be comfortable with. It is specific enough for them to be satisfied with.

• Scrum is intended to highlight every deficiency and impediment the enterprise has so the enterprise can fix them.
• When an enterprise modifies or only partially implements Scrum, it is usually hiding or obscuring one or more dysfunctionalities that restrict its competence in product development and management.
• The gap between current practices and target practices is a measure of incompetence and competitive risk.
• Change is difficult, fraught with conflict, and may take many years of sustained effort. Turnover of staff and management can be expected.

Ken Schwaber counseled us not to sell Scrum as a silver bullet. To my recollection Ken did not use words like “hyperproductivity.” That was someone else.

But there’s a tiny market for difficult change and a huge market for prescriptions and placebos. So here we are.

Some of us are still interested in the honest work that the Scrum movement once embodied. Join us at https://fansofless.com.

What does it matter? It’s not like the Scrum cops will throw you in jail. But people do things unintentionally – mindlessly – because they got the impression they were essential to Scrum. For each one, please think about what problem it is meant to solve and whether there are solutions more consistent with your system optimization goal.

Scrum intentionally does not contain the following:

• daily status meeting
• velocity
• Story Points, Fibonacci numbers
• Product Owner assigning work
• Scrum of Scrums
• multiple Product Owners per product (e.g. one per team)
• tasks in the Product Backlog
• extra roles such as Chief Product Owner and Release Train Engineer
• burndown chart as a management report, or at all
• Scrum Master as coordinator, motivator, or status reporter
• Sprint Backlog as a surveillance tool
• single-function teams

Scrum was intended to be a framework, a meta-process, to connect feedback loops and give teams control over their own work. What you’ve experienced as Scrum in your workplace has likely diverged far from those intentions.

For things that are consistent with Scrum and usually necessary for it to work, see Potentially Useful Things To Add To Scrum.

Scrum Does Not Contain A Daily Status Meeting

Schwaber writes

The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work.

Do I need to say anything more? Companies that don’t treat the Daily Scrum as event for team self organization and re-planning are likely to call it a “stand up” for people to give status reports.

Scrum Does Not Contain “Velocity”

Schwaber’s definition of Scrum has never contained “velocity.” It is a practice sometimes borrowed from Extreme Programming. But even the Extreme Programming people who came up with the idea now have regrets. Should you keep doing it? I’d rather you focused on keeping your product shippable all the time. Focusing on velocity is a local optimization that can be bad for business outcomes. See Why I Barely Mention Velocity Anymore.

Scrum Does Not Contain Story Points and Fibonacci numbers

Scrum does not contain any particular effort estimation scheme. Scrum does not force (or prohibit) the use of story points. The Scrum Guide barely mentions estimation at all.

Ron Jeffries, co-inventor of story points and “velocity,” had this to say:

beware of using story points. they turn out to have been a bloody mistake.

Yes, there’s a strong case for relative exponential estimates over absolute estimates. Do you really need a vast array of Fibonacci numbers? You’re doing this because someone told you Fibonacci numbers have magical powers?

People who know binary find T-shirt sizes with simple powers of two to be sufficient. Other teams are fine with even less: small or let’s slice it until it is small. If you’re using more than a few choices, you’re probably just creating the pretense of precision.

Effort estimates and Sprint Planning

Scrum does not require a team to link Product Backlog Item estimation to Sprint Planning. Ultimately it’s their responsibility to choose what to attempt in a Sprint, as shown below.

Product Owner Cannot Assign Work

During Sprint Planning:

Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint.

It follows that a self-managing team would be responsible for maintaining code quality, test quality, and continuous learning. This benefits everyone, especially a Product Owner who plans to be around longer than a few months.

Principle #8:

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

Scrum Does Not Contain “Scrum of Scrums”

The first Scrum book in 2001 did contain a “Scrum of Scrums” – a hasty stab at the problem that no one knew how to make multi-team organizations agile. But Ken Schwaber’s next book, in 2004, identified the ways it contradicted team self organization. Maybe it meets your current needs, but don’t get stuck thinking it’s the only way. There are alternatives to Scrum of Scrums.

Scrum Does Not Have Multiple Product Owners Per Product

Per the Definition of Scrum

If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

Why is it harmful to have multiple POs per product (e.g. a different one for each team)? See my comic book.

I’m aware of two frameworks that offer specific guidance on how multiple teams share a Product Owner and Product Backlog: Nexus and LeSS. I also know of two other frameworks without clear system optimization goals, thus in practice are about preserving the status quo.

What is a “product” anyway? If we are optimizing for the big picture, consider using the broadest practical definition of product.

Scrum Does Not Have Tasks In The Product Backlog

One clue that someone hasn’t yet gotten the point of Scrum is that they refer to “tasks” in the Product Backlog.

Scrum has historically separated the what from the how. How to solve problems is left to self-managing cross-functional teams. If you cannot do this, you do not yet have self-managing cross-functional teams. Thus, the items in the Product Backlog are properly called Product Backlog Items (or PBIs), not “tasks.”

We’ll give you a pass if you refer to Product Backlog Items as “User Stories,” but we want you to remember this is actually an Extreme Programming concept that many Scrum teams borrow. How to create well-formed Product Backlog Items is covered in detail in the Scrum Training Series.

A team may decide to create Sprint Tasks when planning a Sprint – again covered by the Scrum Training Series. We try to defer how decisions until the last responsible moment.

Scrum Does Not Contain Extra Roles

Since a product has only one Product Owner, there is no “Chief Product Owner”.

There is no “Release Train Engineer.” Are there ways to solve the problems this role was meant to solve that increase adaptivenesss rather than reducing it? Giving responsibilities to named roles takes them away from teams, making teams less cross-functional and less self-managing.

Organizations often try to solve problems by adding organizational complexity in the form of additional roles, structures, departments, processes, etc. All of these quick fixes can have harmful side effects, leading to hidebound organizations. We believe in reducing organizational complexity and solving the underlying problems.

Scrum Does Not Contain Burndown Charts

While the first Scrum book in 2001 did recommend burndown charts, it was quickly discovered that they could lead to a decrease in team self management through excess focus on estimates and short-term efficiencies. Complex work doesn’t necessarily follow Newton’s Laws Of Motion. So they’ve been out of Scrum’s definition for years. Use them if you want, and understand why they’re no longer prescribed in Scrum.

Scrum Masters Are Not For Coordination, Motivation, or Status Reporting

The Scrum Master was not intended to be a renamed project manager.

coordination

The Scrum Master is there to teach the team that coordination is a team responsibility. Doing it for them teaches them the opposite.

motivation

If people are not motivated, it’s likely there are organizational impediments the Scrum Master should be working to address. In healthy organizations the motivation comes from doing great work and seeing how it helps people. (You still have to pay us to get us in the door.)

status reporting

The authors of the Agile Manifesto wrote that working software is the primary measure of progress. Scrum emphasizes the empirical over the theoretical. At the Sprint Review everyone sees the real product itself, not a report about it.

I still have Ken’s slide that said “The Scrum Master has no authority.” For more about Scrum Master responsibilities, please see the Example Scrum Master’s Checklist.

The Sprint Backlog Is For the Team (Developers), Not For Surveillance

From the definition:

The Sprint Backlog is a plan by and for the Developers.

I once heard a Microsoft employee ask Ken Schwaber why the team’s self management artifacts shouldn’t be published to the whole organization. “Transparency” right? Ken restated that the team is meant to be self organizing, and said he would want to find out why people who aren’t on the team would want to meddle with them during a Sprint.

The Sprint Review is an appropriate time to make the results of the work visible to everyone outside the team(s). They are invited to give feedback at that time. The Product Owner will decide how to adapt future plans to the feedback.

During the Sprint Review:

the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities.

Scrum Does Not Contain Single-Function Teams

From the 1986 Harvard Business Review paper that inspired Scrum¹ through today’s Scrum Guide, the magic is the result of cross-functional teams. In 1986 Hirotaka Takeuchi and Ikujiro Nonaka wrote:

Under the old approach, a product development process moved like a relay race, with one group of functional specialists passing the baton to the next group. Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.

The opposite of a cross-functional team is a single-function team. Single-function teams abound in most organizations:

• teams that just do analysis work, writing detailed requirements, etc.
• teams that mostly code but don’t fully test
• teams that only test
• integration teams
• fake “DevOps” teams (real DevOps is the opposite)
• product (management) teams
• UX/UI teams
• support teams (that sometimes become control departments)
• marketing teams
• architecture teams
• risk management teams
• infosec teams
• maintenance teams
• operations teams
• firefighting teams
• etc.

Not everything in the world has to be called “Scrum.” The existence of single-function teams or departments isn’t necessarily harmful. Humans got work done for thousands of years before there was anything called Scrum. Some types of work (especially with physical dependencies) may require a sequential approach. Even Ken Schwaber wrote:

If waterfall meets current needs, keep doing it.

But it is a contradiction to call single-function teams (or departments) “Scrum” teams. Is there an honest reason to use Scrum words for things that aren’t Scrum? George Orwell wrote:

If thought corrupts language, language can also corrupt thought.

Abusing our language prevents the discovery of what Scrum actually is.

How to become a rich methodologist

A person who was called “Product Owner”² of a single-function team told me I could make a lot of money by inventing a methodology to accommodate teams like hers. Did she think Ken Schwaber, Takeuchi-さん, and Nonaka-さん were unaware of the existence of single-function teams? Scrum was meant to expose dysfunction, not mask it.

Around the year 2000 people made a lot of money with something called the Rational Unified Process (the RUP) that could be “tailored” to require no change at all to your traditional organizational design. It was a disaster, of course. Alistair Cockburn (a coauthor of the Agile Manifesto) clearly wasn’t a fan:

I am interested in fending off the fat methodology army, the vast quantity of RUP, [Arthur] Anderson [now Accenture], SEI [Software Engineering Institute] salespeople putting ideas into CIOs’ minds that they should have lots of paperwork to be “safe”.

One of the people responsible for the RUP fiasco repackaged it into a monstrous, fundamentally dishonest thing called SAFe. Fool me once, shame on you. Fool me twice, shame on me.

About “Thought Leaders”

• Q (from a LinkedIn user):

  many of the patterns mentioned in [this] article have been championed by Jeff Sutherland and other thought leaders.

• A:

  Now you can be smarter than a “thought leader.”

“Scrum!” You keep using that word …

Japanese version: ケン・シュエーバーが意図的にスクラムから排除したもの

Increase an organization’s ability to respond to change.

Craig Larman clarifies¹:

the organizational design from LeSS is consistent with broad adaptiveness, but… suggest we coach that adaptiveness is not for its own sake. rather, adaptiveness is in the service of something else: learning towards the discovery and delivery of high value or high impact, in the context of a world in which it’s usually difficult to a priori know for sure what is high value/impact, and a world in which competition does stuff, new technologies emerge, new trends emerge, etc.

for a product group to demonstrate skillful adaptiveness – changing to some unanticipated direction – 2 key elements:

1. the ability to change direction cheaply and quickly. poetically i call this “turn on a dime, for dime.”
2. the information to change direction

both (1) ability to change, via low transaction and switching costs, and (2) information to change, are needed to realize adaptiveness

So, less succinctly:

Increase an organization’s ability to discover and deliver the highest value to end users in a world where we don’t know everything, and everything’s changing.

I don’t see any consistent system optimization goal in SAFe, Scrum@Scale, the “Spotify model” and the way some people explain basic Scrum.

Why not just “Make Everything Better”?

Better in some ways is worse in others. For example, the goal of increased customer satisfaction could be inconsistent with increased stock price this quarter. Or another example, I heard a project manager turned Scrum trainer say “In my experience, Scrum of Scrums works great!” And I can see how that could be true, if we’re optimizing for the sort of problems project managers are usually asked to solve. But if we’re doing Scrum to increase agility, we’ll want to consider some more agile alternatives.

What happens without a system optimization goal?

Example A:

I spent a little some time with a company which I initially thought was a perfect candidate for an Agile adoption, a slam dunk. They had less than 100 people in the company, all co-located on the same floor of their hip, modern office. Their management initially seemed quite gung ho. But as the discussions progressed, it became more clear that this management did not want to untangle the byzantine organizational structure and the overspecialization they had built up over the past 20 years, didn’t think people could learn new skills, and really felt it was best to micromanage employees.

When the company attempted an Overall Retrospective, their actions were to increase the organizational complexity that was at the root of their problems! Local optimization bias is so powerful that doing retrospectives blindly can actually make things worse if we are not clear about our optimization goal.

If management cannot express a clear optimization goal and act consistently with it, perhaps we’re dealing with too low a level of management.

Example B:

At another similarly-sized company I worked with, the CEO himself came to our mob programming training sessions to see the company’s code for himself, and suggest ways of adding automated tests. (This is similar to Ahmad Fahmy’s Gemba Sprint) This sent everyone a clear message that it’s often appropriate to stop and fix, rather than continuing to add bugs by churning out crap code.

What’s the right system optimization goal?

Example C:

I worked with a multi-team product development group that was living in hot-fix hell. Developing new features was impossible because so much energy was spent on fixing and supporting previous releases. Their releases were often so buggy that customers declined to take them, further increasing the support effort as they tried to hot fix multiple versions. To escape the situation, teams had to increase their focus on writing automated tests, increase their focus on reducing code duplication, and increase their focus on collaborating with other teams. But this was inconsistent with what they’d been supervised to do in the past – typing lots of crap code – and initially there were complaints that Scrum was “reducing productivity.” Fortunately senior management made it clear that the old kind of micro-efficiency and their old ideas about what “productivity” meant were not the reasons for the change initiative.

Eventually the effort paid off, they started getting solid builds, and they were able to release solid products. And then they stopped changing their organization! I was initially disappointed because I saw additional changes they could have made to become more adaptive to customer needs (aka. Agile). But they were so pleased their releases no longer sucked that they didn’t have an appetite for the additional changes that would have increased their agility.

While the focus of LeSS is increased adaptiveness/Agility, not just releases that don’t suck, the latter is still consistent with adaptiveness and with LeSS’s guidance. You can’t adapt to changing customer needs if you’re drowning in hot fixes.

The experience taught me to be less attached to my idea of what an organization’s system optimization goal should be. There isn’t a “right” one. At the same time I’ve come to believe that senior management should

1. carefully consider what the goal is,
2. express it clearly to everyone, and also
3. express what attachments we’re willing to let go of, particularly the difficult ones.

When are goals context sensitive?

People sometimes seek predictability. On one hand Scrum tries to make some things as predictable as possible, such as having a shippable product every couple weeks. We want to eliminate unnecessary unpredictability. But let’s do this to increase our ability to cope with necessary unpredictability such as our evolving understanding of the requirements, learning new technologies, etc.

Does the change initiative have consistent optimization goals?

Here’s a list of other optimization goals² that may exist in your organization. They may be explicit or implicit. Some may be consistent with each other in your situation, and others may not:

• increased release frequency
• fewer defects in each release
• predictability
• comfort
• order
• clarity about who does what
• resource utilization (keeping people busy)
• ideation (creating ideas, as IDEO and Xerox PARC were famous for)
• maximum individual team output or tickets closed per Sprint
• secrecy³
• employee satisfaction/retention (when using this list in a system modeling exercise, break this variable down into different categories of employees: coders, line managers, department heads, etc.)
• customer satisfaction
• parent company satisfaction
• the feeling of making progress
• appearance that the change initiative has succeeded
• top-line revenue
• maintaining lead or monopoly
• cost per developer
• size of organizational substructure (e.g. department, reporting chain)
• product versatility
• broaden/diversify customer base
• preservation of status quo
• compliance with rules/regulations
• leading/disrupting the market
• return on investment
• conformance to a plan
• rate of developing features immediately (this week’s velocity)
• rate of developing features within this quarter (this quarter’s velocity)
• rate of developing features next year (next year’s velocity)

You may know that I helped Manoj Vadakkan establish Fans of LeSS, our attempt to un-hijack Scrum and Agile. But just as Ken Schwaber used to explain that adopting Scrum will be difficult, I want you to know that adopting LeSS will be difficult.

A developer named Marcell Lipp wrote about his personal experience with a company adopting LeSS, after working there for two months. His article describes a little bit about LeSS, it’s advantages, etc. This article caught my eye because he described several disadvantages from the perspective of a programmer after a couple months. I encourage you to read the whole thing.

• https://howtosurviveasaprogrammer.blogspot.com/2019/04/first-experiences-with-large-scaled.html

Marcell also wrote followup articles after six more months of experience:

Some of my feelings changed, some of them are still the same.

• https://howtosurviveasaprogrammer.blogspot.com/2019/10/experiences-with-large-scaled-scrum.html
• https://howtosurviveasaprogrammer.blogspot.com/2019/10/experiences-with-large-scaled-scrum_10.html

I don’t want you to think that these negative aspects are inevitable, unsolvable, or even the same one’s you’ll experience. For each one, you should be able to imagine mitigation approaches that reduce organizational agility, and ways that are compatible with agility.

Disadvantages Distilled from Marcell’s article

1. But in the end no one is really feeling himself responsible for holding the due dates.
2. [But in the end no one is really feeling responsible for] solving problems.
3. [But in the end no one is really feeling responsible for] making technical decisions.
4. Really often we are just talking hours long about alternative solutions and no one is there to finalize the decisions, so we are just talking and talking and not making a clear decision.
5. I’m also lacking the career opportunities: in classical working structures there are hundreds of roles which can be overtaken and which are making some changes, some step further into the career, here I can not see much of them. [From Marcell’s followup article]: Furthermore in case of classical working mode your manager is usually also helping you to find the right direction for you. In this structure you are totally alone to figure it out. And it is fine on short term, but a lot of developers are losing their motivation on long term.
6. I’m also lacking the feeling that I can tell: “it is my code”. Maybe it’s childish, but that’s what I feel.
7. I also have issues with the communications: there are so many communication channels, that it is really difficult for me to collect all the relevant information.
8. I also have the feeling that the project is really lacking someone who has a good technical overview on the whole project, like a software architect. When we need to use an interface really often no one can tell us which interface is it and a lot of interface are duplicated.
9. Last but not least I would like to mention that the permanent pair and mob programming is really exhausting. It is really difficult. The team members needs very good social skills and a lot of patience, which is not typical for most of the programmers.