Agile Management | NOOP.NL

The 3 Criteria for Agile Leadership Practices

What does it mean for a leadership practice to be Agile?

FedEx days? Yes. Open Door policy? No. Moving Motivators? Yes. Time clocks? No! Transition backlogs? Certainly, yes. End-of-year bonuses? Definitely, no!

On Twitter I have claimed that a leadership practice is Agile when:

1. It supports people and their interactions;
2. It helps to deliver value to stakeholders;
3. And it does this by improving the system.

Examples of Agile Leadership Practices

I consider the Gemba walk an Agile leadership practice because it requires a manager to interact with the teams who are doing the actual work. It is done in order to understand how value is delivered to customers and other stakeholders. And the goal is to find out how to help improve the system in which the people are doing their work.

On the other hand, I consider performance appraisals not an Agile leadership practice. Because research shows that such appraisals hurt people and their interactions. And they have nothing to do with delivering value to customers, or any other stakeholders. And performance appraisals are usually misguided in the sense that they attempt to improve people, instead of the system.

One-on-ones? If done well, yes. Mission statements? Quite often, no. Happiness index? Yes. Management meetings? Usually, no. Delegation poker? Yes, of course, I created it. Twitter rants? No, but I enjoy them anyway.

p.s. I call them Agile leadership practices, and not Agile management practices, because you don’t need a management position to start applying most of these practices. Nobody needs anyone’s permission to be an Agile leader.

21 Concrete Practices for Agile Managers (Part 2)

At the ALE2011 conference in Berlin I organized an open space session about Concrete Practices for Agile Managers. For almost an hour at least 30 people discussed with me suggestions for concrete techniques an Agile manager can apply to grow an Agile organization. These were the suggestions by the participants:

1. Take part in a team’s stand-up meetings, and also answer the questions “What I did yesterday”, etc.
2. Attend a team’s sprint demos and ask at least one open and respectful question.
3. Have regular lunches with the team and/or the ScrumMaster to better understand what they’re thinking.
4. Organize open talks once every six weeks with multiple teams and the business side.
5. Organize workshops about Agile adoption strategies and practices.
6. Apply an Agile approach to the working relationship with direct reports (with a board, stories, etc.)
7. Maintain a transformation backlog that you use to track impediments and other issues to resolve.
8. Do NOT place or touch a team’s sticky notes!
9. Keep every morning free of meetings, so you can do a gemba walk and solve problems.
10. Have weekly stand-up meetings with the product owners, business analysts, etc.
11. Keep a log about team members so you can remember and reflect on what you discussed in one-on-ones.
12. Ask questions from fellow managers to improve good relationships with them.
13. Set up a community of practice about management in the organization.
14. Organize 360 degree feedback (or 360 degree meetings as I would do) to get input from the entire team.
15. Organize/attend management circles to discuss management with peers.
16. Reserve slack time/organize FedEx days to support team learning.
17. Regularly look at a team’s feedback door or happiness index.
18. Regularly have a look at a team’s output (the application that they are building).
19. Physically sit together with the teams, not in a separate office.
20. Apply collaborative hiring, so that the team is involved in the selection of team members.
21. Significantly reduce the reliance on email. Force yourself to have face-to-face conversations.

And I received two extra contributions just before publishing this post…

• Play Delegation Poker with your teams.
• Ask to take part in retrospective meetings.

And that it is the summary of what we discussed in almost an hour, and beyond. I hope I remembered everything correctly. If not, please add your comments!

(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.)

Concrete Practices for Agile Managers (Part 1)

I was reading Jerry Weinberg’s book Becoming a Technical Leader last week, and I came across his advice to start a journal and write for five minutes per day. The advice was so clear and simple, I decided to implement it right away.

The reason for writing in a journal is to help yourself with self-reflection. But Jerry didn’t tell his readers to “do some self-reflection”. Instead he wrote we should “keep a journal”. Jerry understood that people need concrete steps to perform in order to learn how to achieve an outcome that is otherwise too abstract to grasp.

That is why, more than a week ago, I asked What Are Best Practices for Managers? I asked for concrete practices instead of abstract values or principles, because without learning which simple small steps to take, managers will find it too hard to achieve the desired outcome: an Agile organization.

The suggestions I received where quite interesting. Not only because I got to read about some practices I had never heard of before. But also because many of the suggestions were still (in my humble opinion) too high-level and too abstract. It confirms my experience that most people don’t know what Agile managers should do from day to day. This just leaves managers with well meant but non-actionable advice such as “make yourself obsolete” and “trust the team”.

But, as I said, I did receive a number of good suggestions. And I will list my favorites here:

• Use the ROTI criteria (Return On Time Invested) at the end of each meeting (Gaetano Mazzanti)
• Use the A3 problem solving approach (Benjamin Mitchell)
• Regularly organize FedEx Days (Rob van Lanen)
• Reserve a fixed percentage of slack time for learning and leisure (Jorge Diz)
• Try a collaborative hiring approach that involves the whole team (André Faria Gomes)
• Publicly list the impediments you will solve on your door (Rini van Solingen)
• Maintain physical proximity to your teams (Antonio Lucca)

These were the concrete practices for Agile managers among the blog comments I liked best. With just a few instructions people will understand how to perform them. Just like I understood how to write a journal!

I will send a free copy of my book to Benjamin, Jorge and Antonio, because I added their suggestions to the backlog of the Management 3.0 course. (Which also happens to be a concrete practice for managers!)

Can you name any more specific practices for Agile managers?

If not, why don’t you start writing a journal? It might help you to reflect on what is happening with you and around you. :-)

(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.)

What Are Best Practices for Agile Managers?

What are the best practices for Agile managers? Which recurring tasks should managers put on their task lists?

Yes I know, there is no such thing as a “best” practice. But some practices are a “best guess” when you try to produce some good results.

• Scrum has the product backlog, user stories, definition of done, and retrospectives.
• XP has TDD, pair programming, refactoring, and continuous integration.
• Kanban has the Kanban board, visualized flow, classes of service, and limited WIP.

But what about Agile management?

It’s a bit unfair, isn’t it?

Software developers, testers, business analysts, and project managers have plenty of frameworks and methodologies available to select their “best” practices.

But what should be on the TO DO lists of development managers and team leaders?

• Some of my own suggestions are delegation poker, authority boards and 360 Degree Meetings.
• Other people have suggested one-on-ones, the happiness index, goal setting, or the Gemba walk.

But what do you think?

Which practices make a manager’s job Agile?

I want to know the concrete best practices for Agile managers. And with concrete I mean we should be able to explain to a novice manager how to perform it. “Trust your people” is abstract, not concrete. “Bring them coffee each morning” is concrete.

Many managers and leaders still operate at the Shu-level of management. They need concrete advice, and step-by-step guidance. A person who is just learning to drive a car has no use for high-level values. They need concrete tips for sitting in their chair, holding the wheel, and looking at the road. They will understand the values soon enough, if they survive.

What do we teach managers who are just learning to survive Agile projects?

Please add your suggestions to this blog posts. I will select three people who will each win a free copy of the Management 3.0 book.

(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.)

(photo by GrowWear)

The Purpose of Leadership (video)

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

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

Cultivate Informal Leadership

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

Latest, greatest and favoritest posts: Widen People’s Job Titles T-Shaped People Managers Are Not Game Designers!

The Nonsense of Leadership (Princes and Priests)

Leadership is a term used by many, but sometimes understood by only a few. Again and again I feel compelled to question ideas about leadership that seem to be based on beliefs, rather than science. In my opinion, there are two groups of people misinterpreting the term leadership, and I call them the "princes" and the "priests".

Leadership Princes

There is a group of people who claim that "leadership is different from management", in the sense that leadership is about inspiration and "giving direction," while management is about execution and "maintaining direction." Leadership is seen as something that takes place on a "higher level" than management, exemplified by cheesy diagrams picturing executive leaders above middle managers. (For example: see Good to Great, by Jim Collins.)

The problem with this view is that it disregards the fact that any person in an organization can be a leader in some area. Every employee can inspire others and give them direction, whether their passion is in architecture, coaching, GUI design, cooking, unit testing, social media, or World of Warcraft. Whether or not a leader is also a top executive is completely irrelevant to the concept of leadership. (For example: see Tribes, by Seth Godin, for a discussion of leaders and followers.)

The top-executives-must-be-leaders mantra also ignores the fact that shareholders want executives to manage their business. They don't need executives just to lead their business, because by definition leaders have no power of authority over their followers. Why should a shareholder give her money to a person with no formal authority in the organization? It makes no sense whatsoever.

Unfortunately, these days many "leadership" books, blogs and seminars turn out to be intended for formal managers, not for informal leaders. It is just old wine in new bottles. For executives it is trendy to call themselves "leaders," no matter whether anyone is actually following them or not. Managers use "leadership" as a social myth to reinforce their positions in the management hierarchy. I call them leadership princes (and princesses), because they think their position makes them more qualified than others to lead people.

Leadership Priests

Then there is another group of people claiming that "management in organizations is not needed". They refer to social networks, Wikipedia, Linux, and other great achievements of groups of people who shared purpose and made things happen. They say that self-organization is the best way to grow an organization, and that people "don't need managers," only leaders with a vision. (For example: Mind of an Anarchist, Dutch blog)

Unfortunately, this view ignores the fact that none of these examples are about corporations. If nobody owns the assets of an organization, then nobody is needed to manage them. But a business does have assets. Shareholders won't appreciate it when anyone in the organization can take money from the corporate account and fly to Las Vegas. And they won't appreciate it when self-organization decides to change their technology business into a catering service. Whether or not employees need managers is irrelevant. It is the shareholders who need managers of their business.

Another problem with the managers-are-not-needed dogma is that it attributes "goodness" to self-organization, completely disregarding the fact that Al Qaeda, the Gomorra, and (former) Yugoslavia are also fine examples of self-organization. People don't realize that, from a scientific viewpoint, self-organization is devoid of value. It takes someone with an interest in its outcomes to decide whether the results of self-organization are "good" or "bad".

But alas, many people think management through hierarchies is "bad," and leadership through self-organization is "good." I call them leadership priests (and princesses,) because they preach a belief in something that is "good," while there is no scientific evidence that self-organization alone has made our universe a “better” place to live in. (It would be the same as preaching that molecules are “good”. It makes not sense at all.)

Leadership Pragmatists

The reality of business requires us to be pragmatic about leadership. Every organization has to be managed, on behalf of its owners. And yes, it is nice for managers to have some leadership capabilities, but managers shouldn't think they are the only leaders in the organization. In fact, in the best performing businesses many leadership roles are taken up by self-organizing (and non-managing) people throughout the organization. On the other hand, these leaders must acknowledge that self-organization in a business requires a little direction from the owners, which happens by passing authority around through one or more layers of management.

If you understand my point of view, I might call you a leadership pragmatist. You understand that the management hierarchy is a simple necessity, and that the bulk of the work is done through a social network of leaders and followers. The leadership network is superimposed on the management hierarchy. Communication and inspiration flow through the network. Authorization and restriction flow through the hierarchy.

Every organization owned by someone needs both: the network and the hierarchy.

Next week: about Complex Systems Leadership Theory as a scientific view on the duality of an organization as a network and a hierarchy.

(images by ingermaaike2, nevet5, LeeBrimelow)

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: It’s Only Communication When There’s Verification Managing vs. Coaching vs. Mentoring Management 3.0: The Era of Complexity

The Dolt's Guide to Self-Organization (Presentation)

Here it is: my latest presentation. Five days of work, 38 drawings, 14 photos, 81 slides, and plenty of texts, to be delivered for the first time at the Scrum Gathering in Orlando next week.

The Dolt's Guide To Self-Organization

View more presentations from Jurgen Appelo.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: Self-Organization vs. Emergence Self-Organization vs. Evolution 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