“A leader is a person who assists a group of people become a self-organizing, self-managing and self-sustaining team so that he/she no longer has to be a leader for that group.”

This is an interesting definition in contrast to the wikipedia one:

House defines “leadership” organizationally and narrowly as “the ability of an individual to influence, motivate, and enable others to contribute toward the effectiveness and success of the organizations of which they are members”. Organizationally, leadership directly impacts the effectiveness of costs, revenue generation, service, satisfaction, earnings, market value, share price, social capital, motivation, engagement, and sustainability. Leadership is the ability of an individual to set an example for others and lead from the front. It is an attitude that influences the environment around us.

Read more: http://en.wikipedia.org/wiki/Leadership

Pitching Agile to Senior Management – This inability to articulate to senior management why they should adopt agile techniques is ironic considering our focus on communication. Ambler’s experience is that management is often very willing to become more agile if you’re able to describe to them the costs and benefits in an understandable and meaningful way.

Read more: http://www.ddj.com/dept/architect/199300107

• Levent’s 10 Mistakes in Transitioning to Agile (10/2006)

To implement Agile processes and minimize business disruption, Ross Pettit (thoughtworks) advocates that IT organizations focus on three primary goals: achieving “completion integrity,” providing meaningful transparency, and removing underlying organizational constraints.

Shaping an Agile process that delivers value is not a selection of prescriptive actions. It is a conscious effort to fit and mature best practices in an environment. Three core questions guide this process:

• What will provide sufficient completion integrity for the work we do?
• What will create meaningful transparency of the work being done?
• What are the underlying organizational constraints that will impede changes in the way work is done?

• Ross Pettit’s Key Success Factors in Top-Down Agile Adoption (03/2007)
• Ross Pettit’s Enabling Global Business Success (07/2006)

And now the best news:

Thanks to Boris Gloger who held the Scrum Master Training in Zurich, May 2007 .

It were 2 wonderful days learning new thoughts on Scrum.

So i am prepared for my future without traditional project management methods.

I am now a Certified Scrum Master.

1. Focus on collaboration over documentation. “Agile architects” are … not simply people who document their vision and hand it off to developers.

2. Prove it with code. Everything looks good on a whiteboard, or in a modeling tool.

3. Keep it simple. Agile software developers model … in ways which are very different than traditionalists.

4. Use the simplest tools. … free form diagrams, … simple sketches …

5. Think through the big issues up front.

6. Think through the details just in time. … “model storm” focused issues on a JIT basis.

7. Allow good architectures to emerge over time. … the fact is that the details will emerge as your system evolves to meet the changing needs of your stakeholders.

8. Travel light. Remember Agile Modeling’s They Ain’t Gonna Read It (TAGRI) advice.

9. Have a few overview diagrams. Just like a road map overviews the organization of a town, your navigation diagram(s) overviews the organization of your system.

10. Be flexible. … the nature of the project will help to define the types of views that you should consider creating.

11. Display models publicly. Distributed teams find that a Wiki with snapshots of diagrams and point-form text works well.

12. Take a requirements-driven approach. Your architecture must be based on actual requirements put forth by your stakeholders, otherwise you are “hacking in the large.”

13. Model with others. By working collaboratively you will create a higher quality product, will develop a shared vision, and will learn from one another.

Managing is about systems and processes and resources; leading is about achievement and vision.

— Peter McDougall

You can’t control what you can’t measure.

-Tom DeMarco

Software is a thought process. To patent it is comparable to patenting induction or deduction.

—Tom DeMarco

I have never met a man so ignorant that I couldn’t learn something from him.

—Galileo Galilei

The most beautiful thing we can experience is the mysterious. It is the source of all true art and all science. He to whom this emotion is a stranger, who can no longer pause to wonder and stand rapt in awe, is as good as dead; his eyes are closed.

—Albert Einstein

2. Keep management in the dark. The people actually doing the work have the skinny on what’s going poorly. We know when the server is overloaded, the screen shots used in training don’t match the application, or the data model doesn’t conform to enterprise standards. That knowledge gives us real power. Just keep all those juicy tidbits to yourself, and watch management scramble as the project falls apart, apparently for no reason at all!

3. Keep your customers in the dark. Putting blinders on your customers is even more effective for killing a project than spoofing managers. Don’t tell users or customers anything, especially about your deliverables. Don’t let them see anything until the last possible second, and then make sure it’s too late in development to change anything. Codify this strategy across your program by selling it to management as the best method of controlling user expectations.

4. Don’t document anything. This is one of the most subtle and insidious methods of killing a project. Take advantage of human laziness- urge people to do the fun stuff and not to worry about documentation; say “we’ll get it later, after we’re done.” Then as the natural process of project turnover occurs, enjoy the fun of watching new team members struggle to figure out what their predecessors accomplished or how they arrived at certain decisions.

5. Don’t train or allow for training. This strategy is doubly effective, because you can de-emphasize training for your project team, and this will lead to a consequent dearth of training for your users. Say things like, “you can read a book and pick that up in a weekend” or, “we don’t have the budget for that class right now; let’s wait until later” or, “our customers are savvy enough to pick this up without a guide.” (With project members, however, the best thing to say is “Training? I thought we brought you on the team because you were already qualified!”)

6. Don’t use the best technology for the job. Convincing your teammates and managers that the best-fitting technology is unnecessary can be a very efficient way to ruin a project. Think chewing gum and baling wire-build an enterprise-wide, high-volume, heavily used knowledge management system with an MS Access back-end. Or manage documents destined for multichannel publishing using WordPerfect and the LAN. Kludges always eventually fall apart, sometimes even before the first scheduled rollout.

7. Change project scope frequently. This is hard to achieve unless you’re a manager, but a scope shell game can bring a project to its knees—change early and often. Customers, consultants, integrators, developers, tech writers everyone hates working on a piece of the puzzle only to discard or significantly change their work because of a sudden, inexplicable change in scope.

8. Control scope pathologically. Oddly enough, overmanaging scope can be as effective as undermanaging it. A great example is finding a “hidden” key business need during an evaluation and choosing not to address it because “it’s out of scope” even if it’s easy to fix. Then publicly throw the responsibility for managing the core need back on the customers and watch them rebel.

9. Start writing code before gathering requirements. Unless management is really on the ball, this is a piece of cake, and the less developers know about the goal, the better. Get as many sexy features as you can up and running as quickly as possible. In just about every case, the person who creates a neat interface, training document, or data model has to throw out nearly everything once real requirements are gathered. And redoing the effort often throws the project off schedule significantly, which usually leads to the project death you so desperately desire.

10. Hire great people and micromanage them. While this technique is way beyond the average worker bee, and requires some finesse to achieve, I’ve seen it often enough in practice to know that it is far-and-above the most effective way to kill a project. If you can set up an environment in which every team member is afraid to make a decision without management input, you’ve achieved project-killing Nirvana.

Note: Article was original written by Robert H. Wallace in 2006.