Skip to main content

Situational Leadership in Agile

For anyone line managing as well as performing technical leadership, the term situational leadership may have come up in an HR lecture you really don't care about! Join the club.

However, this was once explained to me in terms that really struck home to me and is something that I have learned the hard way in my teams.

Agile works because the team is empowered to succeed - to a certain degree a lot of responsibility is delegated onto the team.

Situational leadership is the theory that there is no right way to manage - but effective leaders effectively bounce between styles. The styles are:

  • Telling/directing - the leader tells subordinates what to do.
  • Selling/coaching - the leader sells an idea so that subordinates will do it.
  • Participating/supporting - the leader will work with subordinates to get the desired outcome.
  • Delegating - subordinates are essentially able to pick up the work themselves. 

At its most effective, Agile works when most of the team are at the delegation stage. The team responds well to the responsibility and will work efficiently and take ownership of their tasks. This however can cause conflicts when the leader suddenly treats subordinates at the tell or sell stage. Why does he/she no longer trust us to do this work? 

This can usually be explained as either of the following reasons:
  1. The work is urgent and the leader needs to get involved closely to ensure it is done.
  2. The work is new or a change in direction in the team, and the leader needs to explain to the team why we need to make the changes. 
What I have learned the hard way is that you need to explain to your team this model so they understand why you are no longer delegating this specific task. If you can explain to the team you are currently at the stage where you need to tell for some reason, explain you are in the tell stage, why, and that normal service will be resumed soon and it will switch back to delegate. I find teams respond well to this and it removes any tension or hurt feelings in the team. 

Another thing that it's vital to remember as the team are acting in the delegate stage is that ultimately you are responsible. This means that even though you trust them to do the work, you need to take responsibility for it and that to do that you need them to report back with what they are doing and why decisions are made. Explain the situational leadership model to them and they will appreciate this. Reporting back to you helps you defend their decisions if they are questioned. 

The Tannenbaum and Schmidt's leadership model is a slightly different visualization of situational leadership but it explains the delegation/responsibility issue above really well.

Note that in the top right, the line never reaches the top right. That is because no matter how much you delegate, you as the leader/scrum-master/development manager are always responsible. Again explain this to the team and it will help resolve any conflicts.


Popular posts from this blog

Managing programmers and the programming mother******* mentality

I came across the following great site on Stumbleupon today - - and as a developer had a great laugh before realising that in my day job I'm really the guy the site is having a swipe at!

The site aims it's gun firmly at the door of managers, whether they practice agile, XP, Scrum, waterfall etc and pokes fun at the agile manifesto:

Whilst the site may be a bit tongue in cheek (obviously taking inspiration from Pulp Fiction), a huge challenge of managing developers can be the fact they can see you as a roadblock in the way of them producing code. Ultimately you are responsible for the success or failure of a project and as a result you have probably applied a process to the team to help you ensure your team are progressing in the correct direction. So how, as a manager, can you break down this perception from members of your team who have this mentality?

Before I start, I'll confess when I started my first programming job I agree 100% with the se…

Integrating Google Analytics into existing Android app

Analytics are key to measuring the success of your project or application and are a great way of identifying your users trends and demographics. Have you released an app and wondered who your users actually are? Well with analytics you could find out where your users are situated, what ages they are etc. The leader in this field is Google Analytics - this can be embedded into your mobile application, website and even your blog.

After a few frustrating attempts at integrating Google Analytics into an existing app I thought I should post a guide on how to do this.

1. Download the Google play services library and add it to your project.

You can do this by right clicking on the project you want to add analytics to in eclipse, choosing properties and then the Android tab. In the Library section, select Add and choose google-play-services_lib and select Apply.

2. Add the required permissions to AndroidManifest.xml.


Android - Could not find HelloWorld.apk! - fix

So my first experience of Android development left me frustrated after getting an error trying to launch the  simple Hello World example!

Simple fix - basically when I set up eclipse I forgot to set the JAVA_HOME path variable.

The symptoms are this in the console:
[2011-12-12 22:37:05 - RoryHelloWorld] Android Launch! [2011-12-12 22:37:05 - RoryHelloWorld] adb is running normally. [2011-12-12 22:37:05 - RoryHelloWorld] Could not find RoryHelloWorld.apk!
The fix is simple. Open up your machines environment variables (in Vista it's Control Panel -> System -> Advanced System Settings -> Environment Variables).

In System Variables add a new variable JAVA_HOME set to where your JDK is installed, e.g.

JAVA_HOME=C:\Program Files\Java\jdk1.6.0_12\
Then add JAVA_HOME to your Path variable. I added:

%JAVA_HOME%\bin;%PATH%; to the end of mine
Restart eclipse for the changes to take effect, then the next time you run your app it should work!