Agile Zone is brought to you in partnership with:

I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 636 posts at DZone. You can read more from them at their website. View Full User Profile

Lean tools: Leadership

07.04.2012
| 3220 views |
  • submit to reddit

According to the Poppendiecks, the differences between a manager and a leader is that a manager cope with complexity while a leader cope with change (which is an essential tenet of Agile.) This is not to pick on managers of any kind: the original Kotter's article sees managing and leadership as two complementary aspects; it's also difficult for a person to do well in both jobs.

I would mostly speak from the developer side of the barricade, as I am still young and not had many occasions to be the leader (and none for being the manager; I'm also not sure is the best path). But I will tell everything that a developer craves for in a manager, or in a leader.

The manager I want

Planning is one of the most helpful activity of a manager, as he should have many connections with the business your code is supporting - selling a product, providing a service, or cut some costs. In any software shop there's always too much stuff to do, so setting priorities on stories or tasks is a must.

Another responsibility of the manager is to provide me some help on difficult tasks by assigning an additional person (just one!) to the problem, that has complementary skills. And finally, the manager's job is to track what our team gets done, and remove blockers (never have been waiting on other teams or external organizations?).
Ths the bad manager is the one that tells you how to work; the mark of the good one is instead that he defines expectations and goals, but has you rely on your own intelligence for accomplishing the task.

For example, I am currently introducing regression tests over a large component of a legacy codebase. I got some fundamental help in prioritizing the areas to get to the most problematic ones first, in defining the list of tasks to do and in setting a time frame for achieving them.

The leader I want

Leadership as defined by Kotter is different. A leader:

  • sets a direction for the project. When you are drowning in firefighting and small tasks, he steers the team in the right long-term direction. He tells you what are the principles you should care about while writing every single line of code.
  • Alignes the team with the external stakeholders, like the accountant who wants new reports or the company you're selling to.
  • Lets you find your motivation by showing the good things you and the team can make together.

Too much time the supposed leaders give the support of the team members for granted: but I assure you that in a functional (as opposed to disfunctional) situation you feel refreshed from reporting to a leader, and not worried about what is going to happen next and how you'll deal with the new issues.

The leader is the one that sees that you will be able to implement Lean Startup techniques even if now you're in the legacy code muddle. He believes in the project and transmits you his motivation.

Master developer

The Poppendiecks also define the master developer as the software designer that rises from the team to assume responsibility for the architecture of the project. It is a different aspect of leadership, and one that I am familiar with.

Master developers tend to emerge in a team during development, and they become the go-to guy for questions on the more correct direction to adopt. Don't be afraid to be of service for your colleagues if you are the most familiar with the project and can conjugate the needs of external (customers) and internal (developers and maintainers) quality.

Software development leaders will not flourish in an organization that values process, documentation, and conformance to plan above all else. -- Lean Software Development: an Agile toolkit

If your team assumes the right expectation, you can move from considering the established process as the go-to guy to label a real person. That gives you all the benefit of having an intelligent being in charge instead of a master plan made months ago and fitted inside a board copied from some book.

Conclusions

There are different roles at play in team: that of developers, managers, leaders, and even master developers when they emerge. Each is important in its own right - of course scaling down and up with the size of the project.

If you're a developer, form new expectation on what you need from management to do the best possible job for the company and achieve the maximum satisfaction for yourself. If you're on the other side, take a look at the Lean books as they give you a preparation different from the classical one. :)

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)