keithb
Keith Braithwaite
Member
Posts: 19
Registered: 27 Sep 06
Location: London
Member Is Offline
|
![[*]](./images/grass/default_icon.gif) posted on 15 Nov 06 at 04:08 PM |
|
|
agile * flexible / consultancy = what?
So, here we go, something to flesh out the disucssion on the other thread about consultancy. Disclosure: I make my living as an agile consultant.
Dmitri Zimine gives this this Agile Advice[/url]
regarding the business trying to wedge "high priority" items in mid sprint (he's a Scrum guy, it seems)
| Quote: | Tell the project manager that the iteration is carefully planned with a goal to release the new project by expected date. The
plan leaves no space for switching the context daily. Our options are:
1) Put the issue to the back log and plan it for the next iteration.
2) Cancel the iteration, suspend the "new project", replan and work on the issue.
Let them make their call. This is the tough part; it is never well received. But I have to take a stand. I don't have the luxury not to do
this. |
(emphasis added)
Joel gives him a virtual clart upside the head:
| Quote: | | Agile development is supposed to be about agility. It's supposed to mean that you can change plans quickly. It's not supposed
to be about rigid programming teams who are so slavishly devoted to their Two Week Plans that they can't rearrange their schedule a bit to serve the
needs of the customer. Dmitri's conclusion, I'm afraid, strikes me as the very opposite of agile development. Agile is not supposed to be about
swapping out one set of bureaucratic, rigid procedures for another equally rigid set of procedures that still doesn't take customer's needs into
account. |
(again, emphasis added)
This, by the way, is not the first time that I've heard that the problem with Agile folks is that they're so inflexible.
Lou Franco then brings some sense to the
conversation:
| Quote: | | Scrum offers us basically one option for dealing with this -- cancel the sprint. For us, that's unacceptable. So, we may not
be doing pure Scrum -- but, we have seen and implemented some different ways of dealing with urgent items, that I think are in the spirit of
Scrum. |
Now, I don't want to knock Scrum as such, I use Scrum techniques every day (and not just every working day) with great success, but that happens to
be the approach that's being discussed. It's also one of the very few that has all that certification stuff going on.
Lous suggests three ways out of the bind, of which I prefer number 2:
| Quote: | | Remove items from the sprint. I know this is a no-no, but usually we have a few small lower-priority
items that are nice to have and help round out the time to a sprint-sized chunk. In a way, we are pre-deciding what we would do if no urgent items
came up. Probably the right way to do this is to not put them into the sprint to begin with, and then let the team add them in if they have
time. |
(bold is as the original, italics added)
This is exactly the XP practice of Slack, described in the 2nd edition white book as
| Quote: | | In any plan, include some minor tasks that can be dropped if you get behind |
We can also appeal to the "buffer" reccommended in Critical Chain practice to see that Lou's suggestion is pretty well founded, but here he is
apologising for using it! Lou concludes:
| Quote: | | The way to deal with important urgent items in Scrum is to first figure out what you are trying to get out of the process and
then figure out how to do them in a way that let's you still get those benefits. |
Contrast this again with Dmitri's approach:
| Quote: | The plan leaves no space for switching the context daily. Our options are:
1) Put the issue to the back log and plan it for the next iteration.
2) Cancel the iteration, suspend the "new project", replan and work on the issue.
Let them make their call. This is the tough part; it is never well received. But I have to take a stand. I don't have the luxury not to do
this. |
(again, emphasis added)
I think it's that "I don't have the luxury not to do this" stance that would account for some of what y'all have against Agile consultants
(the comment is on that page, anyway. Does anyone know how to link to a particular message?)
Dmitri appears to be a Certified Scrum Master, while Lou does not. Which approach would you rather have from someone consulting into your team?
Keith
Nothing I post here should be taken as a statement of Zuhlke policy
|
|
|
debhart
Member
Posts: 72
Registered: 04 Sep 06
Location: Toronto, Ontario
Member Is Offline
|
| posted on 16 Nov 06 at 12:15 PM |
|
|
| Quote: | | Dmitri appears to be a Certified Scrum Master, while Lou does not. Which approach would you rather have from someone consulting
into your team? |
Note: Dimitry is also not a consultant. I think that makes a difference... he's a manager, a permanent employee, well hooked into the culture of his
workplace.
|
|
|
keithb
Keith Braithwaite
Member
Posts: 19
Registered: 27 Sep 06
Location: London
Member Is Offline
|
| posted on 17 Nov 06 at 06:39 AM |
|
|
| Quote: | Originally posted by debhart
| Quote: | | Dmitri appears to be a Certified Scrum Master, while Lou does not. Which approach would you rather have from someone consulting
into your team? |
Note: Dimitry is also not a consultant. I think that makes a difference... he's a manager, a permanent employee, well hooked into the culture of his
workplace. |
Really? OK. I've ammended the grandparent to reflect that. Not sure it makes much sense any more after that small change, but what the hell.
Shouldn't post late an night.
Keith
Nothing I post here should be taken as a statement of Zuhlke policy
|
|
|
debhart
Member
Posts: 72
Registered: 04 Sep 06
Location: Toronto, Ontario
Member Is Offline
|
| posted on 17 Nov 06 at 12:45 PM |
|
|
Keith - I wasn't criticising your item, just adding more facts. I do think that permanent employees can sometimes take approaches a consultant
couldn't, simply because they have more data and a different relationship to management. On the other hand, sometimes a consultant can say
uncomfortable things a permanent employee may hold back on, if the climate is very political.
|
|
|
PaulOldfield1
Member
Posts: 62
Registered: 05 Sep 06
Location: Perthshire, Scotland
Member Is Offline
|
| posted on 19 Nov 06 at 09:35 AM |
|
|
Whether independent consultants or permanent staff, we (for the most part) give the best advice we can. Normally, and of course this depends on the
individual, more and broader experience will give a better foundation of knowledge to support better advice. A typical genuine agile consultant will
have had a broad range of relevant experience and will be able to give good advice in most situations where agility is required and expected. Not all
consultants are agile, not all consultants that claim to be agile are genuinely agile.
In my experience, a large proportion of consultants tied to a consultancy will give advice that will bring more work for the consultancy. This
doesn't mean the advice is bad, but IMHO it often isn't as good as it ought to be. As I've just joined a large consultancy, I should point out
that this isn't always the case; you can find good non-independent consultants ;-)
This still leaves many folk with the tricky question: "Okay, I've got a consultant - how good is his advice?".
Best of all possible worlds - find a really good independent consultant and persuade him or her to go permanent for you. (or get really lucky and find
great people on your own staff... perhaps you could help that along a bit?)
Paul Oldfield
Capgemini, Telford UK
|
|
|
BillRG
Bill Rinko-Gay
Member
Posts: 24
Registered: 09 Nov 06
Location: Boiling Springs, PA
Member Is Offline
Mood: Optimistic
|
| posted on 21 Nov 06 at 04:14 PM |
|
|
Keith quotes Joel above in saying:
"Agile development is supposed to be about agility. It's supposed to mean that you can change plans quickly."
While agile is about changing plans quickly, eventually you put yourself into a place where changing plans incurrs significant cost. We can not let
the business owner pretend that he/she can change plans forever for free. The decision as to whether to incur those costs is not yours, but the
business owner's. There's a cost to changing the purpose of a sprint in mid sprint. We can't pretend that's not there. There's a cost to
changing the functionality of an artifact that's already passed UAT at the end of a previous sprint. We can't pretend that's not there.
One of the things agile methods give us is a much more clear view of what that cost is. We may not be able to easily quantify the cost of changing a
requirement halfway through a design phase, but we can clearly enumerate the cost of scrapping a sprint in mid course. We can clearly enumerate the
cost of re-building an artifact that is already completed.
That difference alone is a major selling point of agile, IMHO.
Bill Rinko-Gay
Delivery Director
Spherion
|
|
|
BillRG
Bill Rinko-Gay
Member
Posts: 24
Registered: 09 Nov 06
Location: Boiling Springs, PA
Member Is Offline
Mood: Optimistic
|
| posted on 21 Nov 06 at 04:17 PM |
|
|
| Quote: | Originally posted by PaulOldfield1
This still leaves many folk with the tricky question: "Okay, I've got a consultant - how good is his advice?".
|
Ask any attorney about overcoming that question.
How do you give good advice? You develop good judgement. How do you develop good judgement? By making good decisions. How do you make good
decisions? By experience. How do you develop experience? From making bad decisions.
But we have to start somewhere. Over time we develop a track record that speaks for us.
Bill Rinko-Gay
Delivery Director
Spherion
|
|
|
RonJeffries
Ron Jeffries
Super Administrator
Posts: 126
Registered: 29 Aug 06
Location: Pinckney, MI
Member Is Offline
Mood: fascinated
|
| posted on 22 Nov 06 at 10:24 AM |
|
|
| Quote: | Originally posted by BillRG
| Quote: | Originally posted by PaulOldfield1
This still leaves many folk with the tricky question: "Okay, I've got a consultant - how good is his advice?".
|
Ask any attorney about overcoming that question. |
I would, but I can't afford the fee. 
|
|
|
PaulOldfield1
Member
Posts: 62
Registered: 05 Sep 06
Location: Perthshire, Scotland
Member Is Offline
|
| posted on 24 Nov 06 at 04:26 AM |
|
|
| Quote: | Originally posted by RonJeffries
| Quote: | Originally posted by BillRG
| Quote: | Originally posted by PaulOldfield1
This still leaves many folk with the tricky question: "Okay, I've got a consultant - how good is his advice?".
|
Ask any attorney about overcoming that question. |
I would, but I can't afford the fee. |
And despite the cost, how do I trust
the advice sold to me? ;-)
Paul Oldfield
Capgemini, Telford UK
|
|
|
RSS Feed
