mysite blog

The Role of the Project Manager in an Agile Project

Tue, 15 Sep 2009 00:00:00 +0100

Over the last 6 months or so, I have been attending meetings of the Agile Practitioners Forum. It has become apparent to me from these meetings that there are (at least) 2 distinct camps amonst the Agilistas as I like to call them. One camp believes vehemently that if you do not adopt the practices of a methodology, eg XP, that you can not be Agile. The other camp, and the one I personally subscribe to, views Agile not as a set of practices or processes to be followed dogmatically, but as a culture or mindset.

Regardless of which camp you feel most comfortable with though, there is one question that keeps rearing it’s ugly head – is there a need for the more traditional role of Project Manager in an Agile project?

Some would say that if the team is using Scrum, there is no need for a Project Manager as the Scrum Master will undertake that role. I find this an overly simplistic view though, and what about the agile team that isn’t using Scrum? From my experience, none of the practices of XP actually cover the need for project management. Maybe this is why some people still view Agile projects as having no control?

Before I continue, let me suggest some of the tasks a Project Manager would typically undertake on behalf of the team, then it should become apparent where I am coming from on this entry.

Most importantly to me, the Project Manager will ensure they know what else is happening within an organisation, for example other projects, operational issues, new marketing ideas – all the things that could influence and impact the scope and timescales of the project the team is trying to deliver. Also, the Project Manager will typically sort out procurement of development and test environments and will track expenditure against the project budget. The Project Manager will also, typically recruit the project team and certainly should heavily influence the ethos and culture of the team.

In the ideal world of Scrum, the organisation agrees to leave the team alone for the duration of each sprint in return for a committment from the team to deliver the agreed product backlog items for the sprint. Now whilst it would be brilliant to work in an environment like this, I have never experienced this in the real world of systems delivery. In the real world, teams are asked to investigate and estimate new pieces of work to satisfy that new marketing initiative or to deal with that production issue that has just emerged and will cost the company lots of money.

Whilst I agree that the Scrum Master should be protecting the team in these situations, not all Agile projects use Scrum and not all organisations will allow the Scrum Master to protect the team 100%.

I would suggest that the need for a skilled Project Manager is just as great in any Agile project as for any other project, and that like any other project, the Project Manager’s role is more outward facing than inward. A good Project Manager will protect his team whatever method they are using to deliver. A good Project Manager will also make sure that their team has everything they need to allow them to deliver. A good Project Manager will also make sure that they have a good team in place, and doing this means that the team can be allowed to self organise. A good Project Manager will value the contribution of all team members and encourage open discussion within the team. A good Project Manager will arbitrate in the event that the there is disagreement within the team to give the team a way forward. A good Project Manager does not take credit for the work of the team but ensures that the team get the recognition and credit for successful delivery.

A bad Project Manager on the other hand will be inward facing and will try to micro manage their team whilst paying no regard to the external factors that can affect the team’s delivery. A bad Project Manager will not protect their team. A bad Project Manager will take credit for any delivery the team makes.

Believe it or not, an Agile project without a good Project Manager will be just as bad, if not worse than an team with a bad Project Manager.

When agile coaches go bad

Tue, 22 Sep 2009 00:00:00 +0100

Recently I was managing a large scale agile enablement for a client, helping them to adopt the agile practices of Scrum and eXtreme Programming (XP) across a department of 250 people.

Prior to my engagement, two well respected agile coaches had been brought in to set up and run the first agile project, which was up and running well with the main limitation from my perspective being that they had brought in their own team and were only coaching a couple of the client's staff.

My remit was to transform the software engineering department to use agile methods and this could only be done by changing the way the client's staff were working. Because of the sheer size of the task, several other coaches were engaged to help with specific product streams - again, these were all well respected within the agile community.

When one product stream had achieved its alpha release, I was asked to facilitate a retrospective covering all the sprints that had been run to deliver the alpha release, a task which I always enjoy doing. I decided that with this being a new team, I would encourage them to focus in on 4 main areas during the retrospective - 3 chosen directly by the team with the 4th focussing on the agile practices within the team and where they thought they were in terms of maturity. During the retrospective, the team would split itself into 4 groups and rotate around, each group discussing each of the 4 areas in turn.

This particular product stream, at that time, had 2 well respected agile coaches who were both going around together in the same small group. Given that they were both well known within the agile community I decided to go listen in to their discussion about the agile practices and the level of maturity in the team, and I have to say that quite frankly I was horrified at what I heard.

The first words out of one of the coaches mouths was "well this isn't an agile team", a comment that the other coach agreed with without hesitation. Now forgive me if I am being niaive here but I thought the role of a coach was to encourage people to try new practices and to provoke thought about the value of those new practices when compared to the old practices - and they both knew that this was a new team that was adopting agile practices whilst delivering a project. If you can't at this point see why I was horrified, then you should probably close this window now as I'm not going to explain any further.

My initial thought on hearing the comments of these coaches was "anyone in the team hearing this bullshit is going to be immediately demoralised and this is not what I want to see in this team". Fortunately my faith was somewhat restored by one of the developers who was actually involved in discussing another topic but had overheard the coaches discussion. This guy immediately picked up a whiteboard marker pen and wrote on the board being used by his small group "WE ARE AN AGILE TEAM".

When I did a bit more digging, after the retrospective, it appeared to me that the coaches view of the world was very much "if you're not using the 12 practices of XP, then you're not agile", a view which could easily explain their comments during the retrospective but not a view I could ever subscribe to.

My own view is that a team that can prioritise and apply some of the established agile practices based on what is hurting them the most and is then willing to try new practices but most importantly stops regularly to review the way they are working, what is working well, what is working badly and actually makes the effort to change the things that are working badly for them - well that is a team that is displaying a good agile maturity.

A team that can get itself into the rythm of regularly and frequently delivering production quality code whilst seeking continuous improvement is really the sort of team that I leave behind when I complete an agile transformation or enablement.

And for me - that sort of team will never be created by a team that feels forced to use practices without being given the opportunity to try and fail and through that, find out what works best for them. We are all human and humans do fail. It's much better to fail early when the cost of failure is low and to learn from that failure and that to me is what an agile coach should be encouraging as through that you are more likely to encourage continuous improvement, so my advice to you is that if you ever hear an agile coach say "that's not agile" or "this team isn't agile" - show them the door quickly, or better still, take them out into the car park and put a bullet in their head so that they can't destroy another team's confidence and morale.

Agile Business Conference

Fri, 16 Oct 2009 00:00:00 +0100

I was fortunate enough to present, together with two of my associates, one of the keynote sessions at the Agile Business Conference this week and firstly I would like to thank everyone who attended and provided very positive feedback on our presentation.

During the conference there was also a presentation from a very large IT services company which I found really disturbing.

It wasn't that they openly talked about their projects failing - in fact that demonstrated a degree of openness and honesty that you wouldn't normally expect to see from such a company.

The disturbing bit was that after telling the attendees how agile they were, they then basically said that it had taken them 10 years to come up with the idea of a retrospective (of course I am paraphrasing a bit here).

This was distrubing on several levels:

To me, the behaviour of continuous improvement is critical to the success of a team and the retrospective is the most important ceremony in achieving continuous improvement.

Any delegates who were attending with a view to adopting agile practices might think this is quite normal, and

This company could well be viewed by anyone looking to adopt agile practices as a safe approach.

It also begs the question "have the large consultancies and service providers jumped on the agile bandwagon just to sell more bums on seats?"

The presentation I was involved in presented three real life experiences of teams adopting agile practices and what can go wrong. Our main point was that adopting agile is not easy and is unlikely to succeed without good quality coaching and mentoring from experienced, high performing people with a track record of implementing agile practices. The two presenters from the other company could be really dangerous and set back agile adoption by years.

BCS Oxfordshire Group

Sat, 17 Oct 2009 00:00:00 +0100

I was invited to speak to the Oxfordshire group of the British Computer Society (BCS) last Thursday evening and presented to them on the use of agile methods within a Prince 2 environment. I'd like to thank Dr James Bacon and the rest of the committee for kindly inviting me to speak. I'd also like to thank all those who attended the meeting and made it a thoroughly interesting and enjoyable evening. There were some very detailed and thought provoking questions asked by the group and several people have contacted me since. To all of you, thank you and I'm looking forward to keeping in touch with you and keeping our conversations going.

Do we need an Agile Maturity Model?

Wed, 21 Oct 2009 00:00:00 +0100

Recently a new "hot topic" appears to have emerged - do we need an agile maturity model? There certainly seems to be a view in parts of the agile community that we do need one as various organisations are working to produce one. This however seems to be developing in a very worrying way as I have discovered through my own research into what these organisations seem to be proposing.

What disturbs me is that the proposed maturity models are not measuring outcomes, instead they are measuring process adoption. This is potentially very dangerous for organisations adopting agile methods as they make the process the end goal. I can hear people now saying "well we followed all the right processes, but our projects are still failing. Agile doesn't work!"

The measurement of process adoption as a measure of agile adoption is also fundamentally flawed in my view as it goes against the manifesto for agile software development "we have come to value individuals and interactions over processes and tools".

Surely any agile maturity model should be based on measuring outcomes that demonstrate the values of agility rather than the implementation of processes?

Stand Ups Aren't Agile

Mon, 30 Nov 2009 00:00:00 +0000

<rant>Controversial I know - but that's what I'm here for :)

I'm fed up of hearing people say just how "agile" their teams are just because they do stand up meetings every working day. These people are dangerous and should be taken out into the nearest car park and shot because they just don't get it, they won't open their minds and they give real agile practitioners a bad name.</rant>

Feeling Good :)

Mon, 16 Nov 2009 00:00:00 +0000

A colleague at my current client sent me this link on Friday http://www.oxon.bcs.org/2009/10/19/event-summary-talk-by-iain-mckenna-agile-project-management/ which is a very kind write up of the recent talk I gave to the Oxfordshire BCS.

It feels really good to receive such positive feedback. Thanks again guys :)

The Agile Hoff

Fri, 11 Dec 2009 00:00:00 +0000

I'm not sure whether I should be happy about this or not but having met up with some excellent, pragmatic agile friends for a few drinks on Wednesday evening, I was told by one of them on Thursday that they had decided that I was the "Agile Hoff". The only justification for this was my leather jacket. Now I have really mixed feelings about this because on the one hand, when I was very young I did like Knight Rider, but on the other hand, Hoff is definitely naff now. What do you think?

Project Success Merchandise

Fri, 11 Dec 2009 00:00:00 +0000

I've now had a couple of people ask me for their own Project Success polo shirts. Obviously I think they look good - otherwise I wouldn't have had them made in the first place and I am going to get some more made for the people who have requested them. If I get any more requests I might even have to consider selling them through this site :)

Low Cost, High Value

Fri, 18 Dec 2009 00:00:00 +0000

I recently started working with a new client and had a very rewarding first day with them. The approach I took with them was designed from the outset to demonstrate the agile approach of delivering early value.

I did this by firstly giving them an overview of Scrum and XP and then facilitating a retrospective of their current software delivery processes and practices.

I find this a great approach to take with new clients as it gives them a relatively low cost (1-2 days of my time, plus their time and appropriate meeting facilities), but allows them to achieve very early value (and return on investment) by starting to make some improvements based on the outcomes of the retrospective.

If anyone else is interested in this high value, low cost approach to investigating whether agile practices would be beneficial to them, please get in touch.

The Joys of Life

Sat, 19 Dec 2009 00:00:00 +0000

Or more appropriately, the joys of being a jobbing consultant. As I sit here on a client site in Leeds, looking at the snow and thinking 'great - I only have to drive 150 miles to get home tonight'. And of course I'll be back here next week too.

The Joys of Life - Part 2

Sun, 03 Jan 2010 00:00:00 +0000

Well if I thought sitting in Leeds in the snow was bad, tomorrow gets worse when I fly out to Minneapolis for 2 days of meetings before returning on the overnight flight on Wednesday. Does life get better than this?

Who is responsible for failure?

Mon, 01 Mar 2010 00:00:00 +0000

A question I get asked quite often when talking about Scrum and other agile methods is "who is responsible for failure?". It's an interesting question and depending on the circumstances there are different possible answers.

Firstly though, I don't like using the word "responsible". I much prefer "accountable" as I expect people to take accountability for their individual or collective failings and respond appropriately (unlike our current crop of politicians who will only understand accountability when they lose their seats in an election).

So who is accountable for failure in an agile context? In my opinion it really depends on the maturity of the team with respect to agile adoption. To my mind, a mature team will always accept accountability for failure and will not try to hide behind the scrum master. Indeed hiding behind the scrum master shows a distinct lack of maturity with respect to Scrum.

A new team that is in the process of adopting agile practices however can often not be held accountable for all failures as very often those people who train, coach and mentor the team must take accountability for not having guided the team in the best way prior to a failure.

Sometimes though, this 'rule' doesn't hold true. I have recently been working with a team who have been given a lot of support and coaching, yet a recent code review highlighted serious deficiencies in their code. Similar deficiencies had been pointed out to the same team a couple of months previously and the team had received some intensive coaching to help them address the quality issues. Despite this coaching, and being given a period of time to address the issues, the team has just carried on as before.

Ultimately, however you look at it, this has demonstrated a collective failure by a team to deliver a product to the required quality and the team will stand or fall on how it reacts to another opportunity to address its failures.

Although as coaches we must still accept some accountability (as there is always more we could have done), this has been a spectacular failure on the part of the team. This team have refused to be open, honest and transparent about what they are doing, they have also rejected the advice of their coaches. On top of that, they have failed to take collective ownership and accountability for the quality of their work, seemingly thinking that they can blame everyone else for their own lack of quality.

Training Tomorrow

Sun, 06 Jun 2010 00:00:00 +0100

I'm really looking forward to the next couple of days as I'm giving a Scrum training course to kick off a new client engagement.

I've spent the weekend preparing all the materials and printing out the course handouts.

Training makes a change from the day to day of managing delivery, however giving training as a springboard into delivery is even more rewarding :)

Ascot

Wed, 16 Jun 2010 00:00:00 +0100

I'd really like to thank Alex and Anna from Connections Recruitment for a fantastic day out at Royal Ascot yesterday. Not only was the company first class, I also picked 5 out of the 6 winners and won some money into the bargain :)

It's been a while

Wed, 20 Oct 2010 00:00:00 +0100

Well it's been a while since I posted anything on here and there are some things worth catching up on.

I am now the Midlands regional coordinator for Agile Legends. There is a Linked In group for both Agile Legends and for the Midlands region specifically. I'm looking to organise a initial get together for the Midlands Legends in December, so if you are a Midlands based Agile Legend and you would like to know more, please join the Linked In group.

We've recently been working on agile training and adoption with a company who develop embedded software. This is going really well with the first team showing some really good signs of understanding agile practices and why/when to use them. We will shortly be starting work with a second team.

Through our work in the field of embedded software, I have also made some interesting contacts which could lead to co-authorship of a book on Scrum - watch this space.

The Agile Awards was a good night out - I really enjoyed seeing some old friends and having a chance to catch up with them over a drink or two. I'd also like to thank all of those who joined me at the Project Success table for a thoroughly enjoyable evening.

Finally, I'm off to the CBI Conference on Monday. It should be an interesting day with good opportunities to see how the CBI are looking to help private sector investment improve the current economic situation.

CBI Conference

Tue, 26 Oct 2010 00:00:00 +0100

Yesterday I attended the CBI conference where it was very refreshing to see that in a straw poll about 25% of the audience indicated that their companies were likely to hire new staff in the coming year. It was even more interesting that in another straw poll nobody indicated that they thought the much talked about "double dip" recession would materialise.

It was also very interesting to hear the former Canadian Prime Minister, Paul Martin talking about how Canada dealt with their budget deficit in 1995.

Maybe it's time the doom and gloom merchants kept quiet and let those who want to change things for the better get on with it - and maybe there's a lesson or two there for people who claim that agile can't work in their environment because "we're special".

When are universities going to start teaching agile methods

Wed, 27 Oct 2010 00:00:00 +0100

I've recently been visiting a few of England's universities with my eldest son, looking at computer science/computing undergraduate degree courses. So far none of the universities that we have looked at have done anything that comes close to teaching about agile methods, indeed at one university a discussion broke out between 2 of the tutors about whether or not they still taught SSADM. They were totally surprised when I said that agile was mainstream with many banks having adopted agile methods. If universities are really going to produce the workforce of tomorrow, surely they need to be embracing the working methods and practices of today?

Twitter

Thu, 28 Oct 2010 00:00:00 +0100

I'm now on twitter but not promising to tweet regularly or frequently. The bizarre thing is that since I joined twitter and before I tweeted for the first time, someone I have never heard of started following me. If you do want to follow me (and I'm not sure why anyone would) then you can find me @project-success.

Do I have a twitter stalker or are there really people out there that have that few real friends?

The perils of indecision

Mon, 08 Nov 2010 00:00:00 +0000

I was driving home from Cardiff on Saturday (a long story which I won't go into here) when another driver nearly pulled out in front of me on a roundabout. The fundamental reason that this other driver very nearly caused an accident was that they couldn't decide whether it was safe to pull onto the roundabout or not, and therefore they didn't commit one way or the other until it was too late. Their indecision, as I said, very nearly caused an accident.

Whilst not normally so drastic, indecision is also bad when it comes to delivering software. It is often better to make a wrong decision than to make no decision at all, although obviously, it's better to make the right decision. Unfortunately, not being blessed with hindsight, we don't always know whether we have made the right decision until after the event. This is why it's better to make a decision and even better to make a decision at the latest responsible point in time and make decisions that don't lead is down a dead end that we can't get out of.

How do we make sure we do this - well unfortunately there is no substitute for experience.

Executive Coaching

Thu, 18 Nov 2010 00:00:00 +0000

I've recently encountered a situation which has made me step back and re-assess a view I've held for a while, namely that the Product Owner role is the one that companies usually struggle to get right.

In the past I've thought that this was caused by not choosing the Product Owner carefully and thinking about the PO role and the attributes needed in the person who fulfills the PO role.

Recently I've had a change in thinking on this as it has always been an issue that is difficult to crack. Recently I've decided that a good way to ensure an appropriate and empowered Product Owner is to look at the executive team and their understanding and adoption of agile values and practices. I feel that there is a definite need for coaching at the exec level in order for an organisation to effectively leverage all the benefits of agile working but too often we concentrate our coaching and mentoring on the team themselves.

Time to not only think outside the box but also to step outside and coach outside the box.

Commitment

Fri, 24 Dec 2010 00:00:00 +0000

It struck me the other day that we have recently had a good opportunity to gauge the commitment of our teams because of the bad weather.

Whilst I would never condone anyone taking silly risks travelling in bad weather, I was heartened to see that the team I am working with right now were all committed to the point where they made it into the office to ensure that they could collaborate effectively. This involved one team member flying over from Spain (although it was a shame that the first real problem he encountered was when he got to London and tried to catch a train to Coventry).

Once in the office, the team set about putting things in place so that they could all work from home but still collaborate effectively.

This contrasts very much with a team I was working with a few years ago. In this case, I was driving 85 miles each way to get to the office however quite a large number of people who lived 5 minutes away didn't even attempt to get into work.

I know who I would rather be working with.......

Changes at the Scrum Alliance

Tue, 28 Dec 2010 00:00:00 +0000

It's been really refreshing and reassuring over the last few days to see some of the changes that are happening within the Scrum Alliance. If they really do follow through on some of the discussions that are taking place, it will make it a much better organisation :)

Agile Awards 2011

Thu, 07 Apr 2011 00:00:00 +0100

I'm very flattered to have been nominated for "Most Valuable Agile Player (UK)" in this year's Agile Awards.

Although I'm not sure who nominated me, I would like to say a big thank you - whoever you are. It means a lot to have recognition like this from my peers.