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.

Put the “User” Back in User Acceptance Testing

I think it's about time we really focus on making the lives of the users better in our User Acceptance Testing (UAT).

Here's how I propose to do that, and gain the advantages within an iterative Agile framework.

First off, let's settle on definitions. How exactly is UAT defined, and what is its purpose? Most definitions of UAT on the web offer a variant of "having actual users test the application just prior to delivery, to ensure it meets requirements." Some organizations hand users the detailed requirements to test against. Some provide the users with actual test cases or scripts. To these definitions and methods, I would say, respectfully…hogwash.

In UAT, I am interested in whether or not the product makes the users' lives better. Does it make their jobs easier? Does it accurately reflect and support the way they actually work, and not whether what we captured in requirements reflects the way they work? Testing the product against requirements, or test cases, is the job of the team…not the users. What if the requirements are wrong? Maybe we missed some need, or some use cases. Or what if, even though the requirements reflect what the users asked for, once they get their hands on the product, they realize it's not what they need?

Here is my proposed solution to the issue.

First, my Utopian scenario. In an Agile framework, my ideal scenario for UAT is to have direct access to users during the iteration, to gather their feedback as the feature is actually being developed. Show them a screen; let them spend some time with an isolated module. If we have that luxury, the cost of making changes based on their feedback is far less.

Absent that, here's my process framework for incorporating UAT into an iterative development process. NOTE: this process is tailored for a multi-iteration release cycle:

1. Iteration review/demo: We have finished iteration 1. We have the Product Owner identify and invite interested users (our UAT group) to the demo at the end of the iteration. Let them meet the team, and use the demo of the features developed in that iteration as an introduction to the UAT group of what they will be testing. Gather their initial feedback from the demo and review it with the Product Owner to see if the P.O. wants it in the Product Backlog.
   
2. UAT Cycle Start: Use the product demo as a launching pad for a UAT cycle. The UAT group has seen the features in action, they've been able to ask questions and get an initial impression. Now, during iteration 2, it's time to get their hands on it. Structure this in such a way that:
   1. They are using the product in a way actually reflective of the way they work,
      
   2. It has minimal impact on their busy schedules,
      
   3. They aren't necessarily testing the same areas,
      
   4. You get periodic feedback from them in a group setting.
      
3. UAT standup: While the team is developing in iteration 2, your Agile team lead (or Scrum Master or business analyst), maybe with the Product Owner, is having quick feedback-gathering sessions with the UAT team…maybe 2x/week. Do this as a group, so members can hear each other's observations. Ask questions such as "How does this help make your job easier?" or "What would you change about these features?" Notice these are NOT 'yes' or 'no' questions. Open-ended questions elicit discussion and feedback…and that's what you want here.
   
4. Cycle feedback into the Product Backlog: The Scrum Master or business analyst can now review that feedback with the Product Owner, for possible inclusion in the backlog for a future iteration. Create user stories from the feedback, and have the P.O. prioritize them.
   
5. Bring feedback stories into future sprints: So now, let's say iteration 3 is beginning. And feedback from the UAT held during iteration 2 has made it to the top of the backlog and is brought into iteration 3. At the demo for this iteration, your UAT group will see their feedback brought in as actual working product before the release.
   
6. Lather. Rinse. Repeat.
   

Iterative UAT

What are the benefits we're likely to see from this process?

1. UAT users become invested parties: They are providing valuable feedback, helping shape the product as it's being developed;
   
2. Product better aligned to user needs: By having UAT testers interact with the product according to their actual work patterns, instead of a script, we are more likely to get realistic, usable feedback;
   
3. UAT users become community advocates: Imagine your reaction to this process if you are one of the UAT group. "I saw the product in development, tried it, gave feedback, and they actually listened and made the changes I suggested before they released the product!" These users will become strong SMEs on the product, and advocates for your process within the user community. And THAT is a big win in an Agile adoption.
   

 
I would be very interested to hear your thoughts and observations on UAT in iterative development. So as always, I welcome your comments.

How Really Simple is Simplicity?

Why this Agile principle is not as simple as it seems…and why it is a must


 
"Simplicity, simplicity, simplicity! I say, let your affairs be as two or three, and not a hundred or a thousand; instead of a million count half a dozen…and reduce all other things in proportion."
– Henry David Thoreau

"Simplicity – the art of maximizing the amount of work not done – is essential." This is one of the twelve essential principles behind the agile Manifesto, and I think it is one of the most critical and challenging for people and organizations attempting Agile.


Why stress simplicity?

Just what makes this principle so critical, anyway? I mean, when we say "maximize the amount of work not done", are we advocating laziness? Of course not, but I would say we are advocating efficacy. Increased efficacy – maximizing output for a given input of effort – means we are producing the most value for a customer with our expenditure of effort. And simplifying what we do…our processes, our code, our communication, any use of our time…will maximize the amount of effort we can focus towards producing quality product for the customer above anything else. And that is one of the value propositions of well-practiced Agile…maximum output for a given input. Simplifying software can also make it more flexible to extend and adapt, easier to maintain, and easier to learn for new team members. But simplicity itself can be hard at first.


Natural or unnatural? Science or art?

Our lives are getting more complicated every day. It seems to be a natural tendency for us to allow, or enable that to happen. Think about it…do you find it more of an effort to simplify, or complicate? A quick search on the term "simplify" on Amazon's book list yielded more than 1,300 books on the topic at the time of this writing. Want more proof that we crave help in simplifying? Think of the Staples "Easy" button. One of the more successful ad campaigns in recent memory was so successful, I contend, because it speaks to such a cross-section of our society that struggles with an overly-complex business and personal life. And every generation says that, in their youth, life was simpler (I'm even doing it now, with my own kids). It's actually become "outside the box thinking" to focus on simplifying. In fact it isn't natural, so it isn't easy…it takes focus and effort to simplify. And it is an art, rather than a science, because the answers aren't prescriptive. Ultimately, the answer to maximizing simplicity is between your ears – it's how you think and how you approach situations. You have to actively look for the simple answer, the simple solution. If you don't, when you finally step back and take stock of what you've built – system or process – you may have that "Rube Goldberg moment"…the realization that what you've built is something very complex to accomplish the very simple.

Example (click to enlarge):

Recently, I was watching the Discovery Channel series "One Man Army." It's a reality show where contestants with backgrounds in the military, law enforcement and extreme sports compete in various challenges for the title. In one challenge, they had to breach a series of barriers using only the tools provided. The barriers got progressively more challenging including a cinder block wall they had to breach with a sledge hammer while being sprayed with water. By the time they got to barrier 5, the contestants were adrenaline-charged and bent on destroying anything in their paths. At this point, the host said "what they don't know is that the door on barrier 5 is unlocked, and they only have to try the handle to move on." How often do we assume in our work that the answer to a challenge has to be complex…it couldn't possibly be that simple…could it? Yes, it could.



How to do it

While, as I said, the answers aren't prescriptive, here are a few pointers and concepts to keep in mind as ways to simplify your practices.

• Focus on simplicity…continuously. The importance of diligence can't be overstated. As I noted previously, our natural tendency is to make things more complex. Things will consistently drift in this direction – you'll see it if you watch for it – so keeping this a continual daily focus is important.
  
• Challenge your assumptions. Don't assume complexity is a forgone conclusion. Established processes, legacy code, tools and procedures…all are likely to remain static and unchanging unless questioned. One note of caution: I'm not telling you to go raise Cain across your organization and change the world overnight. Start with even your own practices and see if there are opportunities to simplify. You might find you end up leading others towards this way of thinking by your example.
  
• Framework, not process. Agile frameworks like Scrum are indeed simple in structure…even deceptively so. Resist the temptation to extend and augment them with more process. Again, some people will tend to add on additional processes to their Agile practices over time, assuming something so simple in structure can't be effective. Don't be one of those people.
  
• User stories. User stories are so powerful in capturing users' needs precisely because they are so straightforward and focus on what the user wants to accomplish, not what "the system should do" or the technical implementation should be. Use them as they were initially intended…as a starting point for a conversation between customer and implementation team. Try them, trust them, and practice face-to-face communication for requirements, and you will be amazed at the rapid rate of sound understanding that develops.
  
• "POW" modeling. I won't name them, but there are one or two modeling software programs out there I just can't stand to work with. They are complex, awkward, and by the time you've built the model being discussed in a meeting, creativity, flow, and some aspects of the design may be gone. Instead, I like to use Scott Ambler's "POW" modeling…the Plain Old Whiteboard. Quick, simple, dynamic…and just pull out a smart phone, snap a picture and email it to the team and/or stakeholders and *poof* you have model documentation.
  
• Manual task boards. My experience is that this is consistently the first Agile practice that nay-sayers change to something more complex. "Seriously…we build software. We can come up with something slicker than post-its, can't we?" "This looks like a children's classroom…can't we clean it up a little and use something electronic?" Now, I like electronic ALM tools, and there are several terrific ones out there. They will do a great many valuable things for you and make many aspects of your Agile life easier. But replace the good old post-it task board? Sorry…no. The effectiveness of a manual task board is in itself worthy of a separate post, but for now, trust me. I have lived it personally. Buy stock in your favorite office supply store or sticky note manufacturer. Then, go buy a ton of them and use them, and promote their use with others.
  

These are just a few tips on practicing simplicity. I would love to hear and share yours, and your views on the subject, as well. So as always, I welcome your comments and questions.


Editor's note: In my Agile meetup group, we're exploring the twelve Agile principles, one per month, over the course of 2012. If you are in town, please join us.