A few days ago I cleared the case for Dialing the Manifesto. The bigger picture is indeed context-driven methodology construction. For this I will borrow some ideas from the Context-driven Testing school and from Alistair Cockburn’s Just-in-time methodology construction.

When is context-awareness unncecessary?

Some months ago James Bach challenged me in a personal exchange with the question:

Can you think of situations where being mindful of your context is unncecessary? Give me three examples.

Here is the essence of the three situations:

• When you need trained reflexes, i.e. sports or emergency situations.
• When someone else takes care for context-awareness, i.e. in a teacher-student relationship or under bad management by “Tell, don’t ask” (yes, I did say this)
• When your context is never changing, i.e. in assembly line production.

What is context-awareness?

As can be seen above, these situations do not relate to software development. In fact, we have to deal with changing requirements, changing perceived quality criteria from our customers, people working in those projects and beside that some technical problems as well. Putting all this together we still need to understand the business domain in which we’re going to apply our software and find appropriate models in terms of code, tests and even checks. In addition there is also some variability flowing into the development project, which can just be steered indirectly if it can be steered at all.

While the context-driven school of testing teaches to be aware of the context in your testing, I would expand the message to project management as well. In fact, Alistair Cockburns method to construct a methodology just as you need it in your current context is exactly what most companies need. There is a large variety of factors flowing into each software development project, and I sincerely doubt that there is a best practice of a methodology or process to follow for each and every software development company on the planet.

What we can do instead is dive into the company, seek the values of the workers in there and help them find out how to best develop software in their given context. Sounds like a good consultant brought, doesn’t it? Well, I wouldn’t say so. Personally I think a project manager needs to know the same things for each and every project. Since every project unfolds over time in different ways which are mostly unpredictable, project management or – better – project steering therefore should be able to encourage the people on the project to find their way of working. Sounds like leadership? To some degree my perception of the concepts of consultant, project management and team lead blurs here. Clearly, I resist to distinguish between them.

Tyrant or democracy?

In my Latin lessons in school I learned that there are three basic variations of leading a state: mnoarchy, aristocracy and democracy. These are the positive, well-lead forms. The negative ones are tyranny, oligarchy, and anarchy. Platon claimed that the models how a state is lead is in a fluent shape. From a great king or ceasar sometimes a tyranny is raised. After some riot the aristocracy is installed. Over time this might degenerate to oligarchy, before democracy takes over enging in an anarchy, which may be ended by a monarchy. Then the cycle begins anew.

While this is a pleasant model for state leadership, it is not an appropriate model for leading highly educated technical people in a software development company.

Telling highly educated people what to do is a problem. (Mary Poppendieck)

Instead of having a tyranny or an oligarchy, the people in the project need to be able to decide upon their course. Of course they will make mistakes. This is how human learn. By bringing in regular feedback cycles and giving honest feedbacks about their course, they will be able to learn. By installing blaming or placating messages in these reflections you will make sure that people may start playing hot potatoe on your project, hiding as much information from your discover as possible. In order to get a healthy project back you need to install trust and help people articulate their fears and problems honestly. You need to be aware of their context to realize their problems, though.

Management or accompanying?

A well running project does not need to be managed. It needs to be accompanied. Make sure that obstacles from the work get removed immediately and people get enough time to work focussed. I never claimed that it will be easy to do this. Sure, there will be hard times. The down-side of the managing approach is honestly said command and control leadership, for which I wouldn’t have needed to study computer science at all.

After the people

After you made sure to get well with your stuff on the people-side the next context to spent efforts on is the interrelationship between your team and the outside world. This may be the customer, who will get the product. This might also be other teams in the organization such as maintenance programmers and service desk people. In fact, after the people is before the people. Since you have human interrelationships to handle here as well, you will not be able to relax and get back to technical work too soon.

Finally…

Finally, things will become technical. Don’t forget that just five percent of your work as a project lead or manager are technical. Most of the time you need to coordinate people, make them talk to each other, setup communication channels and help them raise their concerns and remove their obstacles. After finishing this there will be little time to deal with the latest technology. You will be glad to focus on your current picture of the implementation as it is fit to the customer requirements, which are changing. This does not have to bother you. Though you might come from a more technical background, you have to refuse to jump too deep into it. Don’t forget: As a manager, the people are your work, not the technical realization.

I hope this write-up might help project managers and team leaders focus on the right things first, and second on the technical side while reading through them.