Individuals and interactions over processes and tools

So reads the first line of the Agile Manifesto. Agile (and Lean) frameworks differentiate themselves from traditional software project management in the value that they place in people.

I’m always confused when I people attempt to separate out line and project management in the context of software. To me they are intrinsically linked, and cannot meaningfully be considered in isolation. In fact I’d go so far as to say that one of the principle drivers of the agile movement is not so much what it says about project management, significant as that is, but more what it says about motivation and simply letting smart people get on and do their jobs.

As an illustration, I’d like to use Martin Haworth’s ‘Ten Tips About People Management’ as a representative article of a more general approach to people management. For each point I’ve highlighted how it is commonly addressed in the context of an agile team.

1. Talk to Your People Often
By building a great relationship with your people you will bring trust, honesty and information. This gives you a head start in Performance Management of your people.

Daily stand ups provide a frequent and regular period to interact with the team. It doesn’t provide one on one time but it does mean that raising impediments and sharing of ideas is common place such that it then feels much more natural for one on one conversations to occur.

2. Build Feedback In
On the job two-way feedback processes gets rid of the nasty surprises that gives Performance Management such a bad name. By building it in as a natural activity, you take the edge away.

Agile is all about rapid feedback. Both at a technical level in the form of TDD and CI and a personal level through daily stand ups and a commonly agreed definition of done.

3. Be Honest
By being frank and honest, which the preparation work in building a great relationship has afforded you, both parties treat each other with respect and see each other as working for everyone’s benefit.

With lead times measured in days, trust and openness are essential for any agile team, where honesty does not exist the whole process collapses.

4. Notice Great Performance
When you see good stuff, shout about it! Let people know. Celebrate successes and filter this into formal processes.

At a team level daily stand ups and visualisation of work flow provides this for free. Furthermore, since features are delivered in a state ready for production, regular product demos provide the customer with a hands on measure of progress.

5. Have a System
Performance Management is a process and needs some formality – especially for good personnel practice and record. This need not be complicated, but it needs to be organised and have timescales.

Agile frameworks have little to say directly on the subject of performance management, though there is an assumption that team members are continually looking to improve their skills and performance. Agile working models introduce the idea of cadence where there is a period dedicated to retrospection and continuous improvement.

6. Keep it Simple
But do keep it simple. If you have a relationship with your people that is strong anyway, you already know what they are about. Formal discussions can be friendly and simple, with formality kept to a minimum.

With an emphasis on verbal communication, it’s easy to have serious conversations in a relaxed but constructive manner.

7. Be Very Positive
Celebrate great performance! Focus on what’s going well. It’s about successes and building on strengths, not spending ages on their weaknesses – that serves no-one. Go with the positives!

Again, constant feedback through regular delivery of working software, reinforces and encourages good practice.

8. Achieve Their Needs
Remember that we all have needs that we want fulfilling. By working with your people to create outcomes that will do this, you will strengthen your relationships and channel effort in a constructive direction.

Since teams are typically cross functional, team members are exposed to a range of challenges, and have a clearer idea of where they feel they are strongest. While an agile framework does not specifically look to fulfil the longer term needs of an individual, it at least attempts not pigeon hole them into a specific roles.

9. Tackle Discipline
Whilst it often happens, Performance Management is not about managing indiscipline. That has to be managed in a different way. By setting clear standards in your business that everyone understands and signs up to, discipline becomes much, much easier.

In the same way that team success and good performance are highly visible to the team, individual poor performance is also obvious. Expectations of good practice are generally arrived at through team consensus and so could not be clearer. If the expectations are inappropriate or unrealistic then the team has the power to amend as necessary.

10. Learn from Mistakes
As part of regular on-the-job and informal review, mistakes will come to light; things will go wrong. By using the ‘What went well? And ‘What could you do differently?’ format, the unsatisfactory performance becomes controllable and a positive step.

Where teams are correct to take take credit for their success, it is equally important that take responsibility for failure. Examples include retrospectives or Lean style 5 Whys root cause analysis.

Software is an industry not always known for the strength of its people management, by pushing human issues to the fore agile and lean frameworks ensure that not only is the management of of the project considered, but also the management of the people. In a practical sense, while applying agile principles won’t necessarily make me a good manager, they make me less likely to be a bad one.

Jan 242010

Last Spring I attended QCon London, during the course of the conference I attended Linda Rising’s talk entitled Agility: Possibilities at a Personal Level

It was suggested that in the same way agile teams rigorously apply a regime of inspect and adapt, the individual should do the same at a personal level. As an example, she asked why tea and coffee are so prevalent in the workplace and linked this back to the working practices of the industrial revolution. Specifically, that while caffeine was very useful in making sure unskilled workers arrived at the factory on time and alert, she questioned what penalties we incur force fitting these practices onto a skilled craft like software development?

Just to be clear, Linda Rising stood up in front of a room of computer people and said ‘Stop drinking coffee’ and at no point did anyone try and throw her out of the window. So it was a pretty good talk, so good in fact that immediately afterwards I decided to give up caffeine to see how I would react.

Firstly a bit of background. My company supplies free coffee beans and making coffee is a complex and communal ritual, verging on the sacrosanct. The etiquette has been built up over years, and even offers rival schools to subscribe to. We have Wiki pages detailing coffee brewing best practice and it’s no joke to say that my social standing and ability to make good coffee are linked. In short it’s a bigger part of my day than just a caffeine high.

I wasn’t a big coffee drinker by any stretch of the imagination, the coffee was definitely strong but I’d only have two or three cups a day. Nonetheless going fruit tea total came as a bit of a shock.

The first two weeks were pretty miserable, I found that I got very tired towards the end of the day, and where previously I might have stayed late if it meant finishing something off, I was pretty useless after 6pm. I also missed the ceremony and social interaction, sure I still went to the kitchen and brewed my cup of lemon and ginger (or whatever) but the whole process was deeply unsatisfying. I went through all manner of cravings which was strange since at weekends where coffee really isn’t part of my routine I hardly noticed the difference.

After having got through the hard part I started to notice some benefits, while the tiredness was still there, it was much more manageable, and crucially the knowledge that I couldn’t just stay late meant that I was more focussed during the day. I became more disciplined at trying to perform the tasks that required the most energy earlier leaving repetitive, less creative activities for the last few hours. Despite working less hours overall I think that I achieved a similar amount.

A second benefit that sounds silly in hindsight was that I started sleeping much better. As a student I wasn’t a big coffee drinker but I’d always been one to lay awake at night pondering some puzzle or other. So when this behaviour continued into my working life I didn’t consider it strange. Giving up caffeine meant that I had a fighting chance of falling asleep not long after I switched the lights out, which in turn meant I had less need for an early morning coffee.

As an Englishman, it was unlikely that I was ever going to last without tea in the long term. For a start my Nan would have struggled to comes to terms with the change. So after a few months I felt that I’d served my time and now allow myself tea and the odd coffee in the morning, interestingly though I can no longer run with my old coffee pals as the strength of their brew gives me headaches.

So the key points to take away are:-

  • Stopping completely after only a few cups a day led to notable and sustained withdrawal symptoms.
  • Not having the safety net of being able to stay late at work meant that I worked more effectively during the day.
  • Cutting out caffeine in the afternoon made a real improvement to my sleep patterns.