All About Agile | Agile Development Made Easy!
how do you teach the client
Background:
I work in the Federal Sector for a very large agency. I'm the project manager for the web team that develops and maintains the entire agencies web presence (internal, external and hr); hundreds of thousands of pages. My team has for the last umpteen years been the sole design and content team for the entire web offering.
Scenario:
We've recently been tasked with developing several high visibility and complex web based applications. These apps are agency wide, very high profile (one is being looked at by the head of DOT).
Issue:
I need to educate the client so that he realizes how an Agile iteration system works, and how deadlines are defined. At the moment, the client says - "Here is what I want, and I want it by Friday". We then have to try to cram it into our already heavy load.
We are constantly in Fire Fighting mode.
As a contractor I have to wear "kid gloves" when interacting with the client, but I really need to teach him how Agile works, and why it's better.
Been There, Done That:
I've already explained the entire Agile/Scrub/Kanban methods and their reasons for use. I've provided with verbal and written case material to substantiate our choice. I've expressed over and over and over how features and value driving the process, and the process drives the completion dates.
So, what the heck am I missing?
I work in the Federal Sector for a very large agency. I'm the project manager for the web team that develops and maintains the entire agencies web presence (internal, external and hr); hundreds of thousands of pages. My team has for the last umpteen years been the sole design and content team for the entire web offering.
Scenario:
We've recently been tasked with developing several high visibility and complex web based applications. These apps are agency wide, very high profile (one is being looked at by the head of DOT).
Issue:
I need to educate the client so that he realizes how an Agile iteration system works, and how deadlines are defined. At the moment, the client says - "Here is what I want, and I want it by Friday". We then have to try to cram it into our already heavy load.
We are constantly in Fire Fighting mode.
As a contractor I have to wear "kid gloves" when interacting with the client, but I really need to teach him how Agile works, and why it's better.
Been There, Done That:
I've already explained the entire Agile/Scrub/Kanban methods and their reasons for use. I've provided with verbal and written case material to substantiate our choice. I've expressed over and over and over how features and value driving the process, and the process drives the completion dates.
So, what the heck am I missing?
Views: 9
Replies to This Discussion
-
Permalink Reply by Radha Israni on -
It all depends upon how much clout you have? From the looks of the background information you have provided I presume you have some authority in terms of process adoption? Given that the client wants the 'what' but have you got any say in the 'how'? (thats rare luxury for contractors-at least here in the UK)
My approach would be to get an approval for a 'Sprint 0' - a really short 2 week sprint modelled, managed and reported the way SCRUM defines - and I would look at the PMO projects pipeline and pick up an existing project for which budget sanction already exists.Allows you to start from a clean slate
-
Permalink Reply by Dave Hopkins on -
Radha, Thanks for the insight. As you suspected I have a fair bit of clout with regards to the team, but when it comes to the client I can only recommend. I do however have a pretty stern "I recommend" voice that I use ... Sometimes that works better than others.
The real dilemma is when it comes to setting dates for a deliverable. Our boss, who is also our client, tends to set these dates to his clients with out consulting us first. This of course puts us into a rigid schedule and tends to lean toward a less than Agile process. We are running "new builds" (Aplha Team) in an OpenAgile fashion and pickups or bug fixes (Gamma Team) on a digital Kanban board. Two separate teams with individual needs and methods. It's the Alpha Team I have the scheduling issues with.
I have never been able to get the sprints in front of the client prior to him setting the date. It turns out that the sprints are often defined by the deadline that's been imposed.
(Did i mention that we're a US Federal Agency? We are a contractor working for a Fed.)
-
Permalink Reply by Radha Israni on
-
I can totally understand your dilemma when you say you are trying to do what you with the Fed! In general I have had terrible experiences implementing SCRUM in public sector projects(in my past life as a consultant-I now work for an in-house corporate IT shop and am usually full of more than a mouthful to the 'business users' who give lip service to SCRUM as they simply want to keep their individual balanced scorecards looking good)
Anyways, back to your problem - we typically have three variables that a SCRUM master can play with - time, quality and scope- from the looks of it you have no say in choosing the time and scope? Here is a cheeky approach(I have tried it and have been able to get away with it with good political backing) - brazen recommendation I know but it works in my experience-
You might want to play around the quality parameter-complete all tasks within time(your alpha team) and then let them find bugs in the gamma team. How do I explain increased bugs? trace the problem back to users! it is quite likely that your boss (who i guess would be ultimately responsible to users) will not like to appear to be failing in front of the users-maybe you could use this to bargain on the other two parameters(time/scope)
Just my 2p.
-
Permalink Reply by Dave Hopkins on
-
Too funny.. At this point, this is exactly what we do. We limit the number of features, and typically have to forgo any serious testing cycles. We still test at the end of each story and again at the end of each sprint, but those are mostly Peer Tests/Code Review and UX/UI testing. Bugs still manage to get through.
It's a hard nut to swallow when you are forced to sacrifice quality in an effort to train your client.
-
Permalink Reply by Radha Israni on
-
Well then you can choose your priority! Do you want(as a contractor) to get your time sheets signed in time and a referenceable customer or do you want to loose focus from the project/SCRUM and get embroiled in massive change management issues especially in places like the Fed agencies!
Sorry just kidding Dave but you get the drift I hope...SCRUM is essentially an SDLC method and requires certain organizational pre-requisites to be met - ideally of course. In reality that is almost never the case especially in large public sector companies where people often choose SCRUM literally to show off how innovative and trendy they are- but lack the clout or inclination to really adopt scrum in a purist sense and find out they have suddenly devolved too much power
-
Permalink Reply by Dave Hopkins on
-
That's right were we live. Somewhere between Agile and Waterfall.. teetering back and forth, leaning to one side or the other based on whether or not the client is in today..
More to come!
-
Permalink Reply by Simon Kiteley on -
Reading this post it does seem your boss is the problem. Without their help you can only go so far before you hit a wall to being more agile.
If it was the external client that are the problem. You could just differentiate between agile friendly and rushed activities by how much each change is charged. Features they want to be time-boxed cost X rush jobs cost Y. Make it cheaper for them to think ahead a little.
If they want to pay the Y cost... then let them but you'll not be agile.
© 2012 Created by Kelly Waters.
