Agile Management | NOOP.NL

I Tried Education Days, Didn't Work

I once introduced the concept of education days. Every employee in the company was entitled to a number of days per year (we started with twelve) that they should use for self-education. It didn’t matter whether they spent it on reading a book, attending a conference, experimenting with a new technology, or building a prototype of some crazy idea. Anything was fine as long as they learned something. It was almost the same as vacation days. But instead of spending those days exploring bars and beaches, we expected people to explore techniques and technologies. It touched upon intrinsic motivators such as mastery, curiosity, and freedom. I thought it was a good idea.

Well, it was. But it didn’t work.

Education, Not Vacation

The idea was worth trying because apparently it does work in some other organizations. Google has their famous 20 percent time. Employees are allowed to spend 20% of their time working on any idea that interests them. This not only works as a good motivator; the practice is also a generator of many fresh ideas. Products such as Gmail and AdSense were conceived in 20 percent time.

Unfortunately, my organizational reality proved more stubborn. Software developers argued they always had more urgent things to do. They had project deadlines to consider, customer demos to prepare, and meetings to attend. (And probably also some games to play.) Therefore they saw no opportunity to make use of their education days, they said to me. I replied that this was strange, because the same people had no problems making use of their vacation days. A more logical explanation seemed to me that they didn’t consider their education to be as desirable as their vacation. Education was in their eyes just another task to be prioritized by management. Important maybe, but not urgent.

Important, Not Urgent

Experienced knowledge workers know that important things and urgent things rarely overlap. Doing what’s good for you, and developing useful habits, takes motivation and discipline, like flossing your teeth, eating vegetables, and going to the gym. People need to grow into it. (I’ve managed the first one, but I’m still working on the other two.) Because organizations cannot really change people, a good alternative is to tweak the environment so that people change themselves and start developing the desired habits.

One way to do this, is with the introduction of Exploration Days (or ShipIt days or FedEx days or Hack days or Hackathons). They are a small but significant improvement on Education Days. Read more about it in my latest article…

This post is an excerpt from my new article called Exploration Days. Do you want exclusive access to innovative practices? Do you want to be the first to read the new articles? Do you want to learn more about Management Workout?

Subscribe to my mailing list

Managers Should Not Be Coaching Developers

Should hospital directors be coaching doctors and nurses?

Should movie producers be coaching actors and animators?

Should Rupert Murdoch be coaching writers and journalists?

I think three times no.
And yet, I often hear about managers coaching developers, designers, or other knowledge workers.

In a previous blog post I wrote “managers cannot coach employees”. OK, I admit that was a strong opinion, weakly held. Many people liked it, others strongly disagreed. Allow me to rephrase that:

Managers shouldn’t coach employees.

And with coaching I mean competence development:

- a teaching or training process in which an individual gets support while learning to achieve a specific personal or professional result or goal. (Wikipedia)

- to instruct, direct, or prompt (Merriam-Webster)

Reinforcing Hierarchies

One of the biggest problems in many organizations is the hierarchy. The hierarchy kills motivation, stifles innovation, and invites mutilation. (Yes, I made the last one up.)

It is extremely hard to get rid of the hierarchy because there are many reinforcing feedback loops that keep it firmly in place. For example, many managers spend a lot time and energy climbing up the corporate ladder. Psychological research shows that people are reluctant to give up things that they have invested in, even when it’s for their own good. And thus, managers prefer to keep the hierarchy in place. It’s an emotional thing, nothing rational. Like holding on to Céline Dion records.

Coaching of employees by managers is a reinforcing feedback loop. It sends the message that managers are superiors who are teaching their subordinates. It is emphasized by management gurus who (with best intentions) tell managers to become “coaching leaders”. Managers eagerly embrace this message, because it acknowledges that they are important, and more experienced than their subordinates. At the same time these authors (unintentionally) make knowledge workers believe that, in order to become coaches, they have to become managers first.

It’s all wrong.

Managing, Not Coaching

Hospital directors don’t coach doctors and nurses. They manage the hospital.

Movie producers don’t coach actors and animators. They manage production.

Rupert Murdoch doesn’t coach writers and journalist. He manages scandals.

The coaching of young doctors is done by experienced doctors. New actors are often guided and taught by older actors. And aspiring writers usually counsel established writers. That’s the nature of things.

I understand, some managers are actually able to coach knowledge workers quite well. But maybe they shouldn’t. It could send the wrong signal. They would be reinforcing the hierarchy. At that’s the last thing we want.

Managers should manage the system. That’s difficult enough already.

     

Keynote Slide Delivery at the Last Responsible Moment

Today I addressed a 300 person audience with a keynote at Ericsson’s Agile conference in Finland. I was invited to talk about personal development, communication, and organizational structure, using one of my more popular presentations: The Big-Ass View on Competence (and Communication).

Some of my main points were:

1. Allow Agile teams to form an internal market of value units who consume each other’s services;
2. A big organization should be scaled in a fractal way by making it look like small ones at all levels;
3. Use personal communication networks as the guiding principle for organizational design.

Now, I gave Ericsson’s conference organizers a hard time because they had been asking several times to receive a copy of my slides. And I told them repeatedly I wanted to wait until the Last Responsible Moment.

The value of deferring decisions and late commitment proved itself last night, when I was reading the book The Interaction of Complexity and Management (which I encourage everyone interested in complexity theory to read because it is very inspiring).

In that book I found the following fragment:

Insofar as the business environment is becoming more complex, firms will need to [...] shift away from bureaucracies and toward [...] internal competition (markets), the need for the large firm to behave as a small one (fiefs), and the importance of interpersonal networking (clans).

- Max Boisot, “Complexity and the I-Space”,
The Interaction of Complexity and Management

This quote is the conclusion of complexity research, where survival of adaptive systems in increasingly complex environments was modeled and simulated with computers. Nothing in the book referred to Agile software development. And yet, the conclusion is exactly the same as mine.

It was the perfect quote to end my presentation, and to kick off a conference organized by a big organization which is transforming to be Agile all through the enterprise.

And because I added the quote to my slides only hours before the talk, it nicely proved that it pays to deliver slides to conference organizers only at the last responsible moment… which is about 1 minute before I go on stage!

p.s. My thanks to Ericsson for the invitation to their conference, which was, as it turns out, very well organized. :-)

(Jurgen Appelo is author of Management 3.0, a best-selling management book for Agile developers. It has a picture of a monster in it.)

The Big-Ass View on Competence (and Communication)

View more presentations from Jurgen Appelo

Agile Discussions: How to Become a Professional

Becoming a software professional begins with sharing knowledge and ideas in agile discussions with colleagues.

Yesterday night I was invited by Improve Quality Services, a quality management company, to lead a 3-hour discussion about Scrum, competence development, and self-organizing teams. I thought it was great!

The group was small (about 15 people), but I didn’t mind because it meant that everyone could get involved, and they all participated actively in our debates.

Agile and Scrum

For the first part of our discussion I used some slides from my popular Zen of Scrum presentation (viewed 19,000 times). We talked intensively about the problems of the Product Owner, how to embrace change when customers want promises, the effects of test-driven development on developer productivity, the position of the tester in distributed teams, and the position of the project manager compared to the various Scrum roles.

Competence Development

For the second part I triggered discussions with a number of slides from The Big-Ass View on Competence. We talked about balancing rules versus freedoms, the shared space concept, the importance of self-development, the challenges of certification, the role of supervision and quality assurance, and how to evaluate each other in a team using 360 degree feedback.

Self-Organizing Teams

The third part of the discussion was about self-organizing teams, for which I used a few slides from The Dolt’s Guide to Self-Organization (viewed 14,000 times). We talked about boundaries and giving direction, the difference between self-organized vs. self-directed, teams that can select themselves, and how to use seven levels of authority to be more specific when you empower other people.

Agile Discussions

I commend Improve Quality Services for organizing these discussion nights with their employees. Competence development is a responsibility of both employers and employees. Though it is hard to measure the direct effects of a discussion night, I firmly believe that craftsmanship and professionalism start with the sharing of knowledge and ideas.

And that’s what they did…

Jurgen Appelo is an award-winning speaker, trainer, and author of Management 3.0, a management book for software development. You can hire him as a speaker or trainer, to add some spice to your discussions, workshops, or conferences.

KISS Principle: Make It Simple vs. Do It Simple

Making things simple is not the same as doing things simple. Unfortunately, this is not a simple message to get across.

Here's my personal quote of today. It is a bit complicated, but just read it twice and I'm sure you will understand it:

It is complicated to build stuff that is simple.
It is simple to build stuff that is complicated.

There's also a more famous quote by Mark Twain, which is a lot simpler:

I didn't have time to write a short letter, so I wrote a long one instead.

Mark Twain's quote is shorter than mine, although I'm sure it cost him more time. But no matter which quote you like best, what is true for writers is also true for programmers. It takes more time to make things that are simple.

The KISS Principle

In software projects there are two very important and very different notions about simplicity:

1. Work carried out in a project must be kept as simple as possible. (Do It Simple)
2. A product must be as simple as possible for its users. (Make It Simple)

Both are variants of the KISS principle (Keep It Simple, Stupid!), but they are applied very differently, which makes it a bit complicated. In the first case it is applied to the work performed, to minimize production costs, while in the second it is applied to the product, to minimize frustration costs. Many people don't seem to realize that Do It Simple conflicts Make It Simple, although both seem to be valid applications of the Keep It Simple principle. This has created a lot of confusion, and it hasn't made communication any simpler!

Creating things that are simple to use is at odds with the need to keep the work itself simple. When people tell me to "Keep It Simple", I am left wondering... Do they want me to do my work the simple way? Or do they want me to do it the complicated way, so that the results are simple? The Mark Twain quote came to my mind no less than three times while reading some blogs, articles and magazines before writing this blog post:

Simple Work <> Simple Products

Ed Yourdon complained about the difficulties he faced when adjusting the time in his car for Daylight Savings Time. Though I agree that user interfaces for changing time in many devices is a real pain, I can also understand why. Many manufacturers prioritize Do It Simple (design of a clock) over Make It Simple (usage of the clock). -- After all, the ease with which one can adjust the clock in a car is usually not the main motivation for selecting one car brand over another.

I once got into a bit of a fight (verbally) with Chuck Allison, the writer of an article on complexity in software. Among other things, he writes that we can simplify the creation of software by adding additional layers of abstractions. He named high-level languages as one example. However, my claim is that this may be true for the users (the simple programmers like me), but it makes things very, very complicated for those enabling such an abstraction layer (the poor souls who build compilers).

Wired once had an article on 37signals, the guys behind Ruby on Rails, who apparently claim that developers should try and keep things simple. But what do they mean? It is said that they are snubbing people who have a hard time getting Ruby on Rails to do what they want. Wired Magazine says: "Now, critics argue, the pair's reactionary embrace of all things minimal has made their products less useful [...]" In my terminology "less useful" might indicate having prioritized Do It Simple over Make It Simple.

Do It Simple or Make It Simple, But Not Both

I have always thought that Do It Simple conflicts Make It Simple. Though both have their place and value, you cannot have one's cake and eat it too. Unfortunately, this is a complicated message to get across, and I'm afraid this blog entry was written in just under an hour. It could probably be simplified, if I only had more time. Maybe there's a bit of Mark Twain in me right now. I didn't have time to write a short blog entry, so I wrote a long one instead.

Jurgen Appelo is an award-winning speaker, trainer, and author of Management 3.0, a management book for software development. You can hire him as a speaker or trainer, to add some spice to your discussions, workshops, or conferences.

Competence Development: The Cone of Incompetence

Managers are responsible for competence development in an organization. But, for some reason, this doesn't always happen.

Steve McConnell has described the Cone of Uncertainty in his books. This graph tells us that project estimates are wildly inaccurate at the start, and only become better over time, when more is known about the nature of the project.

I now think that there is also a Cone of Incompetence.

The Customer

At the far left of the Cone of Incompetence is the customer. The customer has thought long and hard about a new project (usually more than a year) and now that he finally decided that he wants it, the customer wants it delivered in just two months. There is usually some arbitrary deadline that happens to be outside the customer's scope of control, therefore negotiation about the deadline is impossible, because the customer "cannot" change it.

The Account Manager

A bit to the right is the account manager, who is a little more competent than the customer. Unlike the customer the account manager knows what a timebox is, and he knows some benefits of iterations and frequent delivery, with weekly customer feedback. He just doesn't know how to sell it, because the customer doesn't want all that. So the account manager ends up selling a big requirements study, because the customer feels safe owning a big document with a detailed specification of a product. The customer won't read it, but the customer will be happy. And that's important.

The Project Manager

In the middle of the Cone of Incompetence we find the project manager. She is more competent than the account manager because she knows exactly how risky the project is going to be, with an impossible deadline, no timeboxed regular releases, and little or no customer feedback during the project. Nevertheless, she is very eager in getting the project going, and the project manager assembles a team consisting of 45 first-time employees, interns, gnomes, trolls and pizza delivery boys. When added together this team should be able to burn exactly the number of days that was estimated in the requirements study. She might even have had time to write down a Risk List. But it is somewhere at the bottom of the pile that now contains the new high priority features that the customer has sent her.

The Software Developers

Further to the right we find the software developers. They are more competent than the project manager because they understand all the risks and know that the project is never going to make the deadline with any manageable product of sufficient quality. However, they still enjoy working on the small parts that they have been assigned to. Code is code, after all. But in the hurry to finish their assigned tasks, the software developers forget to test half of the stuff they wrote. However, as for the quality of the project, they couldn't care less, because they were not involved in all the wrong decisions that have already been made in the first place.

The Software Testers

On the far right side of the Cone of Incompetence we find the software testers, who are the most competent people in the organization, and who will make sure that lousy products do not get shoved out of the door to customers. Unfortunately, the software testers don't exist. Because software testing means overhead. And overhead costs must be cut because of the losses already made in previous projects. This, of course, was a decision made by...

The Managers

Meanwhile, the managers are doing their best to promote competence development in the company. But, somehow, it just doesn't happen.