I have some major changes ahead of me, which will probably have an impact on this blog.

Medium time scale
In just two days, on August 1, I will send the final manuscript of my book to my publisher. That doesn’t mean I’m done with the book. It only means the writing will be replaced by marketing. But I look forward to that. It’s another creative project, and a new opportunity to learn while doing something useful. And you know me, I love self-promotion.

Long time scale
Yesterday, I told my boss that I want to leave ISM eCompany by the end of the year. I had a great time these past seven years. But with the launch of my book I intend to initiate a new career of full-time writing, speaking, and training. And self-promotion. Again, it will be a road full of learning opportunities. It’s probably a painful road, but definitely worth traveling.

Short time scale
But first, I will need to prepare for the Agile 2010 conference in Orlando, where I will be presenting/hosting one session. Self-promotion for that will commence in about three days. Immediately after the conference Raoul and I intend to enjoy a brief but well-deserved vacation in Norway, with all channels switched off. Except for the verbal ones.

These are the three big changes I’m facing.
It’s so exciting, it’s almost scary.

Don’t expect too much from me on this blog in August. My self-promotion will be back, with a vengeance, in September!

(image by Capture Queen)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
Make a “Social Contract” with Your Team
The Open Space Policy for Managers
Agile (Wrongfully) Assumes Craftsmanship

The approach some people have to the issue of social diversity is rather simplistic. Their idea of “adding diversity” to a software team is usually limited to attracting more women. It is an approach based on stereotypes about gender differences, and, from a scientific perspective, it is completely outdated (see: “Out with the pink and blue: Don’t foster the gender divide” - NewScientist).

“There’s a lot more to diversity than the shape of ones genitals.”
The Future of Management – Gary Hamel.

It has been noted by management experts and complexity scholars that a person’s performance is determined, to a large extent, by the system in which he is set to work. And social network analysis has revealed that this performance also depends on the person’s connectivity with other people in the social network (see: The Hidden Power of Social Networks – Cross/Parker).

This means that, when you hire a new person, one of the most important things to watch out for is how this person will connect to other people in the organization. Preferably, you want these connections to be of a different kind than the connections the existing team members have been able to establish, because diversity in connectivity has the highest impact on competence and performance in your team. Whether the person is male, female, dark, white, single, married, big, or tall, is probably irrelevant.

This means, when hiring a new team member, right after checking for competence, you should check for a person’s connection-making capabilities. For example, by checking what kind of connections she made in her previous job; the kind of connections she prefers in her social life; the sources she uses to increase her knowledge; the way she approaches the receptionist, the HR manager, and other people in your organization; and the way this person can get along with the team she is likely to join. That means you check this stuff before you sign the contract, because these are all indicators of the real diversity the person will add to your team.

Diversity is not about a person’s genes. It’s about a person’s mind and her connections.

(image by batega)

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

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
Choosing Authority Levels for Team Members
The Optimal Team Size is Five
People over Process: a Universal Law

I really like our system administrators, but I think I am their worst customer. It’s not that I’m behaving badly. (Well, usually I’m not.) It’s just that my aura has an unpredictable effect on electromagnetic fields. People have seen reliable software crash whenever I passed by, and even the sturdiest operating system has an increased tendency to reboot unexpectedly in my presence. And remember those many times you saw a fail whale on Twitter? Yes, that was probably me having logged in before you. That’s why I like our system administrators so much. Because no matter how many problems I generate for them, they always treat me as a customer.

It is often claimed that cross-functional teams solve the problem of local optimization, which happens when functional teams optimize their own efficiency. This hurts the overall performance of the business. For example, a testing team may optimize testing procedures, making sure that all testing for a project is performed in one short period of time. Such an “efficient” practice doesn’t take into account the dramatic effect this has on the development and support phases of the projects. But is this really a problem of functional structure? Or is it an example of the testing team not treating the development and support teams as their customers?

The opposite problem is that cross-functional teams tend to optimize for their own projects, which can also hurt the overall performance of the business. For example, there may be problems when different project teams all decide to choose their own architectures and 3rd-party components. This increased variation of technologies makes it very difficult for the organization to support all those projects. And I’m sure that, when I allowed all our project teams to purchase their own computers and install their favorite operating systems and development environments, our friendly team of system administrators would skin me alive. With a screwdriver and a soldering iron.

But nobody in our organization would dream of inviting a system administrator into their cross-functional teams. And that’s not because we don’t like them. It’s because communication within the team of system administrators is more intensive than their communication with the project teams, even though infrastructure is an important part of many of our business solutions. Therefore it makes more sense to keep these people together in their own functional group, despite the communication penalty paid on any cross-functional communication.

What’s important is that every team, both functional and cross-functional, should see itself as delivering value to a customer, no matter whether that customer is an internal or external one. Our team of system administrators sees itself as a small business unit that tries to serve their customers, by delivering something valuable. And that’s why we like them. They make the other teams feel important, because to them we are important, no matter how often I crash our systems or bring down our servers. Functional teams and cross-functional teams should be run as little value units, and there is no limit to the number that can be formed.

(image by Josh Pesavento)

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

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
When You Are Rejected
About Project Success and Failure
I Follow My Rules, You Follow Yours

…continued from part 1 and part 2.

Step 7: Create slides

When I am confident about the content, structure and supporting materials, I start creating the slides. Note that rework of the content in slides is costly! That’s why I need to know what is going to be shown on which slide before I start making them.

At this time the details of the layout (font size, colors, positioning, etc) are not important. These are easy to do later.

What’s important in this step is that content, structure, and basic materials all have their right place in the presentation.

Step 8: Review the talk

This is the moment when I review the entire presentation to check if I have everything right. Are the stories in the right place? Do I have some silly jokes to entertain the audience? Do I have some surprises in there to keep them awake?

Basically it means I perform the entire presentation in my head to see if the flow is right. This review can result in some final tweaking of the content: splitting or merging slides, or adding/removing some.

Step 9: Tune the layout

Only now is the right time to bother with the layout, after I have verified that all content is in the right place. This means taking care of font, size, colors, positioning, etc.

Again, consistency is important. I don’t want to use 5 different sizes of fonts on my slides. That’s why the content must be finalized at this point, because the best decisions for a consistent layout depend on the whole set of texts and visuals.

(Oh, and one layout tip: please don't center everything on your slides. Stop that immediately. It's boring. You have two good friends for design: white space and alignment.)

Step 10: Practice!

The last step, and one of the most important ones, is to practice the presentation. I practice a new talk at least three times. The purpose is not to rehearse the texts until I know them by heart. I prefer being casual, and being able to respond to the audience. That means I don’t want to read from a script.

However, the purpose is to know the content, so that I’m not surprised by it myself. For example, only when speaking out loud I may realize that I don’t know how to pronounce a foreign word; or I realize that I must know the exact timing of a joke right before I show a slide that gives away the punch line.

My plea is never to go on stage if you have not rehearsed your performance. Music lovers expect artists to have practiced before they see them on stage. It is an insult to the audience if you think you can get away by not rehearsing your show.

That’s it. These are my 10 steps for making presentations. I hope you found them useful!

back to part 1 – back to part 2

p.s. You still have not ordered the book Presentation Zen, by Garr Reynolds? Well, then at least get yourself Confessions of a Public Speaker (Scott Berkun), or Slide:ology by (Nancy Duarte). Those ain’t bad either.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
No Maturity Models, But Individual Competence
People Motivation: Target Intrinsic Desires
Risk Management = Banana Peels AND Dollar Bills

…continued from part 1.

Step 4: Define slides

In this step I transform the topics to individual slides, by sketching on (new) sticky notes my ideas about what the slides will communicate. Sometimes it’s just a few words, sometimes just a picture, and sometimes a graph or a quote. At this point I sometimes use different colors of sticky notes to distinguish the content (the message) from the context (agenda).

Also, in this step, I try to keep the 6 SUCCES principles in mind, which tell me that sticky messages are about Simplicity, Unexpectedness, Concreteness, Credibility, Emotions, and Stories.

Step 5: Design slides

The next step is about how I will create the slides. Will I use photos? Will I use quotations? Will I make my own drawings? I write these decisions on the sticky notes so that I will remember them. I recently switched from the use of photos to (mainly) drawings, but anyone should use a format that he/she is comfortable with.

Most important for me is to understand how much work there is to do to design all slides. And whether or not I can save some time by reusing visuals across multiple slides. These are things I want to know before creating the first picture.

Step 6: Create visuals

Then it is time to start collecting (or creating) all materials. Which for me means either browsing Flickr for free (creative commons) images, or drawing them all myself.

Here the crucial issue is consistency.  I have seen many presentations with a complete lack of consistency of the visuals across the slides. But people enjoy presentations more when the design is good, and consistent. For example: if you’re using photos, you might want to make sure that the photos have a certain color as a recurring theme. Another idea is to use a metaphor (like traffic management) for most of your pictures.

back to part 1 – go to part 3

p.s. Have you already ordered the book Presentation Zen, by Garr Reynolds? Why not? Didn’t I tell you this last time?

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
No Maturity Models, But Individual Competence
Self-Organization vs. Anarchy
Great Managers Have No Secrets

Over the years I've made quite a lot of presentations. The ratings of my last presentations at conferences have been quite favorable, and people regularly ask permission to steal some of my slides. So it seems I'm doing at least something right. And that's why I'd like to share my process with you...

Step 1: collect topics

No matter how I decide about my topics (I usually take them from my blog and my book,) I start by collecting them on sticky notes. Each sticky note is a topic, and I put them all on the outside of my bathroom wall. (Why there, you may wonder? Well, because they tend not to stick on the inside.)

At this time I don't worry about individual slides. One topic may need five slides later, other topics may need to be combined. I don't care. I only think about topics and how they relate to one another.

Note that "topics" here means anything I want to tell the audience. Including all kinds of simple things, examples, statistics, etc. That's why I end up with a lot of sticky notes here.

Step 2: create structure

When I'm happy about the topics, I create a structure by clearly defining sections (which will be turned into the agenda later) and the logical flow of the topics within a section (are they in a natural order?).

I clearly indicate sections (and sub-sections) with a different color of sticky notes.

This is the perfect moment to remove topics (when they don't fit well in the flow of the presentation,) or to add extra topics (to smooth transitions between other topics) where this is needed.

Step 3: make story

Then it is time to decide what the conclusion is of the presentation (so that everything in the presentation supports that conclusion.) Basically I ask myself two important questions:

• What is my point?
• Why should people care?

If I cannot answer these questions clearly I will know my presentation is flawed. Asking myself these questions usually results in me making some more changes, until I'm happy about the message that I want to get across.

I also take time to fashion metaphors, and to think about a nice introduction. I ask myself: what stories am I going to tell the audience to introduce the topics, and to keep people engaged throughout the presentation?

For example: in my last presentation (Big-Ass View on Competence) I used traffic management as a metaphor, and I came up with stories about car driving, bicycles, roundabouts, traffic police, and even witches on brooms.

go to part 2 – go to part 3

p.s. While you're waiting for the next installment of this little series, please order the book Presentation Zen, by Garr Reynolds. It's plain awesome. 

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
Why We Delegate: The Darkness Principle
The Optimal Team Size is Five
Fixed Price Contracts in Agile Projects

I am ___.

It’s not by choice. That’s how I was born.

I am perfectly happy being ___. It’s no big deal. It’s just the way it is. But other people are making a fuss about it.

Some say there ought to be more people who are ___ in software development. They say we must invite people who are ___ to try a technical career. Because there aren’t enough of them in our industry.

I don’t see why.

Either people who are ___ like software development, or they don’t. (It’s unlikely they’ve never heard of it. Unless they are ***)

I don’t favor an annual celebration day for ___ people in software development.

And I don’t need awards or programming languages named after people who are ___.

And I certainly don’t like government subsidies for people who are ___.

And I definitely don’t like positive discrimination (affirmative action) in favor of people who are ___. Because it is an insult to people like me who are both ___ and competent enough to create a career on their own.

And besides, if we support people who are ___, then we should also support people who are @@@, ###, &&&, --- or ===. And where does that end?

Of course, when some #*! people are negatively discriminating against ___ people, we should fight them. But that's all there is to it. Neutrality is our end goal. It's not a stop somewhere halfway.

I’m very happy that I am where I am today because I am competent. Not because some people pushed me here, just because I am ___.

(image by Dierk Schaefer, who is +++)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
T-Shaped People
Communicators: 2 * Three Types of People
People Motivation: Target Intrinsic Desires

Next Tuesday is my birthday.

It’s going to be a special birthday because my age will reach the 13th prime number. So cool!

And so I invite you to celebrate this with me at my birthday tweetup at Dudok Rotterdam, between 20:00 and 22:00 on July 20th.

And I have an idea for a birthday present...

I hope to get 3,000 followers on Twitter.

I will buy you a free drink and a piece of Dudok apple pie if you’re there, but… only if you help me to get me my present!

I’m sure you’re asking, am I welcome at this tweetup? Well, if I know you exist, you’re invited! That means: friends, family, colleagues, contacts, Italian disco singers, my dentist, and any other weak ties in my contacts list are all welcome to join the tweetup.

Please give me a signal if you intend to be there (tweet, sms, email, voice). And tweet about it! Or else the only thing I give away for free is my radiant birthday smile.

Birthday present status (July 15)… 2793 followers: no free apple pie yet!

Hope to see you at Dudok on Tuesday!

p.s. Even if you can’t come, you might want to help the attendees get their free apple pie.

Disclaimer: the Dudok kitchen might have an upper limit to available apple pie...

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
Fix the Small Problems First
Self-Organization vs. Emergence
Islands in the Stream

Hurray!

Today is the “official” re-launch of the companion website for my book:

management30.com

The site launches with a fine post called The Squeaky Wheel Gets the Grease by Michael = FAIL, by Michael Cardus.

My followers on Twitter have noticed my struggles with (and rants about) Ning, the platform where my site was previously hosted.

After a plea for help on this blog several people suggested that I try Squarespace. And I did.

My oh my, what a relief!

Squarespace turned out to be exactly what I needed… Very easy content management, a modern GUI, a very flexible page architecture, many cool options for blogs, widgets, and membership, awesome styling features, and… super-fast customer support! (And now that I have started promoting them, they received $38.5M in funding. Go figure!)

In short, it was exactly what I had hoped Ning would be half a year ago, but wasn’t.

I have dedicated the front page of the management30.com website to anyone who wants to share an article, a guest post, an opinion, a book release, or a review.

Read the guidelines and contact me if you like to be in the spotlights!

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
The Success of the Agile Memeplex
The Do-It-Yourself Team Values Kit
People Don't Listen

How should people be grouped together? Basically there are two main options to choose from: group people by similar function or by similar business.

Grouping people by similar function means that you put developers with developers, testers with testers, and project managers with project managers. Such groups are called functional units, and the driving motivation behind this kind of structure is efficiency and functional learning. After all, it is easiest for writers of user stories to learn how to be efficient user story writers when they’re all put together in one department called User Story Writing.

Grouping people by similar business means that you put everyone together who works on the delivery of the same business value (the same feature, the same product, or the same customer). Such groups are sometimes called cross-functional units, because all people involved in the same project(s), from user story writers to binary assembly deployers, end up in the same group.

Good communication is both hard and crucial for any organization. It is therefore imperative that we let communication be one of our guiding principles when choosing between the two variants.

Which people need each other most often?

The ones with the same job titles?
Or the ones working on the same project?

If you were to analyze daily communication between employees it would quickly become clear that most of that communication is oriented around the business, and not around the function. People with different functions but working on the same projects need to communicate more frequently than people with the same functions who work on different projects (see figure). We can thus conclude that, for projects, cross-functional teams are a more suitable solution to the grouping problem.

 More communication within projects than within functional groups. 

It has been reported that, in organizations where people are grouped by function (sometimes referred to as functional silos), there are too many dependencies between the functional teams. Delivering even the smallest piece of business value (like one feature of a product) requires communication and co-ordination across multiple teams. Functional silos therefore have a high interaction penalty.

However... when you build teams across the functional silos, and not inside the silos, the interaction penalty is lower, but not zero! There are three problems with cross-functional teams: suboptimization at the project level, inefficiencies due to lack of coordination across projects, and reduced expertise because of limited knowledge sharing across specialists [Reinertsen 1997]. So it appears that with cross-functional teams the penalty is paid for synchronization of standards, methods and approaches within one functional discipline across different teams. For example, it will take a quality assurance manager more effort to co-ordinate best practices in testing, when the testers and QA people are spread over multiple teams. But the price being paid here is generally lower than in the case of functional units.

There are several other advantages to cross-functional teams (varyingly referred to as feature teams, project teams, organic teams, or product teams). Several experts report improved design decisions, reduced waste from hand-offs of intermediate products, improved speed, improved adaptability, simplified planning, and focus on delivering value.

But remember, unlike the Dutch score at world cup final, the costs of having cross-functional teams will not stand at zero!

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

(image by Jayel Aheram)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
Widen People’s Job Titles
T-Shaped People
How to Grow: More or Bigger?

Telling people a Story is one of the six SUCCES principles for getting a message across to an audience. This was described by Chip and Dan Heath in their great book Made to Stick. (The other principles are Simplicity, Unexpectedness, Concreteness, Credibility, and Emotions.)

I recently asked readers to give me some last suggestions for my book, which is nearly finished. And I got a number of very good ideas.

But the one I liked best was the suggestion from Jens Schauder:

I'd really like a chapter “a day in the life of an agile manager.” It would be written like a short story: A nice conflict in the team to start the morning. The manager tries to find out what is going on, talks to people, provides ideas... with cross references to the different chapters of the book.

If I have sufficient time left at the end of this month I will try to write an appendix with a story. Because storytelling is the most powerful way of getting your messages across.

And for this suggestion Jens Schauder has earned himself a $189 Amazon gift card.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
The Three Manifestos
Reduce Your Fear, Increase Your Status
Managing Risk vs. Managing Yourself

And here's another video of a talk I did at the Norwegian Developers Conference. This talk is about managing and leading self-organizing teams. The original slides can be found here.

This talk scored even better than the one I published yesterday: 42 green cards, 1 yellow one, and no red cards. This would correspond to 99% satisfaction (assuming green=100%, yellow=50% and red=0%).

This video is provided courtesy of my friends at Programutvikling AS, the organizers of the NDC2010 conference.

p.s. Go to the Tandberg Content Server for 122 other fantastic presentations!

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
OK, Let’s Talk About Certification
Quality: You Don’t Get What You Don’t Measure
About Project Success and Failure

Here's a video of a talk I did at the Norwegian Developers Conference. The talk is about different ways of developing competence in an organization, and it draws on traffic management as a metaphor. The original slides can be found here.

The talk scored quite well: 31 green cards, 3 yellow ones, and no red cards. I calculated that this would correspond to 95% satisfaction (assuming that green = 100%, yellow = 50% and red = 0%).

A kind word to my Swedish and Belgian readers: I didn't really mean what I said in this video... I'm sorry. :)

BTW, You cannot hear the Norwegian audience laughing out loud during my presentation. But they actually did!

This video is provided courtesy of my friends at Programutvikling AS, the organizers of the NDC2010 conference.

p.s. Go to the Tandberg Content Server for 122 other fantastic presentations!

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
OK, Let’s Talk About Certification
Quality: You Don’t Get What You Don’t Measure
About Project Success and Failure

People tend to form groups. And when a group is small enough, and has a shared purpose, we may call it a team. The concept of a team is very useful, because it is a way of identifying a number of people as one entity. In psychology they call that “chunking”:

The idea of “chunking”: a group of items is perceived as a single “chunk”. The chunk’s boundary is a little like a cell membrane or a national border. It establishes a separate identity for the cluster within. According to context, one may wish to ignore the chunk’s internal structure or take it into account.
– Gödel, Escher, Bach (Douglas Hofstadter)

In my own organization, with many small projects and dozens of developers and testers in multiple locations, team formation has always been a challenge. We’ve changed our team formation approach more often than Madonna changed her image. But management of team boundaries is an important part of a manager’s responsibilities, and it’s important to try and get things right. After all, teams don’t operate well when people don’t know what the teams are, and who they can rely on.

There are three aspects to boundary management:

• the way teams are constructed;
• how individuals relate to teams;
• and how teams change over time.

Self-selection of teams is possible in organizations where people have a high level of “empowerment maturity”. In such an organization you create a pool of potential team members, and then you leave team formation to the group itself. There might be projects that many people want to be on, and projects that nobody wants to do. The great thing is that the group has to find its own rules for team selection, and as a manager you can just enjoy the heated discussions from the sideline. Self-selection of teams is something I have rarely seen in real businesses. It is worth considering, but you have to be sure that people understand how to form teams. One team of 30 developers and one team of 20 testers might not be a good option. Just consider the example of popular boy bands: Though they can have 30 members, in which case we tend to call them boy choirs, with such a size they rarely have the agility to keep up with trends in entertainment as much a small team can. So in order to increase their chance of success you might want to define and discuss some constraints on team formation first, concerning size, diversity, and other parameters.

How individuals relate to teams is another constraint you should take into account. Is a person allowed to be a member of more than one team? It is common for people not to perform as well as they could when they are asked to spread their loyalty across multiple teams. Mick Jagger never joined the Jackson Five to complement the Rolling Stones, and for good reasons. Such situations lead to task-switching, conflicts of interests, loss of commitment, and loss of motivation. Try and make sure that every person is dedicated to just one team. People cannot act as a team when they do not know what the team is. They may occasionally assist other teams, and help out with other people’s projects, or perform some duets, but each person should have exactly one base team to return to.

Finally, the time span of a team is also an important issue. Research shows that teams perform much better when they are long-lived. It is best for teams to exist for as long as possible, because it takes time for communication paths and rules in a team to grow and pay off. It also takes time for them to learn, as a team, which information is important for them and which is not. Just think of this: what is the best pop group ever? And how long did they stay together? More than a few years? Yes, I thought so. When projects in your organization are by their nature short, try and keep people together in teams with longer life spans, where the same teams work on one project after another.

(image by Chris Willis)

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

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
Widen People’s Job Titles
How to Grow: More or Bigger?
Network Effects: Waiting for the Tipping Point

Recently, at a conference, I noticed a big difference between compliments. After my presentation, several people gave me compliments on my inspiring message and my simple and clear drawings. I was grateful for that. And I was glad that I... Jurgen Appelo

Recently, at a conference, I noticed a big difference between compliments.

After my presentation, several people gave me compliments on my inspiring message and my simple and clear drawings. I was grateful for that. And I was glad that I had achieved my goal.

I also overheard people complimenting another speaking on the stunning animations that he created with prezi.com, with rotating words and sliding bubbles. But I noticed people were not talking about his message.

Which compliment do you want?
What is your goal?

Are you trying to make people think about your message?

Or are you trying to send new users to prezi.com?

p.s. This is not a rant against prezi.com or animations. In Toy Story 3 animations seem to work quite well.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
Two Presentations on Complexity and Leadership
Social Commerce (presentation)
The Dolt’s Guide to Self-Organization (Presentation)

At last! I have finished writing the last chapters of my book and I sent them to my publisher and reviewers yesterday. Pffffff… Now I will spend a month processing feedback from reviewers, polishing a thousand little details, and covering... Jurgen Appelo

At last!

I have finished writing the last chapters of my book and I sent them to my publisher and reviewers yesterday.

Pffffff…

Now I will spend a month processing feedback from reviewers, polishing a thousand little details, and covering my ass in all possible ways.

And I can use your help!

Please tell me… Which topic must be addressed in my book about managing agile teams?

What most important question should be answered in my Management 3.0 book?

Email me, or add your question to the comments section. I have a $189 Amazon gift certificate available for the best question that would lead me to add another paragraph or two to my book.

I still have a month to add (a few) important topics. Let me know what you would look for in the responsibilities of an agile manager.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
How to Grow: More or Bigger?
The 9 Capabilities of Communicators
Discipline * Skill = Craftsmanship

Leaders in a team are sometimes called “Leads” or “Chiefs,” like technical leads, project leads, chief programmers, and chief architects. What these people have in common is that they are not the line managers of the others in their teams.... Jurgen Appelo

Leaders in a team are sometimes called “Leads” or “Chiefs,” like technical leads, project leads, chief programmers, and chief architects. What these people have in common is that they are not the line managers of the others in their teams. Informal leadership is bestowed upon people because of credits earned or commitments made. Or maybe even as a practical joke. It is a responsibility that is completely separate from line management. When several people take up leadership in different areas we might call it distributed informal leadership. Informal leadership follows logically from working with generalizing specialists and using wide job titles.

You can actively cultivate informal leadership in your teams by supporting emergent leadership positions, but it is best to refrain from directly assigning such roles yourself (as a manager). Allow the teams to decide whether they wish to appoint Technical Leads, Project Leads, or some other leading role. (Note that many teams tend to flounder when there’s no strong leadership inside the team. You may need to push them and help them in solving their own leadership problem.)

None of the roles mentioned would involve a management layer. In fact, that is precisely why informal leadership contributes to the adaptability of an organization. By abstaining from a management layer of Chief Somethings and Lead Whatevers you make it much easier for the organization to add, move, and delete such responsibilities. Whenever there’s need for a Chief Graphics Designer, she can be appointed at the spot. And when the need fades away, so does the role. Not the person. If the role was a formal job title, the person would have to be kept busy, or she would have been asked to formally change her job, or else she’d have to get fired for lack of work. All of these are unpleasant measures that suck productivity out of the organization.

Generalizing specialists, widening job titles, and informal leadership are different but related concepts. Though they tend to reinforce each other, you can introduce one before introducing the others, which might be necessary when gradually changing a bureaucratic organization to a more adaptable one.

But please don’t ask me what order would be best in such cases. My experience is mainly with organizations where people were flexible and passionate enough to swallow them all at once.

(photo: The U.S. Army)

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

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo'; Latest, greatest and favoritest posts:
Widen People’s Job Titles
T-Shaped People
Managers Are Not Game Designers!