At the Agile Testing Days conference last week in Berlin Rob Lambert presented on how excessive structure kills creativity and what that means for agile software development. One of his main arguments was that making agile development palatable to larger companies pretty much defeats the key points of the Agile Manifesto.
Lambert said that creativity is crucial for software development problem-solving and a key factor for exploration, adapting and iterating, which are some of the core values shared by successful agile software delivery teams. Some structure is required to facilitate creativity, but excessive structure kills it, said Lambert. “We need enough structure”, said he, presenting several case studies of very creative companies. According to Lambert, the features of teams with “enough structure” are:
- people and their talents are a sole measure of competency
- they do not use generic best practices but apply relative judgement
- they spread skills and merge roles
- they create cross-functional teams
- they empower teams
This leads to short feedback loops, responding to change fast and craftsmanship. People in such teams are treated as humans, not as resources, according to Lambert. With excessive structure, people are treated as resources and the environment creates long feedback loops and slow responsiveness to change. He gave several examples of excessive structure:
- formal education and certificates as measures of competency
- enforcing generic best practices for everything
- creating silos of skills
- putting barriers between teams
- enforcing layers of approval
Lambert then said that Agile Manifesto is an example of “enough structure”, and that it supports creativity in teams. Opposing the trend to adopt agile development because “of its coolness”, Lambert said:
Moving to agile won’t make you creative.
It doesn’t mean that you can only be creative if you are agile.
But if you remove excessive structure, and have just enough of it, creative open minded people will naturally gravitate to you.
He warned against making agile “more palatable to companies who would not adopt them in the first place”, saying that the calls for quantification and certification of agile skills and teams create a risk of putting in too much structure. There is no such thing as “A scrum team is able to produce this… and if your team doesn’t, you can do this …”, said Lambert. Introducing metrics and check lists for what makes a team agile might make it easier to larger companies to adopt something, but that has nothing to do with original ideas of agile development. “It’s just a complete myth”, said Lambert, adding that “agile has been working fine”.
I’m not so sure about talent being a sole measure of competency, because lots of talent can lead to no effect without effort and utilisation, but I do agree with most of the other points. Certification and checklists do make it easier for large organisations to adopt the agile cargo cult, but I do not see how this can give anyone any benefits apart from the organisations that sell certificates. (Which was nicely picked up by Tobias Mayer recently in his blog post where he tries to wash his hands from certification like a modern day Pontius Pilate).
See the presentation slides on Rob’s blog.
Also see other articles from Agile Testing Days.
|
|
Interesting post.
Certification a myth? Perhaps, at least in the method that is typically done today (pay $50, receive certification in the mail).
Quantification a myth? That’s less clear. Quantification is certainly difficult, because software is difficult to measure. I recall a post from a business management blogger who had a definition of business agility that essentially boiled down to a certain percentage higher than average return on investment versus the rest of the market. It was an interesting post to consider in the light of software development processes, because agile processes typically focus on putting user needs in front of complex processes like waterfall. But when we measure agile processes we often take a process-centric approach rather than a results-centric approach.
So I’m not sure that agile processes aren’t measurable, but would agree that certification does not measure them.
I share concerns over certifications. Strong or weak, they are not good enough and a sop to companies and individuals.
I believe that Lambert’s list is far too idealistic to be workable. As you allude to in one area, and it’s true in many areas, a team could have the characteristics he lists and still be entirely unproductive. It’s a good list but does not solve the competence problem either.
I do not understand why you took a swipe at Tobias, who has relinquished all of his certifications and no longer offers them. What did you want, ritual suicide?
I got this comment from Tobias Mayer my e-mail:
I am not against certification. I am against meaningless certification. And I am against organizations (like SA and scrum.org) which exist for the sole purpose of certifying people.
I ran certified Scrum classes in the past for two reasons: 1) I semed to be the best way in to helping people learn about this way of working. Companies were prepared to pay for their employees to learn Scrum if they got a piece of paper afterwards, and 2) because it actually helped unemployed people get jobs (I ran a program called WelfareCSM which offered this training at about one tenth of the normal cost).
In the end though, these justifications were not enough. I made many efforts to change the nature of the SA certification model, but was defeated every time. After the last change in policy moved in exactly the opposite direction I was hoping for I realized enough was enough, and got out.
I like to think people benefited from the training I provided, and have gone on to put it to good use. I know that some did — usually the ones who cared nothing for the certification. I continue training, teaching people many of the same concepts, values and practices as I taught when I was a CST, but now it is without certification.
— As to your post, I agree that excessive structure kills creativity, but I am of the belief that large organizations can change. They do not need to be structure-bound. The foundational principles of Scrum (etc.) can be applied in many contexts, to great benefit. generating a deire for innovatiuon and creativity is perhaps the first step in dismantling some of that rigid structure.
@Ron,
I don’t want anything. Getting in or out of a certification program is someone’s professional decision and it’s not up to me to advise on other people’s business plans. I just find it amusing that CSM started to blow up and that people now want to wash their hands.
I remember a discussion on one of the Agilar mailing lists about getting involved with a certification program when I raised my concerns about it blowing up the same as MSCD and Sun Certified Java Engineer, but unlike those scams where there was no community that CS* will damage the reputation of the people who were left without a chair when the music stops.
> I just find it amusing that CSM started to blow up and that people now want to wash their hands.
How is CSM blowing up? With the latest press release from the Scrum Alliance, and all the work ken Schwaber is doing at scrum.org with alternative Scrum certification it seems that it is being reinforced.