Everytime I get in an argument with someone over Agile or XP (I'm not a proponent which I found out means I am definitively an opponent) we basically end up solidifying our disagreement and it usually ends with them saying "Well, you just don't get it."
Clearly.
I especially don't get this new craze of a job of "Agile Coach". I mean, everything I've read about Agile and XP seems dead simple. (then again "i dont get it")
Pair Programming
Iterations
daily standup meetings
customer collaboration
etc
I even did XP at Morgan Stanley for 6 months and it was no rinky-dink attempt either. We hired 2 consultants from Object Mentor, in addition to Josh Kerievesky. We seemingly had all we needed but the project crashed hard. I don't specifically blame XP - I think the project was shaky and the dot-com bubble finished it off (I left after my contract was up, but some 300+ were laid off and the office closed soonly thereafter). Josh did the post-mortem, not sure what he concluded.
But I'm still confused why I need a "coach" for Agile. I'd WAY rather have a coach for Java Generics, type theory, or God-help me, C++ templates. That stuff is definitely harder. Comparatively, agile seems a no-brainer. Seems like if you need a coach for something as trivial as Agile, you haven't a prayer with the type inference used in Java Generics or traits in C++.
The only thing I can come up with is that an Agile Coach is not really a "Coach" so much as a hall monitor or a secret police officer. As in - Agile is not fun (or maybe even inefficient for some people/circumstances) and people keep trying to stop doing the dumbest parts. Then, you need a "coach" to come in, serve kool-aid, and yell at them to start doing it again. Now mind you, the coach doesn't exactly yell at you - he more like "coaches" you like you're missing the point. He comes in like:
"Oh no no no.. you're doing pair programming all wrong!!! You're supposed to have TWO people for pair programming!!"
"Really!!?? OMGosh. I was wondering what the hell fruit had to do with all this."
"Yeah!! Thats why they call it PAIR programming!!!"
"Ha. like pants!"
"Yeah! like pants!"
"OH! But, um, does my stuffed monkey count?"
"Hrm. um. Good question. Lemme go email Kent Beck".
I really have nothing against Agile or XP. Its pretty much common sense stuff. Tracking and predicting your progress on any project (bridge building, designing car engines, or software) is pretty reasonable. Meeting everyday might be overboard in some circumstances but it might not be too. Testing is embedded in all work-related stuff I do anyway - bring it on.
I'm just a bit skeptical I need a "coach" to make sure I'm standing up correctly at my daily meeting. Some jobs appear only when business is good and are the first to go when times get bad. If we assume that eventually, times always get bad - then I guess we'll find out if Agile Coach is one of those.
I am however a little disturbed about the zealousness of the people trying to sell me on it. It has all the makings of a religion. Followers, sermons, prophets, perpetually changing rules, holy books, faith, and high-priced consultants. And like I said, plenty of angry zeal. For now I think I'll remain "not getting it" and get on ebay and see if I can find a stuffed monkey.
13 comments:
Look at it like this: If you had a coach and the project fails, you had disproven the Agile.
Well, this cannot happen: Either the coach is good and will explain why this project failed despite of all his effort, or the coach had not been following pure agile methodology (an impostor).
In the unlikely (not a fault of agile or not most projects fail or at least do not deliver the original promisses) case the project is a success, the coach will get the bonus.
So it is a loss-loss situation hiring an agile coach. Why do people do this? Because most methodologies of the past and present are no better than agile but 100-times more complex, so that no one had virtually any chance of getting it right. The last sentence should not be mistaken to suggest that the other coaches had been more knowledgable, but it is interesting that something simple as Agile is sold as so difficult to do that we all don't get it/ do it right (so that we need a coach)
I'm an "agile coach". Many times I will tell a client the same things you have pointed out in this article; agile is simple being the key point. So why do I bother being a coach? Because despite it being simple, in many organizations, peoples habits and the corporate culture constantly impede the adoption of agile practices and culture. One of the most difficult aspects of agile is that it front-loads the learning and crisis in a project (or it should). Because an agile project should be delivering working, potentially shippable software at the end of the first iteration (usually <20 working days after the start of the project), all the crisis that normally shows up at the end of a project instead shows up at the start. This can be discouraging and upsetting. It can make people want to go back to the old comfortable way of doing things.
So yes, as a coach, just like as a personal trainer or sports team coach, a lot of the time I am there to remind, encourage, motivate, cajole people to follow the practices, to give it a good shot.
Hi. Your view is a reasonable one. I, as a developer who is spending maybe 75% of my time coaching, have a different one. Sorry this is a little long, but I think the "you just don't get it" thing is kind of a bullshit answer.
I just finished with a six-week boot-camp style excercise program. It was four one-hour sessions a week of all sorts of exercise, with a lot of running. Now in theory, I know how to run and learned shortly after I learned to walk. So why would I pay somebody a few hundred bucks to coach me in it?
One, I actually ended up learning a lot: doing something I thought was ok was easy, but doing the exercises exactly right was far from obvious. And doing things right got rid of a lot of unnecessary pain and maximized the benefits. Second, having the coach there to help (or sometimes push) me through the rough spots kept me from giving up in frustration. And third, doing it regularly with a coach kept me focused and helped develop the habit of doing it and doing it right.
I'm sure you're right that in some organizations, coaches are in effect agile secret police. I think that's foolish, and a waste of money. The only clients I take on are ones where the team is interested in trying agile methods to see how they work for them. Like my boot camp coach, I help people improve in things they care about improving. You can create the appearance of change with externally imposed harrassment, but it's not real change, and you don't get the real benefits.
Interestingly, two of the practices you mention, pair programming and daily stand-up meetings, are two of the easiest to get wrong. A few weeks ago I started with a new client that had learned stand-ups out of books. With 12 team members, they were taking circa 45 minutes and everybody hated the meeting: it was too long, it was boring, and it was uncomfortable.
When I saw them, my first thought was, "Well no wonder they hate it. They're doing it wrong!" They were too spread out, the shape was wrong, everybody talked only to the manager, they talked about the wrong things, there was no sense of energy, and yes, they weren't standing correctly. Now a few weeks later, they're much improved. It's 10-15 minutes long, and the meeting is taut and energetic rather than vague and flaccid.
There's also something I can do that employees generally can't: I can tell managers when they are the issue, when their well-intentioned efforts are screwing up the team. I end up doing this quite a bit. Why me? Because I'm always moving on to the next gig anyway, I don't mind losing a job. If the manager is the problem and won't listen, then I've got better things to do.
Ok. I hope that helps. Feel free to drop me a line if you want to discuss it further.
As a clarification.. the "I don't get it" is an answer that has been said to me by people arguing in favor of agile.
Usually, its a nice heated argument and when they run out of counterpoints, this answer has been used as a fallback. Obviously this hasnt happened in all cases, but its definitely happened in more than one.
To me, its like arguing religion with someone and eventually they just say "Well, because God says so". They won - sorta.
Sorry - I still dont buy it. I just have this innate sense that the points of Agile are trivial. And if you need a coach for Agile, you really probably don't have a prayer for understanding the type inference used in Java generics.
And to quote you:
>When I saw them, my first thought was, >"Well no wonder they hate it. They're >doing it wrong!" They were too spread >out, the shape was wrong, everybody >talked only to the manager, they talked about the wrong things, there was no sense of energy, and yes, they weren't standing correctly. Now a few weeks later, they're much improved. It's 10-15 minutes long, and the meeting is taut and energetic rather than vague and flaccid.
By this you imply that after you fixed things, people loved it - is that true?
There seems to be some notion that Agile is ultra precise and any divergence would screw it all up. I dont buy it. On the other hand I hear that you don't have to follow it to the letter - you need to make it flexible per team. So which is it?
Meetings every other day (instead of daily) or single-programming or tri-programming can work.
Its just too damn easy to find a tiny divergence from gospel when agile doesnt work and blame it on that.
And now I contradict myself - I dont think Agile works or doesnt work. Its one of a BILLION ways to run a software team - where thousands upon thousands will be successful with no evidence to indicate what might be the best. I'm sure it works great - just like the other few thousand methodologies.
blech.. the original article was much more fun than this ranting.
cheers
Hi Paul,
>There seems to be some notion that >Agile is ultra precise and any >divergence would screw it all up. I >dont buy it. On the other hand I >hear that you don't have to follow >it to the letter - you need to make >it flexible per team. So which is >it?
Good question. Well, let me put it this way - for every rule, there is a reason.
The reason for a standup meeting it to keep everyone in the team updated with what is happening in the team. This is required because in agile there is a focus on working together, rather than in traditional methods where everyone works in isolation. The time limit is there to keep it quick and energetic, as everyone knows how terrible long meetings can be.
Now, if you come up with another method of keeping everyone in the know, and it is working, then it is perfectly okay to do that instead of a standup. This is 'good variation', where there is a reason for the variation that has been applied with an understanding of the situation.
'Bad variation' is when you are not following some rule, just for no reason, maybe old habits or something else. The example is the 45 minute stand up, naturally everyone finds it boring. If there was a good reason for it being 45 minutes long, maybe it would not have been a problem, but in this case there was no reason, the rule was being broken due to lack of understanding. This is a case of 'bad variation'.
A good agile coach understands the principles and reasons behind the principles, and is in a position to guide the team on this. If the team themselves really understand, not just the princles, but the reasons, and they are able to fit the process by doing 'good variation', then there is no need for a coach.
Also, just like Tiger Woods cannot always see the flaws in his swing, the team cannot always see the flaws in its working. In such a case, an outside perspective provided by a coach might help.
In the end though, the coach doesnt do any of the work. It is up to the team to succeed or fail. A coach is only a component, like getting a good coach will not make you Tiger Woods. Many other components are also important - management support, quality and dedication of team members, culture of the organisation and so on. The coach can help with one aspect - doing the process right, but a proper process will not guarantee a successful project, there are many more factors beyond that.
It is a common fallacy that if you follow agile, the project will magically become successful. It is not so. In the end, you have to look at agile, the culture, the processes and decide if it is a good fit for your company and team. I completely agree that there are a thousand different processes that can be successful if done properly. In the end, it is a question of what fits well within your team and organisation.
Hope that answered some of your questions.
Hi Paul. Thanks for your observations.
I too do coaching work... and my experience shows me that you are right: developers are pretty good at "getting it" - because they are closest to the work and know where the BS is :-)
As a coach, I help people spot counter-productive practices and think about how to return to common sense. In a place where these simple things have not been forgotten, Agile rolls out more naturally, and a coach isn't needed.
But some teams don't have the internal leadership to teach themselves the (admittedly, simple) practices, so hiring a coach can help - remember, some shops come out of a very dysfunctional process culture. Other teams do teach themselves, and later engage a coach for a tune-up or to diagnose persistent issues.
Every team's patterns are different, and self-training is a great pattern - because, in the end, the coach probably moves on, and it's what the team learns that makes the difference!
In addition, like William, one thing I do is help the organization get out of the way so these effective developers can continue to work well! Agile doesn't operate in a vacuum, but usually in concert with a broader organization. Sometimes it helps to have an outsider to work with management while the team figures out how they want and need to work.
I learned Agile from a book, and by doing it with colleagues, as did many of my contemporaries. Still, when asked, I'm happy to help others learn it. But, rest assured, I know I can't do it for them (and so I shouldn't take the credit, either :-)
On the topic of project success and failure: I found Peter Coffee's recent observations interesting. Agile cannot save every project or team, nor should it. Some projects can't be saved. (And some aren't broken!)
Keep calling 'em as you see 'em.
Deborah Hartmann
Hi, Paul. I understood that the "you just don't get it" line is from other people to you. And generally, I think when people say that, it's bullshit. It'd be more productive if they say something like "I guess I don't understand it very well," or "I don't know how to explain this better."
Responding to some of your comments:
"Sorry - I still dont buy it. I just have this innate sense that the points of Agile are trivial."
Once one gets the spirit, I agree the details are trivial. On the other hand, until one does, the details are crucial. It's like learning to ski: once you learn, staying upright and moving fast is a million small corrections, all obvious and natural. But while learning, you eat a lot of snow. Perhaps software process is already trivial for you, in which case, carry on. For my clients, I help them to minimize the number an severity of head-in-snowbank incidents.
"And if you need a coach for Agile, you really probably don't have a prayer for understanding the type inference used in Java generics."
It's a different set of talents and skills. If you find Gardner's model helpful, then it's much more about inter-personal and intra-personal intelligence than the verbal and logical intelligence that development demands. Saying that team dynamics should be obvious to anybody who can handle generics is like expecting someone who writes C compilers to be a sharp dresser and the life of the party. Not that it doesn't happen, but it's not a gimmie.
"Its just too damn easy to find a tiny divergence from gospel when agile doesnt work and blame it on that."
I know people do that, but that doesn't strike me as a very productive activity. Ultimately, the practices have to be measured by each team to see whether they find them helpful. I find discussions of orthodoxy and blame mainly get in the way of seeing what is going on for a team and what might make it better.
And that's how how I got into this. I tried the practices and found they worked for me: higher productivity, greater job satisfaction, higher quality, and better relationships with both suits and fellow geeks. I expected they'd work for others, too, and my coaching experience generally bears that out.
"I dont think Agile works or doesnt work. Its one of a BILLION ways to run a software team - where thousands upon thousands will be successful with no evidence to indicate what might be the best. I'm sure it works great - just like the other few thousand methodologies."
I'd agree and go even further. I think the main success criterion is that a group cares about continually improving how they produce software. (And in that group I'm including everybody, not just the people at the keyboards.) If they have that attitude, having external advice on process may be useful, but it's not vital. And if a group doesn't care about that, then all the process books and coaches in the world won't make things better. In fact, they'll make them worse -- without a shared desire to improve and the room to do it, the imposition of yet another process framework is just a distraction from the real problems.
Hi Paul - I am also a coach. Agile is completely counter-intuitive to the way teams (and organizations) have behaved for decades. Sure, on a slide it's a straight-forward, common sense approach, but agile = organizational change, and that's no easy task. As a coach, I am there to give advice and relate experiences to help a team along the agile adoption path. Often this means discussing agile impact areas with management, which is sometimes better received from an objective third party.
As creatures of habit, people easily slip back into what's comfortable, and I'm not talking about pajamas and bunny slippers here. This "reverting to form" is easy to do, difficult to see yourself doing it, and sometimes takes an outsider to help you through it.
Humorous post... I caught myself chuckling a couple of times (pair programming)...
Hi Paul,
Interesting post.
"And if you need a coach for Agile, you really probably don't have a prayer for understanding the type inference used in Java generics."
Well, Java generics aren't that bad, and if you need a coach for that, you probably don't have a prayer for a programming career in the first place.
Just kidding.
I agree, the reality is that there's little to Agile--at least from a definition standpoint. It does make a difference, however, to have someone who can spot problems on a team and come up with the best possible resolution (agile or not). Sometimes this can't be done by the team--it's often hard to see the causes of your own problems, because you're buried in the thick of them.
Any chucklehead can figure out how to use story points or how to stand up, as you suggest. But the problems in agile, or any process, are usually people problems, and solving those is tougher than figuring out how to comprehend something technical.
You can call yourself a coach after reading a book or becoming a "master" after a two-day class. But a true coach is capable of honing the rough edges around the team, avoiding inevitable pitfalls, or getting out of pitfalls when we fall in. That's not a skill everyone has.
A good coach is also technically capable. Most of my hands-on work has been in the area of helping out with programming and design skills. It's not easy to learn how to deliver quality software every week, and lack of solid design skills will turn attempts into a disaster.
-J-
What a fun read. Why do you need an Agile Coach? Heck - I have no idea and I am one. Let me explain......
I have drank the CMMi, ITIL, ISO, and Six Sigma Koolaid yet fully supportive of "agile" above them all - in any organization. I am old and my experience is vast. You don't need coaches to improve an organizations project delivery nor do you need a coach to implement agile practices.
If that is your focus.
It all begs the question of what are you trying to do? Improve time to market, increase quality, create chaos, or implement a framework where none exists? Or are you taking an existing embedded risk adverse process and transforming the organization to one that is more responsive to the industry (competitive)? That is something entirely different and does require a coach.
The challege isn't teaching people practices at the grass roots level, applying new metrics or even ratting on the teams who are cheating. The challenge is to consciously plan the transformation to keep the organization stable and get the most gain you can while it is changing. We are asking adults, old dogs, to change their behavior and the very things that made them successful to date. These behavior changes occur at all levels of the organization and needs creativity and tolerance. It also needs someone at the helm who can take the truth and accept that banging your head against the wall a billion times is sometimes ok. Changing cultures and mindsets that allow agile practices to work in risk adverse environments aint easy. Bringing in a consultant who has this experieince to help the leadership craft the roadmap to a new vision, change it based upon feedback loops all while the organization is still functioining is invaluable. "Managing" emergent practices and processes requires leaders to think differently much like the reconginzed differences between entrepaneours and leaders who manage day to day operations. Both are needed, but at different points in the organizations life cycle. Coaches help existing leaders change, without going through expensive failures.
So do you need a coach? As with most emerging process discussions, the answer is " it depends."
Your volley.
Sounds like you are getting a mentor, not a coach. A coach will help you to find the practices that work best for your team and aide you in making importnat decisions, however, all the calls made are those of the team. If teh coach is telling you what to do then get another coach.
Post a Comment