Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Opinion: Agile Success Is Not Dependent on Agile Techniques
Posted by Amr Elssamadisy on Jan 11, 2010
The marvelous successes of Agile teams are fact. But so are the failures: the cases of 'fragile' adoption, 'we suck less' adoption, and many others where Agile teams fail to produce great software and/or fail to effect the organization as a whole. Is this something that can be addressed and 'fixed', or is Agile development only useful for a some teams?
Here is a thought: the major improvements in technique have already been introduced and all of the major improvements have already been made with respects to the Agile community. The myriad of modifications, adaptations, and new labels are only incremental improvements. The problem lies not within the processes and techniques that we are constantly trying to improve, but the problem lies within us - the people building the software. There is a story that I heard years ago and it has stuck with me:
A new agricultural college grad is speaking to an old farmer and telling him about all the new techniques that he has learned and how he can help the farmer double and triple his crop. The old man looks at the young grad and says "son.... if I did half the things I already know I would have double the crop."
Could that be what is happening in the Agile community today? Could it be that the failures are not failures of the older Agile techniques to produce value in today's different environment? Could it be if we did the simple things we already know, most of the failures would be marvelous successes? This reporter certainly thinks so.
The next logical question is "why don't we do what we know will work?" This is a painful question. If we know what works, why don't we do it? Here is what I have found to be true: success of Agile adoption is 100% reliant on the people; the people practicing it must take ownership for their problems and face the ugly truths that surface in a disciplined manner. Note that these two facts don't fall under any of the Agile methods (new or old) but are implied by almost all of them.
But "facing the truth" and being "disicplined" are not easy things to do. There are people who are predisposed to this and find Agile techniques natural and empowering. There are others - and I would hazard a guess of greater than fifty percent of the population of human beings - that these behaviours do not come naturally. I know of no way to force people to do these things and I'm not quite sure that teams and organizations can be "changed" to do so. Thoughts?
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
RelatedVendorContent
Transforming Software Delivery: An IBM Rational Case Study
18 agile and lean practices for effective software development governance
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
You cannot change people if they don't want to
by
Sebastian Kübeck
Posted
Re: You cannot change people if they don't want to
by
Amr Elssamadisy
Posted
Re: You cannot change people if they don't want to
by
Sebastian Kübeck
Posted
Re: You cannot change people if they don't want to
by
Amr Elssamadisy
Posted
Re: You cannot change people if they don't want to
by
Sebastian Kübeck
Posted
Re: You cannot change people if they don't want to
by
Amr Elssamadisy
Posted
Re: You cannot change people if they don't want to
by
Jérôme Avoustin
Posted
Re: You cannot change people if they don't want to
by
Amr Elssamadisy
Posted
Re: You cannot change people if they don't want to
by
Jérôme Avoustin
Posted
Re: You cannot change people if they don't want to
by
Janet Moyer
Posted
Re: You cannot change people if they don't want to
by
Jérôme Avoustin
Posted
Re: You cannot change people if they don't want to
by
Sebastian Kübeck
Posted
Re: You cannot change people if they don't want to
by
Jérôme Avoustin
Posted
Re: You cannot change people if they don't want to
by
challe wdll
Posted
Re: You cannot change people if they don't want to
by
Sebastian Kübeck
Posted
20/80 rule
by
Greg Willits
Posted
Re: 20/80 rule
by
Amr Elssamadisy
Posted
Its more about the organisation than the process....
by
Ben Hughes
Posted
Re: Its more about the organisation than the process....
by
Amr Elssamadisy
Posted
Re: Its more about the organisation than the process....
by
Ben Hughes
Posted
Totally agree
by
Mr Magoo
Posted
-
I know of no way to force people to do these things and I'm not quite sure that teams and organizations can be "changed" to do so. Thoughts?
You know of no way because there is none. Dictatorships have tried to change people in the past but this didn't work either. You can make people obey but you cannot make them want something.
One thing you can do is to make the change gradually. When people see a benefit in every step you make, chances are better that they are willing to follow you.
However, there will always be teams and companies that resist the change and we will have to accept that. -
And so.... Maybe there is (should be?) a non-technical set of skills/attitudes/attributes that should disqualify teams and organizations from even considering Agile.
And furthermore, maybe we - the Agile community - should consider realizing that Agile is NOT for all software development teams. (I know we have never said this is a silver bullet, but I have yet to see a movement saying that "these folks shouldn't even try.") -
Like many movements, Agile got started by the craftsman of their trade. It probably wouldn't matter how they did the work, they would do well at it.
When a herd sees where its leaders are going, they're going to follow, but they're still going to behave like a herd. Comparatively uncreative, uncaring, and lazy.
When Agile is being performed by the 20%, it is going to look like a rock-star process. When it is being done by the 80%, it is going to accumulate blunders like everything else the 80% takes on. Simple population distribution.
However, I'd still rather have the herd doing Agile than anything else. -
I don't think that you can set up a simple list of skills/attitudes/attributes that you can tick of to tell whether a team disqualifies for an Agile transition.
Depending on the initial situation, an Agile transition can mean a pretty drastic cultural change not only in the team but in the whole organization.
Many organizations are not aware of this and in many cases, the only way to find out if Agile works or not is to try it out.
However, I don't think that an Agile transition that failed is always a bad thing. At least you know what is possible and what not in the given situation. -
'fragile', 'we suck less' and the like seem to born from the fact that if the organisation is not motivated to change it won't.
The most successful transformations are driven through desperation - cut costs of delivering or go bust.
Unfortunately, most (big business) gigs aren't like that - Agile is introduced for lots of different reasons, and almost all of them don't incite the kind of motivation to drive the deep introspection that is required to get the best out of the organisation.
Tis why startup's are such fun places to work. You can taste the fear of failure. -
I know of no way to force people to do these things and I'm not quite sure that teams and organizations can be "changed" to do so. Thoughts?
You know of no way because there is none. Dictatorships have tried to change people in the past but this didn't work either.
+1
"If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. " Antoine de Saint-Exupery -
I don't think that you can set up a simple list of skills/attitudes/attributes that you can tick of to tell whether a team disqualifies for an Agile transition.
I would disagree. I have never seen a successful agile team that did not take ownership of their problems. Neither have I seen one that was successful without discipline. I am not suggesting these are sufficient, but they *are* necessary. -
However, I don't think that an Agile transition that failed is always a bad thing. At least you know what is possible and what not in the given situation.
Not sure I agree here either. If we know it is going to fail, wouldn't it be wiser to spend our time, effort, and $$ elsewhere? -
When it is being done by the 80%, it is going to accumulate blunders like everything else the 80% takes on. Simple population distribution.
However, I'd still rather have the herd doing Agile than anything else.
Hmmm.... I'm not sure it is 'rockstars' vs. 'herd', but that being said, why would we want to imprint what works for one set of people on another set?
Wouldn't we all be better served by finding something else for those for whom this is a bad fit? -
Tis why startup's are such fun places to work. You can taste the fear of failure.
Well put, so FEAR is enough to push us through these really basic human growth spurts. Doesn't that also imply that given the lack of fear, the best thing we can do for a company/org is to work on the basics before going Agile? -
Have been saying similar for some time.
All this stereo typing and boxing and calling this agile and that not agile and only one way works. The team must be the one who changes 100% and not the process.
Total rubbish.
Teams have dynamics and strengths and weaknesses. You have to work out what works for your teams. The teams change, the process adapts also.
Of course which, when and by how much is part of the art. Incremental and via retrospectives is definitely the way to go. -
If we know it is going to fail, wouldn't it be wiser to spend our time, effort, and $$ elsewhere?
Sure, if you are able to find out that it wouldn't work, it's better to stop as early as possible. If not, you have to find out later.
I have never seen a successful agile team that did not take ownership of their problems. Neither have I seen one that was successful without discipline. I am not suggesting these are sufficient, but they *are* necessary.
Yes, these attributes are necessary if you want to be an Agile team. As many others are. The problem is that it is not so easy to prove that they are in place.
Some teams pretend to take ownership of their problems while you are there and fall back to bad habits once you are gone.
Note that we are talking about difficult and hopeless cases here. Fortunately, there are plenty of highly motivated teams with sufficient support from their organization around where the transition to agile really makes sense. :-) -
In the main - yes.
Certainly, big companies often have maxed out in the Peter Principle and have plenty of cash (gentle nod in the direction of the financial sector) are the hardest to change, as the desperation is not apparent.
Ben -
Sorry Sebastian, but you should read The Toyota Way (Jeffrey Liker).
You would be very surprised !
Specially, Liker is talking about motivating methods (Maslow, Herbitz, Taylor, etc.), and explain how Toyota use each type of to serve their primary goals. It's not about software development. But it IS about motivating people and bulding Teams, with a big 'T' ! :)
And yes, people employed in such a company are among the best, because of their Toyota-Way-compatible mind.
And yes, it takes a long time to bring these people to maturity. But -
If we know it is going to fail, wouldn't it be wiser to spend our time, effort, and $$ elsewhere?
But Agile is all about revealing problems ! It's not anything else !
Agile helps organisation to get better by solving the problems immediately, when they appear.
So if you stop the transition while you meet the first problem, you don't use the benefits of Agile !
People who dislike Agile is because it forces them to face their own problem, and their own defects. -
There is an implicit assumption here, that the people adopting will take ownership for solving the problems and not blame or any other non-productive action. What if it is in their nature not to do so? Will more 'agile' training help?
-
Agile is a f**king religion letting alot of so called "experts" on the field earn tons of money. The amount of energy and devotion that goes into this sacred belief should be invested in programmers that can solve issues rather than bloat project leaders. I cant really say i had one projectleader, scrum trained or not, that has helped me in a significant way during my 10 years professional life.
-
What if it is in their nature not to do so? Will more 'agile' training help?
Agile doesn't prevent people to be good... or to be weak.
Agile juste tries to help them getting better.
But if people don't want to be better, it's not a problem of Agile anymore, but of psychology. By the way, in a canadian company, one of the best scrum master is not an IT professional, but a psychologist !
And as I said, Agile tries to help people asking questions. There's nothing in Agile that give them answers. -
Jérôme,
I have read the Toyota Way and I really liked it.
And yes, you can motivate people but it takes the right environment to be successful and sustainable.
The advantage of Toyoda is that the whole company is living the philosophy.
However, we have to accept that there are other companies around that live a different philosophy that isn't - let's say - compatible with the Agile way of doing things.
In the latter case, it it is often not possible to implement Agile.
Jeff Sutherland addresses this in introducing Scrum to top level management first. If he gets the support he needs, he moves on to instruct the teams. -
...
The amount of energy and devotion that goes into this sacred belief should be invested in programmers that can solve issues rather than bloat project leaders.
...
challe,
seems that you are a victim of "Scrum But" or the like.
Could you please explain how you came to this conclusion? -
If he gets the support he needs, he moves on to instruct the teams.
That's exactly the point !
Whatever you can try, it you don't have a "high-level support" it may be more diffcult, or even impossible !
That is the real problem.
But I still believe that you can motivate teams, and build really efficient organization, if you have it. Even if it takes time !
21 comments
Watch Thread Reply