Crazy about management? You should try some Agile!
I might be the only Agile coach who writes about management. Who doesn’t automatically dismiss management as the mother of all evils. Maybe personal frustrations, failures or traumatising experiences is making us look at management as something old-fashioned but doing Agile today maps quite well on what management theory proclaims.
Out the multitude of management experts, we’ve picked Henri Fayol’s management functions as a framework for doing Agile. Fayol is famous for defining what management is supposed to do: planning, organising, commanding, coordinating, controlling. Sounds familiar? On one side or the other, we’ve all been there.
And now let’s see how Agile fits into this picture.
Planning. Yes, we do plan in Agile. Probably even more than in traditional methods. A few things are different though: short-term more detailed planning, longer-term more general. Any everybody has a say in the planning: not just customers or managers who mistrustingly impose crazy deadlines on the team but everybody has an input. Because everybody can have a point of view that could be very valid. This is where empowerment comes in. You empower the team so they decide about the planning details they know best: tasks, work, complexity, etc.
Organising. Agile teams don’t need somebody to organise them, they are self-organising. They know what they have to achieve, they are committed and motivated so they contribute towards achieving the objectives that they set for themselves. Being cross-functional helps because you have fewer external dependencies so less need to external organisation.
Commanding. Nothing kills agile like a “command-and-control” way of working. It might not be “commanding” but somebody wants needs the team to build the product. And that is the client who is not commanding but rather provide explanations about why the product is needed, what are the benefits and works with the team to express the requirements as user stories so the team understands why the client needs them. There’s no need to command someone to do something is you explain to them how their value-adding work helps you achieve some benefits.
Coordinating. The team knows the best the details and subtilties of their work so they are able (and very competent) at coordinating themselves through face-to-face communication, daily stand-ups and information radiators. Furthermore, the team consists of generalising specialists who are able and willing to help each other when there’s a blockage and can overcome obstacles.
Controlling. Probably nothing says management like controlling. Agile is actually based on inspections which means the team will take any opportunity is has to inspect the progress and make the right adjustments. It is controlling but it is not top-down control. It’s peer-control which is much more efficient and realistic. The team is motivated to do these things on their own which leads to trust.
This was an exercise about openness. About trying to understand different approaches and how they might not be so different after all.
Florian Ivan, Agile Project Management Expert.
Crazy about management? You should try some Agile!
I might be the only Agile coach who writes about management. Who doesn’t automatically dismiss management as the mother of all evils. Maybe personal frustrations, failures or traumatising experiences is making us look at management as something old-fashioned but doing Agile today maps quite well on what management theory proclaims.
Out the multitude of management experts, we’ve picked Henri Fayol’s management functions as a framework for doing Agile. Fayol is famous for defining what management is supposed to do: planning, organising, commanding, coordinating, controlling. Sounds familiar? On one side or the other, we’ve all been there.
And now let’s see how Agile fits into this picture.
Planning. Yes, we do plan in Agile. Probably even more than in traditional methods. A few things are different though: short-term more detailed planning, longer-term more general. Any everybody has a say in the planning: not just customers or managers who mistrustingly impose crazy deadlines on the team but everybody has an input. Because everybody can have a point of view that could be very valid. This is where empowerment comes in. You empower the team so they decide about the planning details they know best: tasks, work, complexity, etc.
Organising. Agile teams don’t need somebody to organise them, they are self-organising. They know what they have to achieve, they are committed and motivated so they contribute towards achieving the objectives that they set for themselves. Being cross-functional helps because you have fewer external dependencies so less need to external organisation.
Commanding. Nothing kills agile like a “command-and-control” way of working. It might not be “commanding” but somebody wants needs the team to build the product. And that is the client who is not commanding but rather provide explanations about why the product is needed, what are the benefits and works with the team to express the requirements as user stories so the team understands why the client needs them. There’s no need to command someone to do something is you explain to them how their value-adding work helps you achieve some benefits.
Coordinating. The team knows the best the details and subtilties of their work so they are able (and very competent) at coordinating themselves through face-to-face communication, daily stand-ups and information radiators. Furthermore, the team consists of generalising specialists who are able and willing to help each other when there’s a blockage and can overcome obstacles.
Controlling. Probably nothing says management like controlling. Agile is actually based on inspections which means the team will take any opportunity is has to inspect the progress and make the right adjustments. It is controlling but it is not top-down control. It’s peer-control which is much more efficient and realistic. The team is motivated to do these things on their own which leads to trust.
This was an exercise about openness. About trying to understand different approaches and how they might not be so different after all.
Florian Ivan, Agile Project Management Expert.