What about the client...?
the kettle sings
off on a tangent...
Well, maybe, maybe not. Give me a few lines to state my case.
Though first here it is in a nutshell. If you're up to a spot of
verbal diarrhoea then read beyond.
<nutshell>
Doing agile remains constrained by the extent of meaningful client
commitment.
It is usually easier to get this right with younger organizations,
with smaller projects.
In larger organizations (even though your client may only be a small
clearly defined sub-entity therein) there are challenges to be
overcome.
I want to learn from the group how to go about encouraging the client
to adopt a set of behaviours appropriate to making Agile really work.
Cheers
Rainer
</nutshell>
<blah-blah-blah>
To me the Agile Manifesto is a thing of great beauty - it encapsulates
a vast terrain (the practice of software development) with a few
simple yet profound value recommendations.
Developers eager to better their practices take to Agile quite easily.
I liken it to distilled common sense.
Of course, trying to introduce agile principles into the existing
workplace is not without its problems, established practices may need
to be unseated, resistance to change overcome, all that softer, fuzzy
psychology of the workplace stuff... and i'm only referring to the IT
organization here. The business, client, user also needs to be embrace
these principles, and achieving that is not always easy.
Let's look at the slogans of the manifesto with the client in mind:
1. Individuals and interactions over processes and tools
You can perhaps choose your team, but you may have to deal with
individuals from the client that are uhm, difficult?
2. Working software over comprehensive documentation.
At first glance - great! "Show me what you've done, not what you are
going to do!" But the principle implies an iterative approach that
demands ongoing client attention - time and effort throughout the
project. This can be met with resistance.
3. Ongoing collaboration over contract negotiation
Ongoing commitment again.
It's ironic that the risk mitigating value of staying involved, of
seeing the shape of a solution evolve so that you can influence it, is
so often overlooked in favour of budgetary imperatives as in "give me
the bottom line, and i want it upfront". You all know how creative
sizing can get when you're forced to calculate a price at the outset
when so much stuff is still unclear.
4. Embrace change over following the plan.
Clients are generally very happy to hear that you are committed to
face changing circumstances. Again though, for this to work, ongoing
involvement is a given - right? Don't you just hate the socalled
"participant" that arrives late, throws a curved ball into the
proceedings and then has to leave - no other contribution...
These concerns about agile and the client are part of my broader
interest in that hoary old chestnut commonly referred to as "Bridging
the IT / Business Divide" - and i think this goes further than just
the bigger, say corporate clients that have their own IT
organizations.
So, i think that doing agile effectively can require a great deal of
evangelizing outside of the scrum.
The full benefits of agile remain unrealized if the client only pays
lip-service to upholding their end of the deal.
</blah-blah-blah>
Brian Silberbauer
My comments intermingled below:
On 4/19/07, the kettle sings <rth...@telkomsa.net> wrote:
>
> Sorry, the group is barely born and in sneaks a guy that wants to go
> off on a tangent...
> Well, maybe, maybe not. Give me a few lines to state my case.
>
> Though first here it is in a nutshell. If you're up to a spot of
> verbal diarrhoea then read beyond.
>
> <nutshell>
> Doing agile remains constrained by the extent of meaningful client
> commitment.
> It is usually easier to get this right with younger organizations,
> with smaller projects.
> In larger organizations (even though your client may only be a small
> clearly defined sub-entity therein) there are challenges to be
> overcome.
>
> I want to learn from the group how to go about encouraging the client
> to adopt a set of behaviours appropriate to making Agile really work.
>
> Cheers
> Rainer
>
> </nutshell>
Use what works for your client, they don't need to swallow the whole
cuppa agile in the first sitting. With more people using agile
principles, this initial client block will become less.
Perhaps it would be helpful to add resources on our web site that
would help clients understand agile - client comments, companies using
agile or success stories.
>
> <blah-blah-blah>
>
> To me the Agile Manifesto is a thing of great beauty - it encapsulates
> a vast terrain (the practice of software development) with a few
> simple yet profound value recommendations.
>
> Developers eager to better their practices take to Agile quite easily.
> I liken it to distilled common sense.
> Of course, trying to introduce agile principles into the existing
> workplace is not without its problems, established practices may need
> to be unseated, resistance to change overcome, all that softer, fuzzy
> psychology of the workplace stuff... and i'm only referring to the IT
> organization here. The business, client, user also needs to be embrace
> these principles, and achieving that is not always easy.
>
> Let's look at the slogans of the manifesto with the client in mind:
>
> 1. Individuals and interactions over processes and tools
> You can perhaps choose your team, but you may have to deal with
> individuals from the client that are uhm, difficult?
Well, all the more reason to interact with them, processes and tools
aren't going to help here.
>
> 2. Working software over comprehensive documentation.
> At first glance - great! "Show me what you've done, not what you are
> going to do!" But the principle implies an iterative approach that
> demands ongoing client attention - time and effort throughout the
> project. This can be met with resistance.
I think in terms of client relations, this could be seen as not
producing a 200 page business analysis document of their domain 6
months before creating any solutions. If you can solve your new
clients most pressing problem within a short space of time, they warm
to the agile approach very quickly.
>
> 3. Ongoing collaboration over contract negotiation
> Ongoing commitment again.
> It's ironic that the risk mitigating value of staying involved, of
> seeing the shape of a solution evolve so that you can influence it, is
> so often overlooked in favour of budgetary imperatives as in "give me
> the bottom line, and i want it upfront". You all know how creative
> sizing can get when you're forced to calculate a price at the outset
> when so much stuff is still unclear.
The ideal would be to say to the client "Pay me X and I'll see what I
can fit in", but you need trust before you are able to do that.
>
> 4. Embrace change over following the plan.
> Clients are generally very happy to hear that you are committed to
> face changing circumstances. Again though, for this to work, ongoing
> involvement is a given - right? Don't you just hate the socalled
> "participant" that arrives late, throws a curved ball into the
> proceedings and then has to leave - no other contribution...
As long as the clients feels they are in control and are willing to
pay for changes, there is no problem. It becomes less annoying to me
to implement major changes for a client if they have seen something
substantial already, I get my feeling of accomplishment and I have
confidence that the client knows where they are leading the project.
>
>
> These concerns about agile and the client are part of my broader
> interest in that hoary old chestnut commonly referred to as "Bridging
> the IT / Business Divide" - and i think this goes further than just
> the bigger, say corporate clients that have their own IT
> organizations.
>
> So, i think that doing agile effectively can require a great deal of
> evangelizing outside of the scrum.
> The full benefits of agile remain unrealized if the client only pays
> lip-service to upholding their end of the deal.
>
> </blah-blah-blah>
>
I like to start off using whatever agile 'values' the client relates
to from the start and not sweat the others till the clients starts
seeing value in what you are doing. If they have to budget up front,
they will want you to, so do it for the first small project (try and
narrow it down) and once there is confidence in your ability, you can
start giving monthly guestimation and communicate with the client as
you go along as to what will be going into the months work, for
example.
One needs to be creative and 'agile' ;)
Brian
--
Brian Silberbauer
Consultant
+27 (0)83 566 2705
skype: brian.silberbauer