Tracking change and innovation in the enterprise software development community
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Free Book Offer
SOA Demystified
$40 Value
Posted by Deborah Hartmann Preuss on Oct 10, 2006
Martin Fowler, one of the original creators of the Agile Manifesto in 2001, reflected last week on reports of agile process being imposed on teams from the outside. He states his reaction succinctly: "Imposing a process on a team is completely opposed to the principles of agile software, and has been since its inception."An important consequence of these values and principles is that a team should choose its own process - one that suits the people and context in which they work.Fowler insists that imposing a process on a team is "a very red flag," but warns that from the outside it may not be possible to tell exactly what's going on - he says, "There are situations that may look similar from the outside, but aren't really the same." For example, he notes that the temporary imposition of a set of practices for the purpose of learning should not be assumed to indicate permanent imposition of those practices. Fowler states, "it's very difficult to tailor a process until you've used it for a while." He wrote about this in an earlier article on Extreme Programming - in which he identifies three levels of process maturity, where his "Level 1" corresponds to Alistair Cockburn's "Shu" stage (a concept drawn from the martial art, Aikido, and one which Fowler also uses). In this stage, particularly for XP, it's widely agreed that teams need to use the practices "as is" for a while, to understand the basic patterns before customizing them to suit their own situation.
Technical Debt and Design Death
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
From my experience in trying to get the teams I have worked with to go agile, I see the truth in what Fowler says. However, the reality is that you can't always build your projects around the ideal: motivated individuals and self-organizing teams. The inertia of old habits can be very hard to overcome. More often than not, non-agile teams will tend to keep following their non-agile ways and they will most likely never get around to going agile unless somebody forges the way and starts imposing agile practices and processes on them. These kinds of teams seem to be still in the majority in the rest of the world. Is there no hope then for the 80% of developers who do not belong to the 20% most productive teams?
As a student of Aikido, I too have been through the Shu stage of learning (still am). It takes a while to get used to doing things differently. Just as it takes a while to get used to entering into an attack instead of backing off from it, it takes a while for developers to get the hang of Test-Driven Development. And for the longest time, I could not bring myself to relax and receive the force of an attack rather than tense up and try to go against it. Many developers have the same kind of difficulty when trying to learn agile practices. It makes people uncomfortable to have to abandon old but familiar habits and adapt to a new style of development.
Students in the Shu stage of learning have form imposed on them by the instructor. What other option besides imposition do you have then to try to overcome the inertia of old habits and get developers rolling with the agile way of doing things?
I guess, for me the question is: was the instructor invited? or imposed? Once the instructor is there, yes, they need to deal with the "shu" phase as they see fit.
Can an entire IT organization, right down to developers and testers, "invite" the instructor?
Teams are usually aware that they are not doing things the best way. Most folks will say "Yeah, that's good. I wish we did more unit testing, continuous integration, yada yada." They're all about improving the process. At least on paper. But when you start asking them to do unit testing, attend daily scrums, giving updates on their tasks and other things agile, the old habits start to drag them down.
When students of Aikido go to class, they expect the instructor to have a system of instruction that structures the learning of techniques. In football, coaches have their "systems". Same thing with agile. With most teams, expecting them to self-organize and continue to improve is just not realistic, especially if they've never been agile before. So, even if they did "invite" the instructor and say that they buy-in to the "system", there often needs to be a certain degree of imposition to help developers overcome the drag of old habits.
I've imposed Agile practices on a team before, but I was the tech lead, working alongside the team. That strikes me as different than a manager reading an article about Agile and then sending a memo to some team they aren't familiar with and demanding Agile adoption.
I like the martial arts instructor analogy. It's very good. The teacher was invited, and expected to teach. That doesn't make it fun 100% of the time. :) But you stay because you want to learn and get better.
I've also introduced Agile practices to an organization by simply using them and letting others see how effective they were. Then you get others coming to you, asking you to help them use the practices. That's a great way to go "gradual agile". Introduction via grassroots.
True, imposition of agile by management, which is what Fowler talks about, is different and less likely to succeed than if it comes from a tech lead. However, tech leads are still often regarded as being a kind of "manager". And while the grassroots route may be a good way to introduce agile, it still does not eliminate the need to overcome that initial drag (I prefer to call it that rather than "resistance" because folks are willing enough, it's just that the old habits are hard to shake).
Take for example an incident that happened to me recently. One guy on my team was asking some questions about debugging, tracing, and logging. After talking about the different ways he could go about doing that, I mentioned an alternative: that writing unit tests really helped to cut down on debugging time. "Yeah, you're really good at that." was his reply which had the distinct ring of "Yeah, it works great for you but I'm going to do it this way because that's what I'm comfortable with." I had spent some time with him doing test-first programming a few days before and his reply surprised me in a way, and yet I suspect it is fairly typical.
Who is forcing you to go to Aikido class? My guess is nobody; you go because you think it will benefit you. Do you think it would benefit you as much if your boss ordered you to go and implied he'd fire you if you didn't?
The alternative to imposing agile methods is to persuading people that agile methods will solve some problem that is bothering them. For me, that works much better.
Perhaps there is sometimes a need to impose. Here's my take: cgardner.blogspot.com/#imposingagile
You're right, I go to class because I want to. But then other concerns of life make it hard to go as often as I want/should and I start missing classes. Same thing for agile adaption. When the going gets tough on a project and pressure mounts, adherence to agile practices often suffers, even though the team members know that doing so adds to their pain. In many ways agile is like dieting or quitting smoking: you know it's good for you but some find it easier to fall back on old ways than to stick with the program. Isn't this where management should start imposing on the team?
Isn't this where management should start imposing on the team?>
In my opinion, no.
Instead, I think management should ask why it is hard for them to do the right thing and aid them. And it's best if the manager does that in a way that moves toward great agility. For example, if the going is tough and the pressure is mounting, the manager should make use of the planning game and yesterday's weather to make the team's workload fit the amount of time available.
I think the only effective time for a manager to pressure the team on agile practices is when the team comes to them and says, "We really want to keep testing; please remind us when we forget."
Instead, I think management should ask why it is hard for them to do the right thing and aid them
That makes a lot of sense. And it's also a very Aiki way of approaching the situation: instead of trying to forcefully impose your will, you make a connection and gently guide the issue to a harmonious resolution. You'd think I would have learned that by now <g>. Thanks!
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
10 comments
Watch Thread Reply