When Working Software Is Not Enough: A Story of Project Failure
Recorded at:
- Share
-
- |
Read later
My Reading List
Bio
Mitch Lacey is an Agile practitioner and trainer. As a Certified Scrum Trainer (CST) and a registered Project Management Professional (PMP), Mitch shares his experience in project and client management through Certified ScrumMaster courses, Agile coaching engagements, conference presentations, blogs and white papers.
Agile 2008 is an exciting international industry conference that presents the latest techniques, technologies, attitudes and first-hand experience, from both a management and development perspective, for successful Agile software development.
Related Sponsor
Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.
Great presentation - Hits the mark.
by
Krishnan Ramani
Wonderful presentation. I had the exact experience in the very first Scrum project I implemented and was fired from my job.
I have been waiting for this kind of insight for alomost 3 years. Thanks again, I will look forward to reading your blogs.
Sounds like...
by
Dave Rooney
This also sounds like a case where the whole world looks like a nail when all you have is a hammer! The amount of 'complete' up-front work is a warning sign to me, indicating that the organization is still in a serial, phased mind-set. The overall education would need to be applied to much more than just the immediate team. This is also something from Industrial XP - the Project Community - which includes everyone even peripherally affected by the project. Taking that into account may have helped, although it's still easy to overlook some people or groups.
Finally, if the Customer is not an integral part of the team on a daily basis, they aren't a Customer. That may sound harsh and even dogmatic, but they are the most critical aspect of an Agile process. They need to be there and be willing to play by the rules.
It's a good cautionary tale, though, and something all Agile practitioners should watch and read.
Dave Rooney
Mayford Technologies
Risk and Reward are like Love and Marriage...
by
Douglas Stein
Also, if a customer's goal is to offload all risk, then they won't get much reward. There are lots of products that are bid, specified to the hilt, designed, coded, tested - and even finish on time and budget. Unfortunately, they land with a resounding "thud" because they don't really solve a problem anyone gives a hoot about.
The comment about not providing "project deliverable status" is a real hoot - because an Agile method gives you measurable value rather than the illusion of progress.
Sorry about the experience, but some customers need to be fired first. Make sure you write your contracts so that you can cancel just as easily as the customer.
You lost me 9 minutes in, unfortunately
by
Chris Morris
where was the EA during all this?
by
Richard Kucera
This is the flip-side of what the EA folks complain about -- PM delivers on-time and under-budget, customer happy -- EA gets no credit, the PM being unaware of EA.
In this case PM fails due to failure of EA program which PM is equally unaware of. PM blames self.
Re: where was the EA during all this?
by
David Marsh
You traded of things that aren't allowed to be traded off in agile. You have to hold customers accountable, business people are often lazy, you have to force them to perform their role, if you don't have stakeholders to assist in this you're finished.
Documenting failure is not agile, if you're resorting to documents to cover your ass you need waterfall. Agile is normally a new form of time and materials, explain that, its not fixed price / fixed deadline, don't oversell it to the customer. You need key stakeholders and buy in in any process, you need to educate the customer on the process, if they can't understand it, don't do it.
It sounds like you now understand agile, but you burnt the project and the dev team, sounds like you should not have been the agile coach on the project.
Fundamentally Agile has nearly all the same problems as other processes because these are people problems, to fix these you have to fix the way people act, agile trys harder than other processes to educate and assign roles but people are strange beasts. They are not always motivated like you are. Agiles no longer new and basically success rates seem equivalent to iterative or waterfall, good people = good process, bad people = bad process.
Agile needs to mature
by
Jose Luis Rodriguez
I work in a large SW dev. outsourcing company and these problems are exactly the reasons why we are not adopting agile for medium to large projects. A convincing engagement model for fixed price and fixed calendar projects simply can't be signed with agile since the changing functionality can't be predicted or planned. This hurts both the client and the contractor since both are commited to an invisible and unpreditcable target.
The industry and our clients still need to mature regarding agile. In my view, there will always exist projects in two flavors: Unified Process based (for fixed price/calendar projects) and Agile based (For internal time unbound projects)
I see more future in the UP-like process with PSP/TSP and Lean than the established Agile Processes for fixed price projects.
Re: Agile needs to mature
by
David Marsh
Agile says if something is wrong you do whatever it takes to fix it, run round the office with your hands in the air, scream at your boss, resign, anything, don't 'collect the data' and send emails in bold marked priority.
Agile says you assume you cannot mitigate much risk, it therefore reccomends minimal upfront planning and analysis, you wasted six months and instead of removing risk you front loaded your project with risk. It says you cannot trade off Quality, you decoped major elements making it impossible to ensure quality. The idea of 'done is done' is related to dev complete, Agile says the customer can screw you around with requirements as much as they like, customer is king, but its their time and money, they have to realise this, thats why their must be an accountable customer onsite 24/7 !
Business types are used to dealing with other business types, any price / estimate you give them they will assume is full of fat, they don't understand engineers and will insist on 50% cuts as a matter of course. They will also create artificial deadlines which must not move, countering all this is in the partnership idea of Agile, remove the uneccessary stuff and just trust each other, unfortunately with multiple companies involved this is politically naive.
Sounds like you drank too much 'koool-aid', nobody in general cares about your openess or honesty, and other Agile mantra. First and formerly you are a project manager, your job is to organise and protect the team, ensure work is delivered on time and budget, ensure relevant stakeholders are onboard.
You failed in two of those objectives within the first few months, you failed to protect the team by increasing risk by descoping crucial elements, you increased risk with wasted time, you failed to get the correct stakeholders onboard and fully involved.
All through this time you yourself seemed to be operating a hybrid process, probably because as an outsource partner you were on a fixed cost contract, this was another massive warning sign.
It was a good presentation and I appreciate the openess and honesty in the presentation, but really theres no excuse for an experienced Project Manager to be caught with his pants round his ankles just because he bought into the latest methodology, you get paid because of your experience and your brain, its your job to pick the right process for the job.
I wish you the best with your book, at least it will give your dev team a break ! Lets hope it doen't cause another generation of managers to blindly follow a methodology and not use their brains.
Odd...
by
Dick Alstein
The first is what was communicated when the budget was only half of what was estimated. The standard reaction should be: "then you're basically going to get half of what you asked". Instead, project tasks were offloaded to the customer (as if they don't cost anything when the customer does it). The customer could keep on thinking he could have his cake and eat it too.
The second is the lack of trust. The openness and intensive communication in Agile projects ought to create a high level of trust between team and customer (or at least, with the customer representatives involved in the project). That apparently didn't happen. Acceptance was given without grounds, and decisions reversed. To me, this points to a pathological culture in the organization.
Re: Odd...
by
David Marsh
Re: where was the EA during all this?
by
Richard Kucera
Re: Agile needs to mature
by
Richard Kucera
That's EA's job, not PM. PM should be able to manage in whatever style they want. Stakeholder messaging is something you *get* from EA, and you just have to repeat the message if you run into somebody important on the elevator.
Agile is biting off more than it can chew if it takes on these environmental responsibilities.
Re: Agile needs to mature
by
David Marsh
The stakeholders are supposed to be agreed at the start of the project, someone should have said something to the effect of "Anyone that isn't in this meeting or hasn't signed this document isn't allowed to impact on the project directly in any way, other than by consulting an agreed stakeholder", someone from IT should have been added to the list at that point or lose their rights to have direct input.
Database standards are often a nightmare in exactly this manner, I've seen many a trival DB schema turned into a one year exercise by over zealous DBA's. Let them re-write it later if they are so fussed, normally the changes are pretty minimal.
Everyone thinks they are a stakeholder when in reality only few people really are, Agiles about doing what matters most and avoiding such naval gazing.
People, Process, Environment and Technology are issues that have to be addressed on every IT project regardless of whether theres a formal EA function or not.
Re: Sounds like...
by
Mitch Lacey
...the story Josh Kerievsky told about an XP transition back in 2003, I believe, that eventually went bad. That's where Industrial XP and its Readiness Assessments came from.
This also sounds like a case where the whole world looks like a nail when all you have is a hammer! The amount of 'complete' up-front work is a warning sign to me, indicating that the organization is still in a serial, phased mind-set. The overall education would need to be applied to much more than just the immediate team. This is also something from Industrial XP - the Project Community - which includes everyone even peripherally affected by the project. Taking that into account may have helped, although it's still easy to overlook some people or groups.
Finally, if the Customer is not an integral part of the team on a daily basis, they aren't a Customer. That may sound harsh and even dogmatic, but they are the most critical aspect of an Agile process. They need to be there and be willing to play by the rules.
Hi Dave,
Thank you for the comments. This project was full of warning signs. I had just left Microsoft to work at a consultancy and this was my first "real" project. The customer was well aware of their own dysfucntion and it was this acknowledgement that drove me to suggest that we use Scrum and XP (aka agile mix). The problem was that they agreed on paper, but did not understand what they agreed to - and the result was not what they expected (meaning fixed everything), so we "failed". The people we worked with were there almost daily. We spoke with our "customers" daily, but it was the surfacing of the others that messed us up. Lots of lessons and yes, a cautionary tale where I hope others will learn.
Mitch
Re: Risk and Reward are like Love and Marriage...
by
Mitch Lacey
Seriously, if a customer can't be bothered to stay in the loop, then it's clear that Agile isn't right for them. Also, if a customer's goal is to offload all risk, then they won't get much reward.
Agreed! They were in the loop in the beginning and in the end, just the wrong customers. We all thought they accepted some risk, but they did not.
Unfortunately, they land with a resounding "thud" because they don't really solve a problem anyone gives a hoot about.
Yup, which is what the customer wanted to prevent from happening. They showed us the legacy application and told us of how it was built but didn't solve the problems it set out to solve - it met the specification, not the needs of the users.
The comment about not providing "project deliverable status" is a real hoot - because an Agile method gives you measurable value rather than the illusion of progress.
Yes, this gave us a good laugh too. :)
Thanks for the post
Mitch
Re: where was the EA during all this?
by
Mitch Lacey
Thank you for taking the time to watch and comment. I am having a hard time what you are trying to say this this post - is it an assertion, a statement or is there a question that you are trying to ask?
Mitch
Re: Odd...
by
Mitch Lacey
The first is what was communicated when the budget was only half of what was estimated. The standard reaction should be: "then you're basically going to get half of what you asked".
Absolutely! In fact, when I said that, I was told by our engagement and sales managers to "make it work" - this customer accounted for nearly 15% of our total business and they were in the tens of millions of dollars in projects for us. This project was small compared to some that we had done in the past with good (not great) success. My common sense answer was "cut the budget, cut the work" but that was not going to fly. I event went as far as to suggest that we just turn down the project flat - but we had a pending $6m statement of work with the customer and doing that would have put that at great risk. There were a lot of variables that I did not have time to discuss in the presentation unfortunately, this was one of them.
The second is the lack of trust.
Yup. We had what we thought was high trust in the beginning but that quickly eroded. Surprisingly, I still keep in touch on a personal level with three of the people from the customer side who were very apologetic. They are good people with good hearts.
Thanks for your post!
Re: Agile needs to mature
by
Mitch Lacey
Do the customer test or do they not
by
Pavel Veller
We escalated to the sponsor on the customer side and explained all implications. Basically we explained that if this is the way their users "accept" the new system, their business would well just break right after we roll it out... Be careful what you wish for. after the real UAT started to happen we were flooded. over one thousand issues were reported during the next couple weeks. This is another story though.
What I'm trying to say is: it should not be hard to figure if the customer team is in fact doing what they committed to do. The recipe that worked for us - measure it.
Thank You
by
Phil Chandler
Thank you for your insightful presentation.
I am suffering in exactly the same way.
The client is at the 'escalating the incompetency of IT to a board with no IT representation on it' stage and we're at the 'uncomfortable truths' and reverting to traditional methods stage.
I hate to say it, but in truth, the traditional method highlights the lack of accountability,ownership and specification vaguaries inherently within the process every time and stops it dead in its tracks - whereas agile may not.
Just hoping my team survive in time to prove to a 'traditional' board
where the problem lies using the standard waterfall process.
Agile gives you lots of data to prove what you've been doing, but it's subjective enough to leave you exposed by a threatened senior user base.
Wish I'd seen your presentation 6 months ago, but at least I know we're not alone and I've stopped doubting my competency and knowledge.
Thank you.
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think