Today I received this from Yahoo.

Here are the pics from my visit.

What an awesome time I had.

By now you probable have heard that John Deere is practicing Agile at scale.  What was less then a 100 people doing it under the radar has now grown into over a 1200 and counting.

But, what does it sound like?

Are they having fun or is it just talk?

Do Employees Like Agile?

How do you find out if employees actually like following Agile practices? You can either ask all of them or you have them take a survey. In one survey, we asked 300 random employees “If you were king for a day, would you want to continue to follow the Agile process.”

Guess what, number was?

70% – LOW

89% – Still LOW

95% – Low Again

100% – Almost

97% of the employees said they would want to continue to follow the process we have created (it’s not a process, it’s a culture.)

How Do I Explain What it Sounds Like?

For me, it’s simple (thanks to Animoto.com). You take a bunch of pictures with your phone and pick a song and your done.

Hope you enjoy the video.

The key to getting people open to learning about Agile is to have them experience it.

Say what? Yes, the trick is to get your attendees involved without you forcing on them.

But it gets better.

What if I showed you the steps on how to make this happen in any environment?

Keep reading.

The Secret to Getting People Engaged is from the Back of the Room

How can you teach Agile from the back of the room?

In the book Training from the Back of the Room Ms. Bowman teaches you techniques on how to not stand in the front of the room during training.

Just like the Agile Manifesto has its principles and values; Bowman applies six learning principles to improve the way students are taught:

1. Movement trumps sitting
2. Talking trumps listening
3. Images trumps words
4. Writing trumps reading
5. Shorter trumps longer
6. Different trumps same

Bowman then goes on to explain that the way we have been taught using lectures and PowerPoint’s does not work. People do not learn this way.

But the question remains: How can you do it?

How Can You Introduce Agile From the Back of the Room

To some people, teaching from the back of the room sounds crazy and asinine. I’ll tell you I was one of those people to. However, like everything I do, I continue to learn to get better.

Below are my step by step tricks on how to get to the back of the room when teaching about Agile

Steps:

1)      Give everyone the instructions on how to play the marshmallow challenge.

2)      Play the marshmallow challenge video.

3)      Ask the group to explain the process they used when building the marshmallow challenge

4)      Tell the group there is a process and it’s call Scrum. Watch quick 10 minute video on what scrum is.

5)      Discuss the benefits of using Agile. Deere is a great example.

6)      Then explain while a process is good; purpose, mastery and autonomy is great. Show them this video.

Those are my steps on how to get out of the front of the room when explain what Agile is. If you have other tricks, I’d love to hear them and try.

Lately I have had many conversations with scrum teams and Product Teams about how to apply an agile technique called story mapping to help facilitate creating incremental vertical slices. The goal is to create end-to-end slices (stories) that a customer would use.

A few months ago I read this blog and it really helped me understand them and then I instantly became mad that no one taught me this years ago.

http://www.agileproductdesign.com/presentations/user_story_mapping/index.html

In this video I’ll give you a simple example of how to create a story map.

In April I attended RallyOn11 in Boulder where I was introduce to Aaron Sanders one of the Rally’s Agile coaches. During dinner I explained to Aaron that I felt teaching Scrum using basic games and slides was ok but not great nor did it create the engagement and excitement I wanted to generate. Aaron asked me if I ever used Legos to teach Scrum. I replied with, “Nope, but please tell me more.” He went on to explain how he learned it from Geoff Watts another Rally’s Agile coaches basked in the UK.

After the conference I kept thinking how is it possible to play Legos and learn Scrum. Over the next couple of months I exchanged emails and phone calls with Aaron trying to get as much details out of him on how this actually works. I remember asking Aaron how much he spent on Legos during one phone call and he said, “$1000.” I then remember thinking, “crap how am I going to pay for this.”

Fast forward two weeks ago. I woke up on Saturday, four days prior to my scheduled Agile training in Moline. I opened the slide deck that I used once before and deleted all of the slides. That night my wife and I were at Toys R Us and purchased $500 worth of Legos. I remember her saying, “Not exactly what I thought we would be doing on a Saturday night.”

That Sunday morning my wife starting building Lego and keeping track how long each one took to be built. While she was busy keep track of time and building houses, I started building my slide deck based on the idea of building a Lego city that would teach all of the core concept of scrum like backlog, stories, story points, acceptance criteria and teams.

That Monday I emailed my manager and told him I just purchased $500 worth of Legos for my training class in Moline and Germany. I told him that if people felt like they didn’t learn anything, I would pay him $500 + the $100 for all of the wasted time.

Going into day one of the training I had 50% of it figured out told myself to go with the flow and inspect and adapt.

The first day went off without a hitch and the teams were excited to get building the next day. Below is a video describing how it all went down.

In recent weeks I have received many emails about what tooling do we use for large scale agile tracking. I am a big fan of Individuals and interactions over processes and tools, but when you have 600+ resources all over the world working together you need something more the sticky notes and whiteboards.

Back in January of 2011 we reached the point where are current tooling based on our waterfall process was not sustainable and was creating additional work for teams. So like any organization would does, we created a small team and went off and researched available Agile tools.

We started with this picture on the right and reviewed the The Forrester Wave™: Agile Development Management Tools, Q2 2010 report.

Once we had our initial list of companies we wanted to review, we followed an Analytical Hierarchy Process (AHP) to conduct the decision analysis. We then identified our needs into 5 categorizes.

1. Planning and Tracking
2. Story Definition
3. Development Integration
4. Quality Assurance
5. Infrastructure Operations

Once we completed our AHP, we then brought vendors in to do demos of their tools. Here are our results. Hope this helps.

We can all remember the first time we learned about Scrum and the magical burndown chart that projects if you are on track to delivery during the specified time. In “Scrum in 10 Minutes,” it too talks about the burndown chart.

Today our Agile tool provides us with many burndowns AND burnup reports. We have the iterations (sprint) burndown that tracks if a sprint is on track, we have the iteration (sprint) burnup that tracks if the scope is going to be delivered, we have the Release (PSI) Burnup that tracks if the PSI scope is going to be delivered, we have the Story Burnup that tracks if a story / feature / epics is tracking, we have the Story Burndown that tracks hours burned.

It can be confusing. Some go up and so go down, some are for a sprint and some are for a PSI. I’m a big fan up going down rather then up, but that is just me.

So now I’m ready to introduce a new report that many people have found extremely helpful in our Agile journey. I’ll refer to it as the “Release Burnup Report.” (I wish it would go down, but it doesn’t). The purpose of the Release Burnup Report is to track the status of an actual customer release. It could combine multiple Epics into want report that will predict when it can be delivered. Below is a video explaining the Release Burnup Report.

As always, I am open to suggestions. It’s not perfect but it is available today.

It is official; John Deere Intelligent Solutions Group is practicing Agile!

Since 2008 I have been blogging about how Agile is working, but I was never allowed to say who I worked for. That day has come to an end I have received approval to reference John Deere in my blogs. Not only am I making it official, but we are now published in Dean Leffingwell’s new book Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise Requirements in Chapter 11 – Role of the Product Owner.

In addition to be unleashing how Agile is changing the way John Deere is developing software, we have given Dean permission to blog about his experiences working with John Deere. Stay tuned for that.

If anyone has topics they would like me to add to my blog list, please let me know. You can email me at holdorfchadr [at] johndeere.com