Agile - The Way A Project Should Be Run!?

As I have told you in my bio, I am a project manager in the information technology industry - a job which tends to be stressful much of the time.  More so because project manager's tend to be the fall guys when everything goes awry.  So you can imagine that when I was introduced to a new method or way of thinking about project management recently, I got excited.  I still am.

You see, the management method has been designed from the floor up to make the 'PM's' life more livable, and that is good news.  It draws the various parties involved in projects together, and in my world, that would be the client and the programmers or development team, and sets the PM up as a facilitator.  That is wonderful, because whilst it does not reduce the level of responsibility that the PM has, it certainly puts their accountability into a far more manageable perspective - essentially, they are no longer burdened with sole accountability when things go wrong.  So that is a plus - a very definite plus!

Oh, and the PM has now got a new title - but I'll tell you about that at the end!

The next positive thing to discuss is the manner in which the project is handled using this method - essentially, instead of the PM setting about and developing a complete project plan and all of the associated functions, defining the outcomes to the letter, etc. now the plan is developed as a series of 'stories', and each story has a beginning and an end (more about this in a moment).  Very importantly, one needs to understand that the 'story' is really a detailed plan that results in a complete component or sub-product, which forms a part of the end-product, however, the difference is that each of the sub-products can be used on their own - they are not necessarily dependent on anything else in order to be used by the client.

So, if we relate this to building a house for instance, the house would comprise a number of rooms and a garage.  Each of the rooms for this house are built separately and then put together on-site so that no part of the house is necessarily dependent upon another - the rooms could fulfil their function without requiring any of the other rooms to exist.

The coolness (if I may say that) about this approach is that it puts the business or client firmly back in the driver's seat.  The reason for this, is that each story in the project results in a complete product which can be used immediately by the client.  That means that if the client decides that instead of four bedrooms, he can use two for now, that the project is not derailed - it works just fine - and the client is happy.  The converse is also true of course: if the client wants more bedrooms the affect is not disastrous to the project either.  So, in business terms, the project is driven by business needs and we all know that these change, so over a short project, it may be that the requirements won't change much, but over a typical medium to long-term project, business requirements do change - sometimes so much that the project actually gets canned!!

So this approach allows for change to occur to the project far more easily that other methodologies.  Change is simple - the client decides at the end of of a project cycle, called a 'sprint', that a change to the plan is required and it simply happens with minimum impact on the full project outcome.  Things are simply rescheduled or dropped and no-one is stressed about it.

I mentioned a new word back there - 'sprint' - that is the time-frame over which a story (product development cycle) is completed.  And here is the next cool thing about this approach - each 'sprint' is typically timed to a two-week cycle - so it becomes distinctly bite-sized, no matter how big the project is.  Incidentally, the team is asked when they consider the product to be complete - built, tested, and delivered to the client - and this too is factored into the 'sprint' and the customer kept in the loop.  So at the end of the 'sprint', team and customer come together at a meeting facilitated by the PM and provided with the opportunity to agree or not on whether or not the product for that part of the project is complete.  So it is no longer the PM on the carpet, but the team - very good!! (this is how things are meant to work!) 

So, what else is cool - well, at the end of each 'sprint' the project is reviewed, and here comes another new word - a 'retrospective' meeting is held, and its purpose is simple - review what went right and what went wrong - what the team loved and what the team hated.  The good thing about this is that if there is something wrong at team level, like someone has to much work, and someone else has too little, this can be fixed during the project life cycle, and everyone is happy.  There is a very real danger that teams can lose members, and worse, that clients can become disillusioned and go someplace else if project reviews are left to the close-out stages, which does tend to happen in busy projects.  The review, 'sprint', 'retrospective' approach does tend to obviate these risks to a very large degree which is fantastic!

Oh, and lest I forget, there is something else that the PM does in conjunction with the project team - determine the teams work capacity and then communicate that to the client, so that the client understands that the team can do a certain number of jobs simultaneously and the others get stacked in a 'to-do' pile.  This is a very important step to take, and surprisingly need not lead to aggressive clients - what does the client want - timeous deliveries - what can this process deliver - timeous deliveries.  No-one is overburdened, no-one is overly stressed, and the team works at the speed of the slowest member - rather like when Mom and Dad took us hiking and we had to walk at the pace of the slowest child!!  It works!!  And this is something that the PM must be very clear on.

Another point that is encouraging to note from this methodology: it is easy to measure performance and because of that it is possible for a good team to develop the ability to deliver very accurate time-frames for project delivery to clients which will keep costs within estimates, and everyone happy.

So what of the project manager now - well, he (please don't hit me - there are a many very fine female project managers in the world - I know quite a number of them) is part of a team which is charged with the responsibility of putting an end-product together, using a series of sub or mini-products if you will, and who is responsible for facilitating workflow through the team, managing the workloads, making sure that everyone is contributing in accordance with their agreed capacity, that the job waiting list is not too long, and that the customer is constantly kept in touch with progress.

Oh, and finally, the PM has a new name - the job is now 'Product Owner'.  I like that, don't you?

So now you, like me, have an overview of the Agile approach to project management and I'd like to know your thoughts.  If you'd like to do that, please do comment, and thank you for visiting!