Retrospective on an agile project

Yesterday I finished my 5 week project. I still can’t believe it’s been 5 weeks, it’s gone so fast.I wrote a bit about it a couple of weeks ago. And now that it’s finished I wanted to reflect a little on how it went. This, of course, is part of the agile process. They call it a retrospective, and in theory you do one every iteration to consider what worked, and what didn’t. Since my iterations were just one week long I didn’t write anything down for each one.

One thing I said in my previous post is that I wouldn’t work long hours to achieve results, as it is unfair on future projects to misrepresent what can be done in the time. Almost the day after posting that I found myself breaking that rule.

I worked several long evenings, but I have an excuse-ish. One of our big problems was getting a system set up so that we could start on some of our tasks. But it gave us enormous problems, and I was tired of burning days on what should have been a couple of hours of set up. So I started working into the evening in the hopes of putting us back on track. Regardless it still took almost 2 weeks to get a system we could use. This was incredibly frustrating and I broke my rule because I didn’t consider the task part of what the project had to achieve. It was just a pre-req. But an important reminder that sometimes the things that take the longest are things you don’t even officially plan or size. I should have taken half a day at most, but it burned more like eight and a half.

I also broke my rule for another reason, perhaps one I should have factored in. We often needed to work with a team in the US, specifically with us raising questions or problems, and getting responses. To that end I joined a weekly conference call from 17.30 till 18.30. I also found it was better to check e-mail into the evening, since it was the difference of responding to a question and getting a second response by the next day versus finding the question the next morning. It’s easy to burn through days bouncing question/answer/question back and forth at a rate of one request/response per day. The conference call helped to speed things up. However the reality of relying on a team in another timezone is that you make faster progress if you spend more overlapping work time.

The common theme to these two rule breakers is things that felt unrelated to the *work*. Just stuff we needed to be able to get on with the doing. That said I need to remember in future to factor this stuff into short projects.

In terms of project results, I have mixed feelings. We failed to achieve all I wanted. However, I did achieve the major strategic investment I wanted. I never expected to be ‘done’ in 5 weeks. Just to have kick started it enough that it becomes a long term commitment to the direction. Although my project is over, most of the team will continue. Everyone agreed that we were going in the right direction, and we did enough to convince people that it *can* work.

I’m very happy about achieving the important attitude shift, and establishing the relationships necessary to succeed in the long run. At the same time I’m very frustrated by some of the things we didn’t achieve already which I feel we could have.

For me personally a big part of the project was trying to lead. My natural instinct when people aren’t doing what I’d like, is to wish I had the AUTHORITY. You know? That feeling that it would be easier if I had been bestowed with power such that people must do as I say. Perhaps this is what attracts people to management. To have that explicit power defined. However, I do not want to be a manager. So the trick for me is trying to lead with no explicit authority. And boy can that be frustrating!

I feel I had a particularly challenging crew. On previous projects I’ve worked with keen, enthusiastic people. Willing to listen and discuss. Ultimately accepting the group decisions, and working furiously towards the agreed goals.
This project could not have been more different. One person in particular had very specific views on what they wanted to do, and how. Whilst this fit with what was necessary that was fine, great even as they made great progress. But they would sometimes decide randomly on another priority. They totally didn’t get the idea of agile and committing to deliverables for this iteration. On one particular occasion when I asked on a Monday about getting started on one of our committed items, I was told ‘I’m not going to look at that this week’, other times I asked for where they had gotten to, and what was blocking progress. Only to be deflected with questions about other things. The attitude being that their tasks were none of my business, they didn’t want to explain the problems or the specific progress. They just wanted to be left alone for as long as it took to do it, their way.
On one occasion I got the Instant Message equivalent of being hung up on. Rather than answer my question I was told ‘I need to concentrate’ and they logged off.

It would be easy to say that person was just difficult, and in future I’ll only work with easier people. But of course I realise I have to learn to get the most from people like this. Perhaps I should have been more direct and just asked ‘ why don’t you want to tell me what the problems are?’

In that regard I feel I did badly as a leader. However in other regards I was getting better. One of my problems as a techie is that I come up with the solution I want, and I try to get people to do it my way. For this project I made a conscious effort to define the result I needed, and accept solutions that weren’t ‘my’ way, so long as they would meet the requirements. Sometimes this means watching something take longer than I think it should take. But maybe that’s just because the solution will be better?

So I still have much to improve on. That said, I was explicitly thanked by the manager in charge of the project for my leadership. So it can’t have been all bad 🙂