I've written before about how Agile Teams Must Be Empowered.

This blog post about Shared Leadership from Leading Answers highlights 9 things teams need, to bring about a successful outcome at work.

See below...

1. I know what I am expected to do and why it needs to be done
2. I want to do it
3. I have the ability to do it
4. Someone who matters to me will notice if I do it
5. I know how well I’m doing it
6. Processes help me do it
7. I have the resources to do it
8. The environment is right
9. I can do better next time

I love the simplicity of this list.

Leadership and empowerment, in a nutshell.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...



Photo by Damork

read more

I saw this post about Agile Managers? on the Agile Chronicles blog, and to be honest I found it a bit irritating.

It mentions the notion that self-organising teams could go so far that managers are not needed. It asks why a manager would want to do agile if it might put them out of a job, and raises the question, what will we do with all the spare managers?

In some ways I guess the comments are just meant to be light-hearted and are making a valid point. Basically that we still need managers, but maybe a manager's role is different in an agile environment; perhaps more of a support role for the team.

That's fine.

But the idea that managers might not be needed in an agile environment... I think in any organisation, this concept is bizarre.

Comments like this can sometimes make agile seem like some sort of developers' uprising against the establishment. Personally I think agile is great. And I don't think comments like this are helpful to the reputation of agile, or its growth in the mainstream.

Don't get me wrong. I do agree that agile teams should be empowered.

It's an important principle. And one of the first things I posted in my series about 10 Key Principles of Agile Software Development.

I also think it's right that agile teams should be self-organising. But self-organisation is not boundaryless. Managers help teams to be self-organising within the constraints of their organisation.

And all teams need leadership. Ideally, inspirational leadership. Although leadership can take many forms, and emerge from anywhere in the team (not necessarily from managers), the appointed leaders (i.e. managers) must ultimately take responsibility for the team's leadership.

In agile development, managers are definitely still needed. There are so many organisational issues and activities that must be considered that have a much wider span than the team itself. Budget, contracts, recruitment, performance management, suppliers, strategy and direction, policies, responsibility for delivery and quality, communication with stakeholders, and many more.

What I do firmly believe, though, is that agile managers need to turn their thinking upside-down.
Kelly.

P.S. Click one of the icons below to join the growing community of people reading this blog by RSS or by email...

read more

Building people's commitment to anything new, or to any significant change, is something that takes time and happens in distinct stages.

Selling agile development is no different.

As a change leader, you need to recognise this and understand the stages people go through.

You need to take proactive action to identify who is at what stage of commitment, and address it accordingly.

This a critical success factor in change management.

First, there is no awareness of the problem or opportunity. There must be contact to generate the initial awareness.

Then there is a period of confusion, which must be addressed by helping people to understand the change.

My presentation about key agile principles could potentially help with the communication for the above two stages.

Then, there will possibly be a negative perception, which may be based on valid concerns, false perceptions, or possibly based on fear of the implications. Now you must sell the need for change and the positive implications, in order to generate a positive perception.

Otherwise they will make a conscious or unconscious decision not to implement the change.

They will then go through a period of 'testing', where they are establishing and assessing the validity of the change and its impact. Here they must be supported in order to avoid losing their buy-in at this stage.

Only then will they move into the stage of adoption. At this point the people who need to implement the change need to be educated. My presentation about how to implement Scrum might help with this stage. This is a good time to consider formal training.

And only then, after extensive implementation, will the change be institutionalised.

So, when selling agile (or any other change), as well as identifying the need for the change and the implications of implementing it, you must also pay careful attention to the process of selling the change to all key stakeholders.

Identify whose commitment is needed - not only to get approval to adopt the change, but also who is needed to implement it, and make it work in practice. Set out a clear communication plan, to ensure you gain and retain their commitment throughout these stages, until the change is successfully institutionalised.

If you want to understand more about these stages of building people's commitment, see here - change management expert and author, Daryl Connor.

read more

One of the key principles of agile software development is that agile teams must be empowered.

In Scrum, an agile management methodology, this is known as 'self-organisation', or 'self-organising teams'.

The concept is that the team is given full responsibility for delivery and the management role on the team, known as 'ScrumMaster', is a facilitator role.

The ScrumMaster is responsible for orchestrating and enforcing the process (i.e. Scrum), and removing any impediments that hinder the team's progress.

For some, this is management. For others, management means telling people what to do and how to do it.

In reality, I think all teams benefit from this kind of light management style. It's empowering for team members. And, in my experience, empowered teams are more motivated and deliver better results. However - empowered teams can also take the 'wrong' direction. And to avoid this, a manager must coach and guide, and on occasions enforce a particular direction.

Self-organising teams are likely to have a much narrower view than their managers, who have broad exposure to all sorts of operational and organisational issues. They may also take a route that is contrary to important company policies. They may unknowingly take a route that has legal implications. They may take a route that suits the team and their current project, but is completely contradictory to some wider or longer term organisational goals.

So, whilst I believe strongly in servant leadership - believing that managers need to turn their thinking upside-down - self-organisation is not boundaryless!

What's called for, is a fine balance between empowerment and direction. What's called for, is inspirational leadership, .

See also:
20 qualities of an Agile leader
Managers need to turn their thinking upside-down
Agile teams must be empowered
10 key principles of agile software development

read more

Teams of all natures - agile software development or otherwise - need inspirational leadership to perform their best.

That leadership may, or may not, come from the organisation's appointed leaders. But all teams need it, nevertheless.

So what are the qualities of inspirational leaders?

1. Strong communication – storytelling and listening
2. Passion for learning and intense curiosity
3. Focus on developing people
4. Having fun and very energised
5. Strong self-belief, coupled with humanity and humility
6. Committed to making a significant difference
7. Clarity of vision and ability to share it with others
8. Dogged determination and often relentlessness
9. Strong focus on priorities
10. Not afraid to show some vulnerability
11. Regular use of reflective periods to think and learn
12. Real passion and pride in what they do
13. Confidence and trust in their teams, giving them real empowerment
14. Respect for all (team members, temps, customers, suppliers and directors alike)
15. Clear standards of ethics and integrity; openness and honesty
16. Ability to drive, inspire and embrace change and continuous improvement
17. Positive attitude at all times and an innate ability to be diplomatic in any circumstances
18. Lateral thinking and ability to find innovative ideas and solutions to problems
19. Ability to inspire and motivate others
20. Willingness to take (calculated) risks

These are qualities that differentiate good leaders; people others would be willing to follow.

These are also qualities of 'servant leadership'. An admirable leadership style that is particularly emphasised in agile software development methods.

How many of your team - or appointed leaders - demonstrate these qualities; the qualities of inspirational leadership?... and if you work for me, please don't answer that :-)

See also:
Agile managers need to turn their thinking upside-down
Agile teams must be empowered
10 key principles of agile software development

read more

Managers in agile development need to turn their thinking upside down.

read more

An Agile Development project team must include all the necessary team members to make decisions, and make them on a timely basis.

Active user involvement is one of the key principles to enable this, so the user or user representative from the business must be closely involved on a daily basis.

The project team must be empowered to make decisions in order to ensure that it is their responsibility to deliver the product and that they have complete ownership. Any interference with the project team is disruptive and reduces their motivation to deliver.

The team must establish and clarify the requirements together, prioritise them together, agree to the tasks required to deliver them together, and estimate the effort involved together.

It may seem expedient to skip this level of team involvement at the beginning. It’s tempting to get a subset of the team to do this (maybe just the product owner and analyst), because it’s much more efficient. Somehow we’ve all been trained over the years that we must be 100% efficient (or more!) and having the whole team involved in these kick-off steps seems a very expensive way to do things.

However this is a key principle for me. It ensures the buy-in and commitment from the entire project team from the outset; something that later pays dividends. When challenges arise throughout the project, the team feels a real sense of ownership. And then it's doesn't seem so expensive.

See also:
10 Key Principles of Agile Development

read more