NOOP.NL

In Defense of Scrum (Please Stop Pissing on It)

Last week Uncle Bob Martin wrote about seven “serious flaws” in Scrum. I usually agree with Bob, but not this time. Actually, I might even feel a bit sad about all the <method>-bashing I see happening in the Agile world, where all too often <method> = Scrum and the bashing comes from either the XP side or the Kanban side.

Here’s my take on the matter…

“Scrum has no technical practices”
The lack of technical practices in Scrum is a strength, not a flaw. It means Scrum can be (and has been) applied successfully not only in software development, but also in design, marketing, and several other creative domains. As far as I know Scrum has always been presented as a framework, meaning that it must be augmented with domain-specific practices. True, some software teams forget about the technical practices, and they are idiots! But is it a “flaw” of the script writer when the director forgets to use stunt doubles when filming the dangerous scenes? Or is that a failure of the craftsman who apparently doesn’t know how to do his job? If you call it a “flaw” that Scrum has no technical practices, then you can only conclude that Lean and Kanban are seriously flawed as well! Obviously this is a bit silly. To me this flawed reasoning seems like a bad case of tunnel vision. There’s more happening in the world than TDD, Continuous Integration, and Pair Programming. Really! (BTW, it is interesting to see praise on the Lean side for Bob's criticism of Scrum, while Lean and Kanban have no technical practices whatsoever! The few described in Lean books are simply copied from XP…)

“The Scrum Master arrogates project management powers”
Maybe, but it’s a risk worth taking. A much bigger problem I see with teams without a Scrum Master is that they are usually an undisciplined bunch of mandrills. XP requires and assumes that teams consist of self-disciplined, competent, and communicative people. Unfortunately, many software developers don’t fit this description. Scrum at least acknowledges that most teams need some help and assistance in getting their processes and communication in order. I find it particularly strange that people who call for craftsmanship on the technical side should point out the dangers of positioning a master on the process side! Honestly, I would rather run the risk of a Scrum Master taking up PM powers than a dev team completely ignoring their responsibilities. What is worse? (And yes, the sooner a team can do without a Scrum Master, the better. I don’t have one in my own team right now. For us there's no need.)

“Scrum provides insufficient guidance regarding the backlog”
See the first issue above. A backlog for graphic designers probably looks quite different from a backlog for developers. And marketers print their backlog horizontally and call it a road map. What’s wrong with keeping all the options open? Scrum is a framework, not a by-the-minute recipe!

“Scrum carries an anti-management undercurrent”
I don’t get it. How is that different from XP? Management has always been underrated in the Agile world. True, management has done badly before Agile. And we should be glad for the Agile movement and its self-organizing teams. But self-organization without governance is anarchy. This is not a flaw in Scrum, it is a flaw that began with the Agile Manifesto itself, which completely disregarded the role of management. And guess who co-wrote that? :-)

“Scrum doesn’t say anything about multiple teams”
True, and again: how is that different from XP, or any other agile methods? Allow me to quote John Gall here:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. – The Systems Bible, John Gall

Scrum is a small system. That’s why it works. It is specifically designed not to cover technical practices, complicated backlogs, multi-team projects, etc. They tried that with RUP, and they failed. Because a complex system designed from scratch won’t work. A big working system has to start as a small working system. This is not a flaw. It is common sense. And now that we know that (small) Scrum can work, we can learn how to make it grow...

And that's what I had to say in defense of Scrum. I really hope that people would stop pissing on it. No agile method is perfect. But I think there’s a world of difference between imperfect and "flawed".

Please note that I am not a CSM, and will never be one. I like XP and Kanban just as much as I like Scrum, because I believe no single model or framework is enough when managing complex systems. Anyone who favors one method and pisses on another is just showing off his ignorance of complexity thinking.

That's it. I hope to have entertained or annoyed you.

I will be speaking at the Scrum Gathering in Orlando. Hope to see you there!

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Management 3.0: The Era of Complexity ScrumButs Are the Best Part of Scrum The Complex Manifesto for Software Development

Scientific Case for Bottom-Up Rulemaking

In his book Hidden Order: How Adaptation Builds Complexity computer scientist and psychologist John Holland describes a generic pattern for rulemaking in complex adaptive systems (like businesses and software projects).

Performance System
The first part of the pattern is what Holland calls a performance system. It consists of a potentially large number of stimulus-response rules, where the rules are meant to act upon messages received from the environment (or from other rules). The result of applying those rules is that a number of new messages are emitted, either to follow-up rules, or to the external environment.

Being a software developer my mind is filled with plenty of rules for building software. The input that I receive from the environment consists of the things my colleagues are doing (or the things they are only saying they’re doing), the code that I am working on myself, the requirements from the customer, the features and restrictions of the development environment, etc. The many messages from the environment are evaluated, in parallel, using hundreds if not thousands of rules in my mind, both consciously and unconsciously, which results in one or more new actions, like code to be written, changes to existing code, conversations with my colleagues, or discussions with the customer.

I know, this all sounds pretty obvious. But the key concept here is that the performance system consists of many potentially conflicting rules, where different rules are triggered under different circumstances, given different messages from the environment. It is as if the performance system is an ecosystem of rules, where rules are both competing and collaborating with each other, and the “fittest” rules are the ones contributing most effectively to the whole complex adaptive system.

Credit Assignment
The second part of the pattern is called credit assignment. Rules that appear to lead to improved performance of the entire system are credited, which increases their strength within the performance system. Rules that were triggered and subsequently failed to deliver beneficial effects, or even appeared to hurt the total system, will see their strength reduced. The strength of each rule determines the chance of being triggered the next time, for similar input messages.

Credit assignment assures that experience is built up in the system, by strengthening some rules and weakening others. The rules together form an internal model of what the world outside looks like and how the system needs to respond to it. And when the environment changes, strong rules will start failing and weak ones could succeed more often than before. This enables the performance system to adapt to new situations, and to continuously correct and tune its internal model.

Rule Discovery
The last part of the pattern deals with rule discovery: where do the agents in a complex system (or software developers in a project) get their rules from? Holland describes how new rules can be constructed from existing rules by recombination of building blocks. This is essentially how DNA works: by recombination of existing genes and their alleles.

Holland was one of the first to create evolutionary models for rule-based decision-making, which earned him a reputation as the father of genetic algorithms. He not only convincingly described how these performance systems are an interesting conceptual model for complex adaptive systems, but he also showed that they can be implemented easily to create evolutionary algorithms with powerful problem-solving capabilities.

Why am I writing all this?

For one reason only: to help people understand that rule-making is something that must happen bottom-up. And not top-down.

Science proves it.

(image by Syntopia)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Management 3.0: The Era of Complexity Self-Organization vs. Emergence Self-Organization vs. Anarchy

Make A "Social Contract" With Your Team

I have told you how to define goals, rules and boundaries for the people in your organization, and hopefully your team is on a great and inspiring mission.

But what do your team members get in return?

Why should people subscribe to your vision? What’s in it for them? Only a salary?

Israel Gat described how he used the idea of a social contract to define the obligations that the manager feels he has towards his employees:

Team, my overarching organizational objective is to preserve our team and its institutional knowledge for our corporation and its customers for years to come. We will achieve this goal by enhancing our software engineering prowess to the level that the resultant benefits will outweigh the repercussions of the current financial crisis. […] Whether you will or will not be with the company in the future, I acknowledge your need to develop professionally as Agile practitioners and commit to invest in your education/training.

In this social contract Israel Gat described not only (part of) a mission, but also what he acknowledged to be his own responsibilities toward the team members. In this case it was investing in education to address their need to further develop themselves professionally.

Social contract theory is a philosophical concept describing how groups of people maintain social order by giving up some of their freedoms to an authority. It is an agreement by the governed on a set of rules by which they should be governed, and it usually applies to societies and their governments. But the idea translates quite well to organizations, even though the “governed” do not have the right to elect their “governors.” What is similar is that the contract lists the obligations of the authorities toward the people, and that everyone is automatically assumed to agree on the contract, or else they are free to leave. (Which, I am sad to add, can be a bit troublesome in the case of some countries.)

A social contract should address the basic necessities of people. In a society, they are not only things like food, shelter, and safety, but also freedom of speech, basic education, equality, and (if you’re fortunate enough to be born in a modern country) healthcare. In an organizational context we’re talking about similar things, like the freedom to voice your opinion, professional development, non-discrimination, and a little help when you’re not feeling well.

This brings us back to a topic I have frequently touched upon before, which is that management is all about people, and that it needs to acknowledge their basic intrinsic desires. A social contract is a simple but effective way of making this explicit for all involved.

(image by madmolecule)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Protect People Yes, Good Managers Are Manipulators People Don't Listen

Quality: You Don't Get What You Don't Measure

I am not a saint. There have been some awful quality problems in the products that I was directly or indirectly responsible for.

No, I was not responsible for accidentally sending that email to 1,000,000 people instead of just 10,000 registered users. And it was not me who messed up the home addresses of a few thousand on-line buyers so that their products could not be delivered. And I had nothing to do with the bug that allowed 9 out of 10 players in a lottery to win the main prize. But I will eagerly tell you about my own programming errors. If you show me yours, I’ll show you mine.

The problem with quality is that it is often simply assumed by everyone. This is exemplified by the well-known triangle of constraints, which lists all important constraints, except quality. Customers just assume they will get quality products, and managers assume that employees know how to build them. And, unfortunately, 80% of people actually believe that the quality of their work is above average. Obviously it isn’t.

Self-organization can solve many quality problems, as long as you put the right constraints in place. It is sometimes said that managers get what they measure. If you make it a point that products must be delivered to customers before their deadlines, then self-organizing teams will do exactly that. They will push (sometimes crappy) products out the door on the day of the deadline. If you make it a point that products have to be reliable, scalable, well-performing, and secure, self-organizing teams can build exactly that. They will deliver high-quality products many months after the customer gave up waiting for them and went elsewhere. And if you manage your constraints to have products delivered on time and of high quality, again you get exactly what you want. But the products will contain less than half of the features the customer originally asked for.

I prefer to depict these choices in my favorite adaptation of the iron triangle, where quality is added to turn the triangle into a square. Part of your job as a manager is to think hard about the kind of constraints you place on self-organizing teams. You not only get what you ask for. You also don’t get what you don’t ask for. Too often, managers forget to define clear constraints for quality in their products. And if you don’t define it, you are not going to get it.

(image by Nick J. Webb)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Yes, Good Managers Are Manipulators The Do-It-Yourself Team Values Kit Where There's People, There's Problems

Protecting Fish and System Administrators

I work for a company with a big open office space, in the Van Nelle Factory in Rotterdam. About 100 people work in an office that was the first of its kind in Europe, when it was built in 1929. And 80 years later architecture lovers from all over the world still come to visit and admire it, taking pictures and making drawings. We sometimes wave at them.

A big open office space has many advantages, and some disadvantages. The main disadvantage is that it is a shared resource for all who work there. Climate, sound, and light are hard to manage in a space like that, and the optimal configuration for the whole is never optimal for all. But our office manager does the best she can in trying to maximize pleasant working conditions, while maintaining tight rules to keep things under control. A shared open office is not the ideal environment to give people full responsibility over their own working space.

When shared resources are not managed by a central authority, self-organization often results in the Tragedy of the Commons. The name refers to a situation in which multiple self-organizing systems, all acting in their own self-interest, overexploit a shared limited resource, even when they all know it is not in anyone’s interest for this to happen. The impact that humanity has on CO2 levels in the air, trees in the forests, and fish in the sea, is right now the most debated and intensively researched case of the Tragedy of the Commons.

Organizations also have shared resources, like budgets, office space, and system administrators. We could see them as the business-equivalent of the air we breathe, the landscape we change, and the fish we eat.

It is imperative that you instill some form of governance to protect these shared resources. (I realize that most modern day governments are not setting a good example of how to do that.) In the case of shared resources, whether it concerns money, space, or system administrators, someone outside of the development teams must act as a ruler, keeping an eye on long-term organizational stability instead of short-term individual gains.

The Tragedy of the Commons proves that multiple self-organizing teams cannot share authority over a shared resource, because the systems will optimize for themselves, and not for the whole. They can only solve this problem by installing a form of governance… that is… a (resource) manager. You perhaps?

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Protect People Self-Organization vs. Emergence Agile is NOT a Risk Management Strategy