Analytical-Mind

In their recently released study “Agile Development: Mainstream Adoption Has Changed Agility“, Forrester reports that “35% of respondents stated that Agile most closely reflects their development process”. The report is based on Forrester’s/Dr. Dobbs Global Developer Technographics Survey, Q3, 2009, which surveyed 1298 application development professionals.

In the past few years, Agile processes have not only gained increasing adoption levels; they have also rapidly joined the mainstream of development approaches. And while more organizations are adapting to Agile conventions, Agile is also adapting to the workplace. Perhaps the clearest sign of the mainstreaming of Agile is the abandonment of orthodoxy: Teams are puzzling out the mix of methodologies and combining them to fit within their organizational realities, blending Agile and non-Agile techniques and practices to create a hybrid methodology that fits larger organizations. Other changes, such as new team dynamics and the redefinition of roles such as the business analyst, show the genuine force behind Agile adoption. It’s time for software development professionals to stop sitting on the fence where Agile is concerned. According to those who have successfully adopted Agile, the benefits are well worth the effort, and with the recent dramatic increase in Agile adoption, the probability of working in or with an Agile team has increased for everyone.

The report looks at Agile Adoption from the following perspectives:

• Agile Adoption Goes Mainstream
• Teams Are Changing To Support Agility
• What it means
• Agile Becomes Mainstream — But Not Without Some Changes

And then offers a recommendation to get the most out of the transition: “App Dev Professionals Should Blend Agile Methods To Meet Their Own Needs“.

Agile methods encourage more-collaborative development than do traditional approaches, and many developers who have shied away from formal development methods in the past — believing them to be the province of “management” — have embraced Agile as a “formal” development process.

The report shows that of the various methodology, Scrum leads as the most adopted Agile methodology with 11% of the organizations reported using this approchach.  Other Agile approaches used are: Agile Modeling (6%), Feature-driven development – FDD (3.8%), Test-driven development – TDD (3.4%), eXtreme Programming – XP (2.9%), Lean development (2.1%), Microsoft Solutions Framework – MSF for Agile (1.8%), Agile Data Method (1.6%), Adaptive Software Development – ASD (1.3%), Six Sigma (0.9%), Crystal (0.3%), Behavior-driven development – BDD (0.2%) and Dynamic Systems Development Method – DSDM (0.2%).

When it comes to selecting an Agile methodology, Scrum is the overwhelming favorite – claiming it is simple, practical, and popular.

The report shows that when organizations select a development approach, they do so in the context of their organizational priorities and characteristics. Each organization carefully selects the approach that will best address their weaknesses rather than implementing Agile methodology for its own sake. In addition, participants considered the engineering processes to be critical to the success of the transition.

Teams do not usually implement all of these techniques simultaneously; even in the most mature Agile adoptions, teams pick the techniques that work best for them (…) This variation in the adoption of Agile components indicates that teams are more concerned with making sure they are working well together and producing high-quality software than with changing their software engineering process.

Perhaps the most important aspect of Agile’s entrance into the mainstream is the way that teams pragmatically mix methodologies. Instead of sticking strictly to a particular Agile orthodoxy, teams cherry-pick Agile methods, often including non-Agile techniques in the mix as well

Overall, the report clearly shows that organizations who have transitioned to an Agile approach use a pragmatic strategy and adapt the methodology that are best suited for their environment and context. While only 27% stick to a particular methodology, 63% mix different methodologies or mix Agile with non-Agile methodologies.

In conclusion

Agile adoption is a reality. Organizations across all industries are increasingly adopting Agile principles, and software engineers and other project team members are picking up Agile techniques. While historically, management has owned “process,” the adoption of Agile methods has pushed ownership into the hands of team members — many of whom have traditionally been skeptical of process and methodology. Broad Agile adoption requires careful consideration; a strong Agile adoption strategy should include:

• A support plan. Adopting Agile practices is not a trivial change; it requires support and time to become effective. The use of external coaches, training materials, and internal support groups can greatly increase the speed and success of adoption.
• Flexible adoption models. One size does not fit all.
• A focus on team empowerment. It sounds really easy, but this is about more than just saying that teams are empowered.
• A tool strategy. A single team in one location working alongside a customer may be able to work without any electronic tools, but as organizations scale and teams become more distributed and part of much larger releases, Agile methods benefit greatly from tools.

Related Research Documents

• “From Agile Development To Agile Engagement” - May 6, 2009
• “Ensure Success For Agile Using Four Simple Steps” - March 24, 2009
• “Make Agile Lean To Boost Business Impact” - December 17, 2008

The Experiment

I attempted a small experiment with my kids a few weeks ago – get them to voluntarily help clean the house. If you have children between 7 and 10 year-old, I’m pretty sure having your kids help with cleaning is nothing short of a nerve-wrecking experience. If you don’t have kids, the process typically goes like this:

• You – “Timmy, can you please pick up the toys in your room.”
• Timmy – “Why?”
• You – “Because your room is a mess and I break my face every morning when I come wake you up.”
• Timmy – “OK, I’ll clean up.”

30 minutes later, you go see Timmy.

• You, slightly annoyed – “Timmy, what are you doing?”
• Timmy, looking up – “I’m building a castle, daddy. You want to play with me?”
• You – “Yes, I’d like to play with you as soon as I’m done cleaning up. Why didn’t you pick up your toys like I asked you too?”
• Timmy – “OK, I’ll clean up”

30 minutes later, you go see Timmy

• … (you can guess the rest)

So, back to my experiment. A few weeks ago, while my wife was grocery shopping I decided to use an adapted version of Scrum. I called my son and his twin sister and told them we would do a little activity. To their enjoyment, they were wondering what I had in mind. They sat next to me at the table while I the took 4 x 6 index cards and on each of them, I wrote a task: pick up the toys, put your clothes in your drawers, empty the garbage cans, bring the recycling to the garage, put the Tupperware away in the drawer, vacuum the floor, etc.

• My son – “Daddy, why are you writing these down?”
• Me – “We’ll play a little game.”
• My daughter – “Can I play too?”
• Me – “Of course. Here’s how it goes. I wrote 8 cards and each card has a little task. I need you to help me clean up the house while mommy is doing grocery.”
• The twins – “OK, what do we do with the cards?”
• Me – “You will each select the cards (the tasks) you would like to do. You then decide in which order you want to do them.”
• My daughter – “Daddy, some tasks are longer than others. What do we do about that?”.
• Me – “It’s up to you to decide.”
• The twins – “It doesn’t matter. We’ll decide which ones we pick.”
• My son – “Do we get a reward for doing the work?”
• Me – “Mmmm, good question. I know you like to read. How about I give you tokens for each task? Once you get 50 tokens, I’ll buy the book you asked me.”
• My son – “OK.”
• My daughter – “Can I buy a beeds set instead of a book?”
• Me – “Sure.”
• The twins – “Can you write how many tokens each task gives on the cards?”
• Me – “Good thinking! Picking up the toys is 3 tokens, bringing the recycling to the garage is 1 token, …”
• The kids – “OK, but who picks first?”
• My son – “Let’s do rock – paper – scissor.”
• My daughter – “Yes, let’s do rock – paper – scissor.”
• The twins – “ROCK, PAPER, SCISSOR…”

After determining who would start, they quickly picked the cards and started doing the assigned task. At their own pace, they executed on the cards. Then, something cool happened.

• My son – “Daddy, can we add a card? We need to water the plants.”
• Me, laughing – “Of course. Who’s going to take this one?”
• The twins – “Me, me, me!”
• Me – “I guess we’ll have to write another card so you are even.”
• My daughter – “Can I dust the bureau? I saw mommy do it the other day and I’d like to do that.”
• Me, with a big smile – “OK, if you’d like to do that. I’m OK with this.”

Together, they successfully completed all their tasks. All of their tasks! No fighting, no screaming. That was a “proud moment” Imagine when my wife got back home after the grocery…

With the Xmas Holidays and the broken routine, I was pleased to see my kids grabbing the cards by themselves this past Saturday and starting to execute on the routine. “Wow, this self-organization thing really works! Even with kids…”, I told myself.

The Take-Away

If you want people to carry out a task, here are a few suggestions:

• Describe the task;
• Let the team self-organize;
• If the team needs help, you may suggest tools or a process – but do not impose them;
• Get out of the way;
• If possible, make it fun;
• That’s it.

Do people become less trust worthy when we start paying them? Do we trust people more when they do something for free?

[Although I also wonder if we trust people more when we pay them a lot of money, I will keep this thought for another post]

This question about correlation between Trust and Money came to me this morning after a good night of sleep. I’m currently reading a couple of interesting books as I often do. One of them focuses on a better way of managing projects (Agile Project Management with Scrum) while the other is about Internet communities (Citizen Marketers: When People Are the Message). Both books are interesting in their own way – I’ll publish a short review once I’m done reading them.

The Agile software development approach suggests that development team self-organize in order to deliver quality software that adds value, on time. For most managers, this approach is counter-intuitive. If people self-organize, how will they actually deliver what we expect them to, let alone delivering value?

It dawned on me that there are many examples of self-organized groups of people that exceeded the expectations in the value they deliver. What would have happened if Jimmy Wales and Larry Sanger didn’t trust people when they launched their project for Nupedia? With over 11 million* articles in 236* languages, Wikipedia is a great example of self-organized people. And what about Trip Advisor with over 15 millions* travellers voluntarily contributing content in order to help fellow travellers. Not to mention the amazing collaboration between amateur photographeurs on istockphoto.

These are 3 simple examples of amazing results when people are trusted. So why do managers and their organizations still feel they must control their teams and the processes they use in order to obtain results? Why do they feel they need to implement strict processes and close monitoring instead of letting their team self-manage with an Agile approach?

It could be argued that the Internet communities presented above succeeded because they shared a common goal. Which leads me to ask, don’t we believe employees could share a common goal?

* At the time I wrote this post.

In the context of launching a new consulting practice, I’m reviewing documentation and compiling examples in order to explain to potential customers the benefits of the Agile approach in the context of Business Intelligence.

I’m currently reading Agile Project Management with Scrum and after watching the hockey game between Montreal and Tampa Bay, an analogy came to mind. Can we compare the Scrum approach to project management with hockey?

Although the analogy used by Schwaber in his book is very easy to understand (the Scrum master is similar to a sheppard dog who needs to protect his sheep), I found his comparison to be simplistic and slightly degrading for the development team (sheep?!).

The analogy could have been with baseball but the Expos left Montreal in 2004, or between Scrum and football but are the Alouettes/Concordes/Stallions/Alouettes really that popular? or between Scrum and soccer (the European football) but I preferred to use hockey – being our national sport.

• A hockey game is divided in 3 periods (sprints).
• The coach acts as the Product owner who provides requirements in order to reach an objective – winning the game.
• The team captain is the Scrum master: he/she is a player just like the other players on the team but has additional responsibilities in the context of the game.
• The coach providing feedback between each period is a well entrenched feedback process.

So my question is, does this analogy work for you? Would potential customers be able to easily understand Scrum if you used the hockey analogy?