DavidChristiansen
David Christiansen
Member
Posts: 11
Registered: 04 Dec 06
Location: Indianapolis, IN
Member Is Offline
|
![[*]](./images/grass/default_icon.gif) posted on 06 Dec 06 at 08:23 PM |
|
|
Avoiding Agile that's not agile
One of the concerns I have with introducing Agile project management methodologies in the corporate IT world is that the processes/tools of an Agile
methodology (Scrum, XP, etc) will be deployed without proper considerations for the principles of Agile methods. What if IT departments deploy Agile
the same way they implemented CMM, Continuous Process Improvement, and heck, even Waterfall - without an appreciation for the fundamental values that
make methods work. I think this is one of the reasons why there is an "Agile Backlash", as blogged about by Jonathon Kohl and others. When a person who is fundamentally
process-centric tries to take Agile methods and implement them, I think they are almost always going to fail because they are so process driven. They
have to change first, and become less reliant on process, or else they will create an Agile methodology that is not agile. How do you prevent this
from happening? How do you change people who have whole-heartedly bought into bad ideas like the following, which just aren't true:
- If you create the right process, anybody can do the work.
- It doesn't matter if you fail as long as you follow the process.
|
|
|
BillRG
Bill Rinko-Gay
Member
Posts: 24
Registered: 09 Nov 06
Location: Boiling Springs, PA
Member Is Offline
Mood: Optimistic
|
| posted on 14 Dec 06 at 10:51 AM |
|
|
| Quote: | | Originally posted by DavidChristiansenI think they are almost always going to fail because they are so process
driven. |
David,
I'm sorry I haven't responded sooner because this is a topic that truly interests me.
One of my favorite concerns in any discussion of the extremes is the question of balance. Processes have a place, especially as the group trying to
implement the methodology gets large. While I have seen a lot about agile projects, an organization can not truly go agile without some implementing
processes to ensure all the projects provide the right information for management control.
Over the years I have come to a few conclusions that I think have impact here:
1) Management controls are meant to enable managers to manage risks, but managers and employees have often forgotten the purpose as they focus on the
controls.
2) Policies and procedures are intended to enable a methodology, but the methodology often gets forgotten as the people focus on the policies and
procedures.
So what happens is that a growing organization sees the need to put controls and procedures in place based on an honest effort to make things work
more smoothly. But the rationale gets lost and the controls and procedures take on a life of their own.
People have a problem walking tightropes. We want to jump off on one side or another. That's our nature. We have to work aggressively to stay on
the tightrope.
I'm not sure if there is an easy answer, but if I may borrow from one of the Agile approaches - aggressively reengineer the process. At least once a
year (more often if you can stand it) take a look at each process and each control and ask the important questions:
1) Is this still accomplishing the task we designed it for?
2) Is this still the best way we can think of to accomplish it?
Doing this should help maintain the agile philosophy while still enabling the larger organization to function.
Whew - a longish dump. What are your thoughts?
Bill Rinko-Gay
Delivery Director
Spherion
|
|
|
IljaPreuss
Ilja Preuß
Member
Posts: 96
Registered: 05 Sep 06
Location: Karlsruhe, Germany
Member Is Offline
|
| posted on 15 Dec 06 at 10:21 AM |
|
|
In my experience, a well organized, regular iteration retrospective is already quite effective at making sure that a process is something dynamic,
adaptable - instead of something static.
|
|
|
BernardNotarianni
Bernard Notarianni
Member
Posts: 14
Registered: 07 Sep 06
Location: Paris, France
Member Is Offline
Mood: Transition.
|
| posted on 16 Dec 06 at 04:14 AM |
|
|
I am currently reading the second edition of Alistair Cockburn book “Agile Software Development: The Cooperative Game”. Cockburn uses the very powerfull metaphor of Shu-Ha-Ri.
My understanding of one of the point of Cockburn is that when people feel the need to be “process driven” and are seeking for “procedures” they are
probably in the Shu state. When people, like Ilja, seem to not need those procedures and do things quite naturally, they are probably at the Ri
state.
The metaphor exposed by Cockburn helped me to make sense of the differences between “not agile way” and “agile way”.
| Quote: | Originally posted by DavidChristiansen
They have to change first, and become less reliant on process, or else they will create an Agile methodology that is not agile. How do you prevent
this from happening? How do you change people who have whole-heartedly bought into bad ideas like the following, which just aren't true:
- If you create the right process, anybody can do the work.
- It doesn't matter if you fail as long as you follow the process. |
I am not sure that Cockburn has the answer to this question, but it worth maybe to have a look to the book.
Hope that help.
|
|
|
IljaPreuss
Ilja Preuß
Member
Posts: 96
Registered: 05 Sep 06
Location: Karlsruhe, Germany
Member Is Offline
|
| posted on 16 Dec 06 at 04:26 AM |
|
|
I agree to the point that when I'm in the Shu state for something, I know I need to more closely follow the rules.
I'm not sure that is the same as being "process driven", at least the way David seemed to use the term. That seemed to have a deeper connotation of
the values believed in.
|
|
|
DavidChristiansen
David Christiansen
Member
Posts: 11
Registered: 04 Dec 06
Location: Indianapolis, IN
Member Is Offline
|
| posted on 16 Dec 06 at 09:10 PM |
|
|
I think I agree with everyone, although I'm not yet familiar with Shu-Ha-Ri. Here's what I read that I found useful:
1) Re-examine process regularly. Our CIO says this a lot - he says we should question them every six months at a minimum
2) Use retrospectives to improve, eliminate waste, etc.
3) Don't forget the purpose for which a process exists. I've often said that if you separate a process from the values it is intended to express it
no longer has any value. I think it's worth saying you should periodically check to see if the values have changed or if the process is still an
expression of them.
One thing I find myself saying frequently is this: "Rather than focusing on how we move forward, let's talk about what we want to accomplish and
why." I find this helps get people focused the way I want them to be.
I'm not convinced that just anyone can be effective on an agile team. I think there is a personality type that is simply diametrically opposed to
being agile. I don't have a good word for it other than process-driven. I have experienced a few people that just can't let go of the idea that you
can do the same six steps over and over, regardless of the project, and be successful. Maybe they should just be shunted off to the PMO...
|
|
|
gdinwiddie
Member
Posts: 40
Registered: 05 Sep 06
Location: Maryland
Member Is Offline
Mood: hunky-dory
|
| posted on 17 Dec 06 at 03:57 PM |
|
|
| Quote: | Originally posted by DavidChristiansen
I'm not convinced that just anyone can be effective on an agile team. I think there is a personality type that is simply diametrically opposed to
being agile. I don't have a good word for it other than process-driven. I have experienced a few people that just can't let go of the idea that you
can do the same six steps over and over, regardless of the project, and be successful. Maybe they should just be shunted off to the PMO...
|
I'm not convinced that being process-driven can be effective on a regular basis, either. That is what Jerry Weinberg calls "Pattern 2 - Routine"
in QSM vol 1. I think that "Pattern 3 - Steering" is where effectiveness starts.
I just wrote a bit about this at http://blog.gdinwiddie.com/2006/12/16/its-all-about-feedback/
|
|
|
prometheusbound
Michael Nyika
Member
Posts: 3
Registered: 30 Jun 07
Location: USA
Member Is Offline
Mood: Thinking Lean
|
| posted on 30 Jun 07 at 09:53 AM |
|
|
David: To answer your original concern in a very simple manner: To prevent the Agile Backlash, teach people in the organization LEAN THINKING. Why?
Because Lean is the *real* driving force behind agile. Lean principles are the reasons why agile works. If this is understood and taught first, then
you cut down the odds of backlash happening.
Keep It Simple
|
|
|
RSS Feed
