24 Hours of Pure Agile

 

A few weeks back, my company conducted an experiment. It was intended to be a motivating, fun, team-building exercise fostering creativity and innovation. And it was that…but it ended up being much more.

 
The Concept

It was our "FedEx" day ("when it absolutely, positively, has to be [done] overnight"). The framework was simple:

• Post up project ideas. It could be anything (product, service, an internal process, a marketing piece). The main requirement was that it had to be intended to benefit the organization in some way.
• Review the list, and sign up for whatever idea interests you.
• Each team should produce something in 24 hours.
• Everyone participates.

That was it. Beyond that, there were no rules. No formal processes, no defined roles, no checkpoints, no required documentation or technologies. Simply starting Thursday afternoon and ending Friday afternoon. From my perspective as the Agile specialist, I was keenly interested in it as a laboratory experiment on the Possible, but I told no one.
Teams formed and sectioned off naturally into their own spaces. Team sizes ranged from ten or twelve down to just two. Everyone was involved, from our firm founder to the newest employee. I joined a team intent on making a video highlighting what it was like to work at our firm. White boards were engaged, post-its began appearing (though not for every team, because they were self-norming) and the work commenced. People enjoyed themselves…the atmosphere was light…but work WAS progressing, you could see that.
When we first discussed the concept, I was asking whether people were staying overnight. I have a long commute, and was ready to stick around to work all night. I mean, it was a 24 hour project, right? Maybe ancient recollections of my time in college were creeping back in, and subconsciously, I thought that would be "fun." But nobody else was planning on doing that, so the staff went home for the evening at later, but reasonable, hours.

 
The Process

What was it like working on the teams? I can tell you from my own experience. We were producing the video, so our backlog looked something like this:

• Develop video concept
• Script video
• Select people for speaking parts
• Enable technology assets (camera, microphones, video editing software, etc.)
• Shoot video
• Edit video

Our team consisted of four people from various departments in the company: myself from project delivery, along with one of our recruiters (Robin), our Operations Manager (Peggy), and one of our software developers (Mani). Most of those skills had no direct bearing on this kind of project, but that didn't matter. We all just pitched in and picked up whatever needed to be done, whatever we were most equipped to help with in terms of talent, experience, resources, or personal contacts. We needed a camera and mics: Robin's contact had professional cameras. Microphones were tough, so we shot with the camera's mic. Peggy came up with a great concept and we ran with it. Mani has a penchant for technology, so he became our cameraman/video editor. Since we have a lot of public material about what we do as a firm, we wanted to show more who we were as a group of people. To do that, we enlisted employees from other teams for the speaking parts (our thanks to their generous cooperation. And in 24 hours, we had completed, shot, and edited a 2-3 minute video, reaching our goal. Did we finish at 23 hours, 50-some minutes? Yes, but this was a 24 hour project, after all.

 
The Results

As the teams demo'ed their completed work to a panel of judges, I was pleasantly shocked. Team after team turned out really great product. And it was varied product. Features were working, plans and processes were well thought-out and documented, etc. While some of the ideas are proprietary and will be developed into product or service offerings, I can tell you the projects were as varied as:

• New technology products
• New technology service offerings
• Fresh new employee onboarding processes
• New comprehensive technology development standards
• A comprehensive employee outing plan & process
• Our promotional video

From an Agile laboratory concept, I couldn't be more pleased. How did these people accomplish these goals, and do it so well?

• They formed self-organized teams. And not just self-organized once they got on a team, but even WHICH team they wanted to join.
• They worked without formal requirements that had to be fleshed out before they could do anything.
• They prioritized their own work without executive direction, knowing they only had so much time to complete something.
• They FOUND the skills on their own teams to fill needs they discovered.
• Each team developed their own best way to work, but with the same basic framework idea.
• They improvised, adapted, and overcame impediments (certainly on my team I saw that).
• They did it WITHOUT OVERWORKING. Nobody I know of came close to pulling an all-nighter, no sleepless heroics.
• They came and CO-presented demos of WORKING PRODUCT. And it was high quality.
• They all had fun. No fights or 23rd hour death marches.
• And the process WORKED, NOT ONLY for software.

 
The Challenge

So you might be thinking: "yeah, that's great, for a quick overnight fun exercise. But we run a business at my place, and that can't work in the real world." Oh really? I challenge that. Better yet, how close is your current development process, your current project hierarchy, your current organizational culture, and your current results, to what I outline here? Can you get closer to this than you are now? And can you gain these real benefits today, in terms of productivity, organizational culture, and team morale?
If you never try, how will you ever know?


As always, I welcome your comments.