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.

Team Reward Systems in Agile

This post has moved HERE.

Thanks,

Dave

Story points: Who gets the Credit?

How getting caught up in the accounting can make us miss the point

My cell phone rang and it was my Agile coaching compadre on the other end of the line, exasperated. Uh oh, time for an Agile intervention.

He had a team that took on 10 points of user stories in a sprint, but only finished 3 points. Now they were planning for the second sprint, and they were starting in a hole with work to complete on the 7 unfinished story points, plus another 10 points of work they were taking. They were trying to keep their average velocity at 10 points per sprint. I asked him what they were going to do about the credit for the 7 story points that spanned the sprints?

"They're going to get credit for them in sprint 2, since that's when they completed the work." Well, he couldn't give them credit for the points in sprint 1, since they weren't completed. That was the right answer there. I asked how much of the work was left over for the stories. "About 10% left, all testing" was his answer. Hmmm…OK. Something was bothering me about that. The majority of the work on these points was done in sprint 1, but they weren't completed in sprint 1, so the credit couldn't go there. But to get full credit for 7 story points in sprint 2, when only 10% of the work had to be completed, wasn't striking me as kosher either. What about partial credit in each sprint…90% credit (6.3 points) in sprint 1, and 10% credit (0.7 points) in sprint 2? Well that seemed like ridiculous mathematical gymnastics, and besides, it would send the wrong message to the team: that it's OK to NOT finish work in a sprint. 

This team was indeed in a box. They had already completed most of the work (and wound new code deep into the existing code base) for those 7 story points. They started all of them in motion at the same time in sprint 1, too, (the Scrum Master should have advised against this) which had limited their flexibility to move some back to the product backlog. So now, it had to be completed.

We continued debating the issue and trying to decide where the points should go. They had to go somewhere, didn't they? And then it hit me.

Those 7 points go nowhere. 

No credit. But they DO have to complete the work. "Well, that's an answer that everyone will hate" was his response. They probably will, but its tough love for the Agile team. And here is why I think it's the right thing to do.

What are we measuring with story points and level of effort? First off, it's NOT "time tracking." It's not meant to be a measure of how the team spent their time. What we are measuring is business value delivered. Stories are worth nothing to the business if they are not completed. We want teams to start a sprint entering into a commitment with the Product Owner that they are taking on work, and will finish it in the sprint. Of course, there are times during a sprint when work takes longer than expected and teams can't finish everything they committed to, but that's when the Scrum Master facilitates communication with the Product Owner to move the lowest priority not started items back to the product backlog, ensuring that whatever stays in the sprint can get to "done." I covered this in a previous blog post.

You honor the commitment, but story point credit and velocity has predictive value in measuring how much work the team starts and completes. Since this was not the case with this work, no credit is given. Would everyone (team, Scrum Master, Product Owner) hate this solution? Sure, but it makes for a great retrospective topic, and a lesson learned for the future.

So how do you, as a Scrum Master or Agile team lead, avoid having this happen in your teams? Here are a couple of tips:

• Use solid velocity measurements in sound planning: Scrum Masters should use velocity as a rolling average, not a single number, and in concert with good capacity planning (vacations, holidays, other commitments, other drag factors) help keep the team from "biting off more than they can chew" in their commitment in sprint planning. This is precisely why I feel you don't get credit for partially completed stories at all…it provides no predictive value.
  
• Minimize WIP: The fewer number of stories a team has in flight at any one time, the greater their flexibility to adjust and move not started stories around without having wasted effort and having to unwind code from the codebase.
  
• Inspect and adapt daily: No matter what, keep the daily standup sacrosanct and effective. It remains the team and Scrum Master's primary channel for surfacing and mitigating potential problems before they become real issues.
  
• Practice "tough love" servant leadership: Remember, a Scrum Master is not a manager of the team, they are the coach and protector of the process framework. The coach does not take the field; he/she observes, advises, supports, and puts the team in a position to succeed. And by practicing tough love like in the example here, a Scrum Master helps the team, and him/her self, learn a valuable lesson from a mistake they are unlikely to repeat in the future.
  

As always, I welcome your comments.






 

Effort Estimation is Child’s Play

Our schools are teaching Agile techniques to 2^nd graders.

My 2^nd grader asked my wife for help with his math homework. As soon as she heard the word "math," she said "go ask your father." He brought it over to me. They are learning about weights and measures and how to use scales. He showed me his homework and said "dad, I don't get it. What is this?" I looked at it and smiled. "Well," I said, "that's what dad teaches grown-ups to do every day at work. You're learning about effort estimation."

Here is his actual homework sheet:

Each example gives you choices of absolute measurements (pounds), BUT you don't have the tool to weigh each object. Instead, you're relying on past experience and knowledge to estimate the weight. Have you ever held a baby? Probably, and even if not, you know they are a lot closer to 8 pounds than 20 or 70 pounds. And while you've certainly never weighed an elephant, you know from your visits to zoos and circuses that they are huge, and your experience with objects that weigh 100 pounds or 500 pounds tell you that an elephant is certainly much more than that, so given the choices, 11,000 pounds is easily the right answer.

This is essentially what we do with effort estimation in Agile product development. We are asking team members to measure how much work is required to complete the product feature, not how long the work will take. And the measurements are not on an absolute scale, they are on a relative scale, meaning "how much work is this item, relative to the amount of work the simplest item you can think of is?" When we start using effort estimation (BTW, a.k.a "story points" or "effort points") we have teams baseline on a common simple activity in their domain, and use that as the base measure. After they agree on what that is, all other features are measured relative to that baseline.

Many, if not most, Agile teams use a numerical scale called the Fibonacci scale to measure effort. The Fibonacci scale is named after Leonardo of Pisa, who was known as "Fibonacci" (son of Bonaccio). He introduced the concept to the West in the early 11^th Century. These are the typical Fibonacci numbers used for effort estimation:

1, 2, 3, 5, 8, 13, 21, 40, 100

Without getting into a doctoral dissertation in mathematics, let's just say it gives you a scale with steps that increase in magnitude as you go up, so when you have to decide between two of the larger numbers, it's not so fine grained. Seeing it graphically really helps. Here is a "Fibonacci spiral" which you get by making boxes with areas the same as the Fibonacci numbers, and drawing circle arcs corner to corner, and connecting them:

And where else have you seen that shape in nature?

The increase in step values forces you to choose the closer "bucket" rather than argue over minutiae. And that's why it works so well in effort estimation…it forces you to "pick one!" and not get bogged down in the details, which is the point of effort estimation…the right amount of detail at the right time. We use it early on in the process, before you can know all the detail you would need to know to get down to estimates in hours.

Pick Your Measure

Here's one of the great things about effort estimation in Agile…you don't have to use Fibonacci. It's hard enough, when we're used to a professional lifetime of giving estimates in hours or days, to mentally switch to measuring effort. If your team is having a hard time with Fibonacci, and divorcing a numeric measure from absolute time measurements, don't use it. It's only important that your chosen measure has relative sizing that the whole team can relate to; it doesn't have to be numeric.

Teams have used T-shirt sizing for effort estimation (Small, Medium, Large, eXtra Large). I'm coaching a team right now that uses sea life: guppy, salmon, dolphin, shark, whale, Kraken. ("Release the Kraken, Jim!"…props to you). I even heard of a team that measured stories in "Frito bags." Why? They baselined a 1-Frito bag story on the amount of work it would take this one developer (who ate Fritos all day, every day) to complete while eating one bag of Fritos. You really can use any scaling method like that.

But in the end, remember to focus on simplicity. Effort estimation doesn't have to be difficult, They are teaching the concept to 2^nd graders.

As always, I welcome your comments.

Agile – It’s Not Just for Software Development Anymore

2011 marks the 10 year anniversary of the Agile Manifesto, and it's a good time to examine where the movement is headed. In February, 2011, there was a gathering at the Snowbird Ski Resort in Utah, sight of the original Manifesto creation, to do just that. While I understand that there were some views at that event that Agile is really just about software development, there were thankfully other voices that endorsed Agile as values and principles applicable in general terms, and not just in the area of software.

My view? The Agile Genie is out of the bottle.

Agile is not a methodology, it is a way of thinking and being. The values of the Manifesto articulate where to focus attention and effort to make sure we create product that provides maximum business value the quickest. Agile's simple, but elegant, tenets are inspiring the Agilists among us (of which I am one) to look for new ways to apply them and engineer new solutions in areas, I suspect, were not even on the radar in Snowbird in 2001.

Scrum is by far the most popular Agile methodology in use today, and is technology agnostic. It is a lightweight Agile project management framework that focuses on building a releasable increment of product (not just software) frequently. Working in short increments, an empowered, creative, cross-functional team collaborates with a business owner, and each other, to ensure they are producing quality product while constantly adapting to the changing world around them. Why does it work? Agile embraces a simple concept that we all accept as fact in our lives: "The Only Constant is Change." The Greek philosopher Heraclitus said that about 100 years before Plato was in his prime. I use that quote in each presentation I do on Agile, and every time, every head in the room nods. However, for a notion that is so universally accepted as a truth, we traditionally practice project management techniques that try to predict, measure, and engineer that constant out of our reality, and ultimately often fail in the attempt. To me, it only makes sense to practice management techniques that not only accept change, but capitalize and thrive on it.

The notion of using Scrum outside of software development isn't new; Scrum co-founder Jeff Sutherland and his wife described how she used Scrum to run her church. There are success stories of marketing companies utilizing Scrum to deliver marketing initiatives, indeed to address "marketing crises." People have even used Scrum for wedding planning. At my firm, we use Scrum practices and Agile principles to run not only our development projects, but internal operations and our own marketing efforts as well. And in the interest of full disclosure, the favorite anecdote about me around the office right now is that I used Scrum to help my family prep to host company for Christmas this year. Yes, it's true.

The Agile Genie is out of the bottle. Like a platoon graduating from basic training, we have learned what our instructors had to teach, incorporated the values, and are now taking it to the next level and growing beyond their control. And this is a good thing. The Agile "revolution" is kicking into high gear, crossing boundaries to new horizons, and people are beginning to jump on board.

So why not you? Why not now? Come check out what Agile can do for you.

As always, I welcome your comments.

Planting the Flag – The Power of Vision

If I asked a random member of your organization to state the goals of the organization for this year, could he or she do it? Could they name even one goal? What if I asked "how does what you're doing today advance a strategic goal of the company?" If their answer is "I don't know" or, even worse, "I don't care," we have a problem. Not a problem that will keep you from being good, but one that can prevent your organization from being truly great. What is lacking is a Vision.

Architecture of a Vision

So what do I mean by a Vision, and why does it matter? I'm not talking about a mission statement, I'm talking about a goal…but it's more than that. To be effective, a Vision should have the following characteristics:

SIMPLE

"Any fool can make things bigger, more complex... It takes a touch of genius-and a lot of courage-to move in the opposite direction."  - Albert Einstein

"Simplicity is the ultimate sophistication." - Leonardo da Vinci

A great Vision statement should be clear and simple. You shouldn't have to be an industry insider, or a senior executive, to decipher it. So we don't want a statement such as "Develop, deploy, and manage a diverse set of scalable and strategic knowledge management tools to serve our customers, improving the possibility of overall satisfaction among our diverse customer profiles." There's a lot wrong with that one, not the least of which is it's not simple. How many tools do we need to deploy to be successful? What does it mean to "improve the possibility of overall satisfaction"? Is it enough that it's possible that our "customer profiles" will be more satisfied, even if they're not actually more satisfied? As an employee, would you be able to tell when you had achieved the goal?

MEASURABLE

"The focus of subjectivity is a distorting mirror." - Hans-Georg Gadamer

Effective Vision statements describe a goal that can be measured. We can tell objectively whether or not it has been achieved. They should also have a deadline or target date. Open-ended, nebulous statements with, at best, subjective success criteria make it impossible to tell whether or not the organization has achieved the vision. Here's a good example of an immeasurable vision statement: "To experience the joy of advancing and applying technology for the benefit of the public." Simple, yes…but measurable? How would you measure the "joy" of a company? And the goal is to "experience the joy"…so if we experience it, and don't sell much product, have we achieved the goal?

INSPIRATIONAL

"Make no little plans. They have no magic to stir men's blood..." - Daniel Burnham

"If you have built castles in the air, your work need not be lost; that is where they should be. Now put the foundations under them." - Henry David Thoreau

Bold, inspirational Visions move people and organizations to push the envelope. Some of the very best ones set goals that may even seem somewhat impossible at the time they are presented. In 1987, Apple produced this video illustrating their vision of what computing in 2010 could be. It is a concept called the "Knowledge Navigator," a tablet-type device presenting amazing power for the user to interact with the device through speech recognition, research data from multiple sources through an integrated multimedia search engine, simultaneously accept and make voice and video calls, manage appointment calendars, etc.. To put this vision in perspective, 1987 brought us the following advances in computing: Windows 2.0, the introduction of Microsoft Works, and the creation of VGA. To say the Knowledge Navigator seemed "somewhat impossible" in 1987 is probably an understatement, but what do we have in 2010? We have high speed wireless internet, cloud computing, and the iPad.

The Connection in Agile

So how do we tap into the power of a Vision in Agile practices? Once we have a leader who establishes the simple, measurable, inspirational Vision, try creating a "Vision Backlog"…analogous to a Product Backlog, a Vision Backlog can be created and revisited quarterly or annual basis by senior management, and contain the same elements as a product backlog item: the clear statement of the goal, acceptance criteria so everyone knows how to tell when that goal is met, and effort sizing to measure how much effort each item will take to complete, relative to the others. A Vision Backlog could have even just two or three items in it. Then, we can tie product backlog items to vision backlog items, assuring the product features we build serve a strategic vision of the organization. Break those product backlog items down into tasks and hours for a sprint, and you have a chain of evidence from the task to product backlog item to vision backlog item of how much work, and time, it takes to realize that vision.

The Perfect Vision

I have given a few examples of Vision statements that are sub-par. So has there been a "perfect" vision statement? On this 50^th anniversary month of John F. Kennedy's inauguration, I would say he takes the award for the most perfect Vision statement in at least the last 100 years:

"I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." – John F. Kennedy, May 25^th, 1961

The statement is simple. Everyone in the world could understand what it meant.
The statement is measurable. It's very clear that if we landed one man on the moon, and returned him safely to Earth, before January 1, 1970, that the goal would be met.
The statement is inspirational. It's hard to imagine a more impossible, incredible goal than flying a human safely to another heavenly body for the first time in history.

Yet ordinary people followed that vision, that "castle" that JFK built in the air. They put the foundation under it, planted the flag on lunar soil, and achieved the goal.

Bravo, Mr. President. Bravo.

A Manifesto on Problem Solving

I have a natural tendency to be a helper, a problem solver. It drives my wife crazy when I try to solve her problems and she "only wants me to listen." I've long considered the question "what are my essential elements to effective problem solving?" What follows is my distilled "Manifesto on Problem Solving." I strove to keep it simple, straightforward, focused, and easy to remember.

1. DON'T SOLVE PROBLEMS THAT DON'T EXIST
   
2. SOLVE THE PROBLEM, NOT THE SYMPTOM
   
3. CONTINUALLY TRIAGE
   
4. SEEK THE SIMPLEST SOLUTION
   
5. MAINTAIN THE VISION
   
6. START EVERY SOLUTION WITH THE INDIVIDUAL: YOU
   
   

To explain in detail:

1. DON'T SOLVE PROBLEMS THAT DON'T EXIST
   It sounds obvious, but it can be easy to forget and can be a temptation for those of us that enjoy developing "cool" solutions. Before I delve into lengthy and possibly expensive solutioning (in time and money), I want to make sure the problem I'm trying to solve really IS a problem. Especially if you're in the business of developing solutions, this is critically important, even to the point of being an ethical imperative where spending your client's money is concerned.
   
2. SOLVE THE PROBLEM, NOT THE SYMPTOM
   Make sure you're finding the real problem, not just what initially is presented as the issue. This can take a bit of critical thinking and investigating, but can be done rapidly in conversation. I see a breakdown in this area often in organizations, especially when the root cause may be difficult to confront, e.g., an organizational culture issue rather than a process issue. One of my favorite models for this root cause analysis is the "Five Whys" of Sakichi Toyoda. Keep asking "why" each symptom happened until you reach the root cause.
   
3. CONTINUALLY TRIAGE
   Always ensure you're solving the most critical issue now. The triage concept originated with French Army field medics in World War 1, and has undergone many evolutions since then, but the original elements are the same and can be applied metaphorically to any problem situation. A more modern version for use in catastrophes categorizes patients (in order of triage importance) as:
   1) those most in need of immediate care,
   2) those whose required treatment can be delayed,
   3) those likely to live, regardless of treatment, and
   4) those likely to die, regardless of treatment.
   Translated to business problems, this can be done by quickly bucketing problems into: "Now", "Next", and "Someday." Continually triaging, and prioritizing within each bucket, is the key.
   
4. SEEK THE SIMPLEST SOLUTION
   My best friend is a sage in this area. I went to him one time in college because my elbow was hurting when I moved in a certain way. I said "it hurts when I do this." His response: "Well then don't do that." SIMPLE. Humans naturally add detail to anything. We find simplification far more difficult than elaboration. The simplest solution to a problem is often the easiest to implement, and will keep you focused on solving the problem rather than finessing the solution.
   
5. MAINTAIN THE VISION
   Never lose sight of the goal, the vision of what you, your system, or your organization is trying to accomplish. Post it somewhere visible. Begin solutioning every time with the question "does fixing this problem serve our goal(s)?" If not, put it in the "someday" bucket.
   
6. START EVERY SOLUTION WITH THE INDIVIDUAL: YOU
   When you follow this tenet, problems will be solutioned at the most basic level possible and have the best chance of remaining targeted and simple. Think about your home life: if you have a clogged drain, are you going to call the federal government for help? Of course not, that would be ridiculous. You're going to go to the store and buy drain cleaner, because you understand that's all you need. (Although if you did ask the government for help, you might see a costly commission convened to study the curve of drain piping and its effect on debris-filled water flow contributing to clogging. Maybe new regulations for plumbing would be enacted.) If you don't have the means to solve the problem, then and only then escalate it to your boss, or your municipality. Performing the same means check at each successive level will ensure that the only problems that bubble to the top of the hierarchy (like national defense to the federal government) will be those that truly must reach that level to be solved.
   

What tenets for effective problem solving do you ascribe to? Do you have something to add to the list? As always, I welcome your comments.

Are Your Teams “Wired for Agile?”

Agile "out of the box" looks easy. Heck, it is easy. Take Scrum: a light framework (three meetings, three roles, three artifacts) within which teams self-norm. Form a team, plug 'em in and let 'em go…success! And the business side of the house and organizational leadership just kick back and reap the benefits, right?


Wellll…no. This approach belies the social and, frankly, psychological complexity in making the move to highly functioning Agile teams and Agile organizations. If you've tried the simplistic tools/processes-based approach, you've most likely struggled or enjoyed, at best, limited benefits of Agile (the "qualified success"), whether you or your organization is aware of it or not.


When I conduct trainings or speak to groups about Agile and Scrum, I'm often asked questions like "if I have a good traditional project manager, will he/she make a good Scrum Master?" or "what kind of personality is 'right' for Agile?" These are insightful questions to ask, because the reality is Agile is not right for every personality, and not every good traditional project manager will make a good Scrum Master. For that matter, I think the reverse is often true: a team member floundering in a traditional project structure or an underperforming traditional PM may thrive in Agile. The key is digging past the nuts and bolts of Agile – the roles, meetings, artifacts, tools, and processes – into the values and beliefs shared by highly functioning Agile teams and organizations. Then, you have to decide whether your team members and organizations have, or even want, to embrace those values and beliefs. In this multi-part series, I'll be doing that deeper digging, and looking at what it really means for teams, Product Owners, Scrum Masters, and ultimately organizations to be "wired for Agile." In this first installment, let's look at the team level.


At its core, this is about the values and beliefs of team members. Your values and beliefs define how you interact with the world around you. They drive your assessment of which activities you find helpful in your workday, which you identify as impediments, and ultimately why I can present the same process to two different people, each will rate its value very differently, and they'll both be right…because it's subjective. Life coach Tony Robbins, in his series "Personal Power," talks about values and beliefs as being the drivers of your behavior. He teaches that your values define what's important to you: success, love, freedom, simplicity, transparency, etc. Your beliefs, then, are tests of whether those values are being met. Ask someone to state something they value, and then ask them "how do you know you have <the value>?", and they'll tell you the underlying belief. This is how two people can have the same values, but wildly different beliefs of what it means for those values to be met.


Take the value of Success as an example. Tony uses this example in his series. He had two attendees at a conference that both stated they value Success. When asked if they were successful, the first attendee, a corporate executive, surprisingly said "No." His definition of a success was a litany of criteria: you had to make $1 million/yr (he was something like $50k below that), you had to always be positive and never be down or depressed. The list went on and on. Tony asked the other attendee if he felt successful and the man replied with an enthusiastic "Yes!" How could he tell he was successful? Easy: he said "well, I feel that every day I'm above ground is a successful day. So I wake up, look around, and if I'm above ground, I'm successful." We see two very different belief systems feeding a shared value.


So how do we apply this to building a team "wired for Agile?" It takes more than just a cursory glance at the Agile Manifesto, but that is a good place to start. Even though the Manifesto says "…we have come to value…" what follows (Individuals & interactions, working software, customer collaboration, responding to change) is a mixture of what I term as "Ends" values (goals) and "Means" values (methods). They're not all exclusive to Agile teams, either. Waterfall PMs value the "Ends" value of working software too, for instance. But a "Means" value of customer collaboration – interaction – over comprehensive documentation won't likely be shared by lovers of documentation, as I noted in a previous blog. We have to sift through the Manifesto and then do some further digging for "Means" values that highly performing Agile teams should embrace, and what beliefs would need to be present for people to be happy working on those teams.
Here are just some of the values you should look for in choosing people for an Agile team:

1. Collaboration: Effective Agile team members don't work in their own silos. They talk to each other, and the Product Owner, frequently. A former instructor of mine described programmers as "sitting alone in a dark room, growing mushrooms all day." Potential team members that prefer to spend 8 hours a day, every day, alone on their own tasks may not be the best choices for an Agile team. Ideally, you're going to colocate these team members. So look instead for people who value collaboration, and favor face-to-face communication over channels like email, instant message, or phone.
2. Adaptation: Some people get very uncomfortable with change. These are people happy with predictability in their daily work. The antithesis of this might be the person who gets bored being on a maintenance project. Look for people who value adaptation, and express a belief that goes something like "I'm adaptive if I'm able to – and maybe enjoy – shifting direction quickly in response to changing conditions." If they get bored with routine, that's also a good indicator that they're right for an Agile team.
3. Autonomy: This is a concept from the Self Determination Theory in psychology that addresses our "…universal urge to be a causal agent of our own life." In other words, "having the freedom to make your own choices." This is an important characteristic of Agile team members because we want to set the goals for them (the prioritized Product Backlog), and give them the autonomy to decide the best way to achieve those goals. But the team must still be on the hook to deliver business value, so with autonomy must come a sense of responsibility. "I like to be left alone" is not enough to tell us if a person has the right beliefs related to autonomy. Someone who says "just tell me what you want me to build and I'll build it" seems to value autonomy, but likely doesn't believe that responsibility goes with it. Keep that way of thinking off your Agile team.
4. Transparency: On a properly functioning Agile team, there's nowhere to hide. We hold daily standups where team members talk about what they did since yesterday and what they will do before tomorrow. Teams share work in progress with the Product Owner, at whatever stage it's in. We post our progress, or lack thereof, in clear view for any passerby to see. This can be difficult, and is not for everyone. It's about daily accountability. Look for someone that favors true, honest transparency and defines it in terms of sharing daily successes and failures throughout the process. (NOTE: you have to commit to making it safe for them to share the failures). If someone tells you that the hardest thing about Agile is having to say what they are doing on a daily basis and how long it will take, they are unlikely to be happy on an Agile team.
   
5. Teamwork: It's an overused term, but important in Agile. There's no such notion among Agile team members as "you failed your sprint, but I succeeded in mine." Here, you want to look for people that define teamwork as "doing whatever I need to do to help the team succeed." You want to seek, for instance, a developer who wants to help the testers test if they're behind and the developer is available. Avoid the "it's not my job" people here. In addition, look for people who like to be sociable with each other to at least some degree. These folks will spend a good amount of time interacting. If they enjoy each other's company, it will make that interaction much easier and more likely to happen.
   
6. Efficacy: This can be a tricky one, but let me explain what I mean. In the field of electrical lighting, efficacy is defined as "the amount of energy service or useful energy delivered per unit of energy input." In Agile, we place high value on reducing waste and spending as large a percentage of your time as possible adding value to the product. So look for someone who has an aversion to "Process at the expense of Product." This might be someone that dislikes going to a lot of meetings in which they just sit and listen, or dislikes heavy overhead processes that take them away from developing for a significant amount of time. Avoid people that tend to call these type of meetings, even in spite of the effectiveness of the outcome. They may be overly favoring process.
   
7. Simplicity: To maximize efficacy, it is wise to seek the simplest solution to a problem. People who fit this value should be easy to spot in design meetings. They'll be the ones likely, as I say, "clouding the issue with logic." Again, this can be a fine line to evaluate in someone, but people who like to spend an exceptional amount of time in elaborate design before beginning development may end up feeling pressured on an Agile team that values simple approaches and learning as they go. The adaptive approach is also known loosely as the "ready, fire, aim" approach. Tom Steele has a nice blog explaining this phrase over at the Scrum Alliance.
   

As I said, these are just some of the values you could look for to build a successful Agile team. I would very much like to hear yours. I welcome your comments.

Managing Stakeholder Expectations in Agile

When starting any new significant change in your life, its easy (and natural) to have high expectations. Whether it's starting a workout program, a new job or even a marriage, human beings tend to get caught up in the euphoria of the newness and all that the change can seemingly promise. Unrealistic expectations of (somewhat) effortless success can pervade and sometimes sabotage the effort. Transitioning from traditional Waterfall-based methodologies to Agile is no different. The promise of the "silver bullet" of Agile and common misconceptions about what Agile even is (or isn't), if allowed to persist, will make the move far more difficult than it needs to be. Let's look at some of the challenges related to stakeholder expectations in Agile and how to address them. 


Battling Misconceptions
There are some common misconceptions out there about what Agile is or is not, and you need to address these before they manifest on your adoption. Here are a few of the biggest ones:

1. "Agile=Rapid Development" – I'm not exactly sure where this notion started, but it is even perpetuated by some Agilists in the community. This, in my opinion, is potentially the most dangerous misconception that stakeholders could have. It's the notion that because you're "doing Agile," you'll just get done faster. I argue that while this will likely end up happening in the long run, I wouldn't characterize it as "rapid development." "More efficient development" is the term I would use. Agile should end up giving the development team more value-added time by stripping away unnecessary processes and lost time from miscommunication that comes from relying on the written word. It should also give the business quicker ROI by delivering release-ready product sooner in the business cycle. But stakeholders shouldn't expect that all else can stay the same, the development team starts "doing Agile," and code will just be cranked out sooner. 
2. 
   
   "Agile=No more Documentation" – Looking at the Agile Manifesto, and the valuing of "Working Software over comprehensive documentation," stakeholders will often expect this will mean they will get NO documentation. This should not be the case. As I tell my teams, "I want you to do as much documentation as is absolutely necessary." And how/when/if you should create the document depends on the type of document it is. To look at this a little more closely, I'll divide documentation into three subgroups:
   1. Compliance – Documents required by governing bodies external to the team, be they industry regulatory governance or even internal project management office requirements. Either way, those types of documents are necessary to release the product, even if they are not part of building the product. Creating these documents should be tasked out on the Sprint backlog, even if those tasks are all taken by a B.A. or technical writer. These tasks will likely be ongoing during a sprint so as to avoid a mad rush to document at the end.
      
   2. Users – User guides, help documentation, etc. These types of documents also are not directly related to building the product, but necessary for release. The key to developing these documents is to generate them as late as possible in the process, so as to capture the end state of the product, rather than expending effort throughout the development cycle to continually try to capture the change. Since they aren't published until release time, all that time spent changing them is waste.
      
   3. 
      
      Team – These documents are used by the team to document the development of the product and the technical aspects of the design. These will likely include logical and physical database models, class diagrams, design guidelines…anything you can picture would be used by designers and coders to understand how the product was/is designed and functioning under the surface. There are two keys to these documents:
      1. Have the conversation first, then document – We shouldn't assume we need all the documents we're used to generating. Teams should first talk about an issue, or approach. If they arrive at an agreement and no documentation is needed, then don't produce it. If they decide they need documentation at that point, then they've proven its validity and should task it out.
         
      2. Generate the documents, don't author them – Especially when we're talking system and database documentation, there are plenty of tools out there that can reverse engineer code or databases and document the end state. Spend your time collaborating and designing, then use one of these tools one the design is stable and let it do the work for you to optimize your time.
         

Radiating Information
Another key way to manage expectations is to give stakeholders the transparency that Agile promises. Use "information radiators" to do this. Beyond the typical burndown chart used primarily by the team to track progress towards sprint completion, consider using a burnup chart, showing the additional metric of scope change. In this way, stakeholders can clearly see the effect that adding or removing scope will have on the team's progress towards reaching their goal.

Burnup Chart



Consider also adding the information radiators of a release burndown and velocity charts. A release burndown will simply show the amount of work remaining from the product backlog after each sprint. Used in conjunction with a velocity measurement chart of the amount of work the team completes in each sprint, simple math will give you and stakeholders the best case, worst case, and probable average for how long it will take the team to complete the work for the release.

Velocity Chart

No "Silver Bullet"

You must coach stakeholders that Agile is not a "silver bullet" that will solve all the organizational development challenges overnight. Transitioning to Agile will actually surface organizational impediments, likely starting with the most significant and painful. What the organization decides to do about the impediments is the question. As Ken Schwaber says "Bringing Agile into your organization is like inviting your mother-in-law to come live with you. She won't solve all your problems, but she will sure point them out to you." Stakeholders should expect that following the initial euphoria that often accompanies new efforts, there will likely be a time when those involved find it very difficult, and it will seem easier to go back to the old ways. It's at this time that their commitment and support will be most vital to the team, to help them push through the "valley of despair."

Expect to Communicate

Finally, stakeholders should expect to be engaged throughout the process. Collaboration is critically important to successfully adopting Agile. If stakeholders expect to be disengaged, development will be far less likely to match the needs of the business. Ultimately, Dialogue + Transparency + Collaboration = Trust…and trust between stakeholders and the team will breed the most success.

Working without a Net: Making the Move from Traditional Requirements to User Stories

Walking across a tightrope 30 feet in the air would frighten most of us, but having a safety net might make you feel safe enough to try it. The reality is you can get hurt pretty badly in a fall even with a net, so the feeling of safety is more perception than reality.

For teams happy with the perceived security provided by highly detailed, prescriptive requirements, moving to user stories will probably feel like removing that safety net…more detail is seen as more security. But when practicing Agile, making that move is essential to shortening your timelines to release, eliminating waste in your development processes, and having more assurance that what is actually developed will more closely align with business needs and wants.

What's Your Story?
So why do Agile practitioners favor user stories? A user story is a starting point for a conversation between a Product Owner and the Development Team. It's a vehicle to express the business needs to the Team, in language that a user of the application should understand. A classic user story template has the following format:

As a [user role],
I want to [accomplish a goal],
so that [reason].

Let's examine that story template a little bit. Why is it so effective? We find an answer by looking to journalism and police investigations, to the "Five W's." In those arenas, these are essential elements of gathering or telling any complete story. You likely learned them in high school composition class, too. (The documented origins go back at least 2,000 years to the Roman orator Cicero, so it's safe to say they're time-tested.) They are the questions:

1. Who
   
2. What
   
3. When
   
4. Where
   
5. Why
   

The questions are designed to bring out the expositional details in a story, effectively "the essentials." Mapping to the user story template above, the [user role] tells us "Who," [accomplish a goal] answers "What", and the [reason] addresses a key element for understanding, the "Why." The "When" and "Where" often crop up in context throughout the elements. Consider a mobile application for users to get information about your local city. As an example:

"As a city visitor,
I want to get a list of festivals during my vacation week
so I can plan my itinerary."

Who=a city visitor, (not a resident)
What=get a list of festivals for the week they'll be in town
When=(presumably) some time before their vacation week? How much before? Good question…
Where=on their mobile device (we're building a mobile app)
Why=to plan their vacation itinerary
How=??? Yes, the "How" is missing, and that is on purpose.

The story clarifies the essential elements of the goal. Notice that the "When" answer generated a question for discussion and clarification. Notice too, that no implementation details are present…there's nothing in there about buttons, links, grids, etc. The answer to the question "How do we get there?" is left up to the development team. The Product Owner owns the 5 W's, but the development team owns the "How." And in the conversations around the user story, you also end up tapping the creative minds of the developers to help shape the requirement. That input might otherwise be missed by just relying on the one-way communication of handing them the finished requirement.

"But I want my detail!"
A car salesman can show you a brochure, review all the technical specs on a car, and tell you how great it is, but only when you test drive it do you get the real feel of whether it's right for you. I tell my teams that "at some point, you will have all the detail." That's at the end of the iteration, when the feature is delivered. Only then are all the unknowns eliminated. Both Agile and traditional requirements get you to all the detail, they just go about it in different ways. Traditional requirements are most often developed completely before development begins. Detail is arrived at by people speculating, projecting, maybe wire framing, and likely guessing at what the end state of the feature will be. The challenge there is that change is a constant, so everything that changes in the end makes the upfront effort to project the end state of what ended up changing into wasted effort. In Agile, beginning with user stories, the details are arrived at collaboratively between the Product Owner and the team, building something and putting it in front of the Product Owner for a test drive, and iterating and incorporating his/her feedback until the feature reflects what the Product Owner wants.

Not All Truths are Self-Evident
To some (both business and development), moving from generating and following detailed, prescriptive requirements to using user stories and face-to-face collaboration will be liberating… "Finally!...free from all the overhead!" But for others, it will like being made to walk that tightrope without the net, and their reaction can be visceral. Some Product Owners will feel that if they don't put all the detail in the requirements, they won't get what they want, or something will be missed. Some developers actually prefer the prescriptive development model of "just tell me what you want me to build and I'll build it." If you've embraced user stories and the benefits they and collaboration offer, that way of thinking will likely make little sense to you. You may even have a deep desire to stand up in a team meeting and proclaim "We hold these truths to be self-evident, that ALL Agile tenets are created good!" But you have to understand that some people are just not wired that way. Agile is a culture and a mindset, based on the Principles and Values of the Agile Manifesto. If your Product Owner or team members don't share those principles and values, you'll have a difficult time debating the merits. Remember, all the logical arguments in the world about how user stories are better won't matter to them. We're talking about perception of security here, and possibly even emotion, so it becomes subjective rather than objective.

So how do I make the move?
It's far more difficult to get people to remove detail from requirements than to add it. When faced with stiff opposition on this front, try putting the requirements through the same processes and rigor you would use to declare a user story to be "sprint ready":

• Engage the team in backlog grooming on those requirements. This will get the conversation between the team and business started sooner, and can open their eyes to the magic of collaboration in discovering that they need less detail spelled out in advance than they previously thought.
  
• Ensure that the 5 W's are present and clear in every requirement, and that the "How to" is not.
  
• Require every requirement to pass the INVEST acronym test: Independent, Negotiable, Valuable, Estimable, Sized appropriately, and Testable.
  
• Make sure also that each requirement has well formed "acceptance criteria" – just a few (maybe 2-5) clearly stated criteria, expressed again in language any user can understand – that tell us when the requirement is met. It gives you a clear script to demo against in the demo at the end of the iteration.
  
• The other extensive details can be covered in test cases, and their pass/fail can be reported succinctly in the final demo rather than walking through each flow in an all-day meeting.
  

Taking these steps to start with can start you down the path of transformation, give you some essential benefits of user stories, and overcome the objection of "working without a net." As always, I welcome your comments.

Sometimes, It's the Little Things...

Sometimes, it's the little things that make all the difference in the world for people...like the person that buys a $30k car just because they like where the cup holders are placed. Yes, I laughed at that too, but I've actually seen that happen.

Clients are people too, and I like to look for opportunities to provide a "better than expected value" for them. By that I mean, not just confining ourselves to what the SOW says we're to deliver, but other opportunities to deliver added value...whether it be handling little ancillary issues for them from a project management standpoint, or some helpful little documentation, or just a quick interpersonal check-in.

One way I go about this is I routinely (maybe daily) ask the stakeholder(s) "How can I help you? Is there anything I can do for you?" But you have to really mean it...come at it from a personal approach. The way I look at it, if it's something that lies outside of my realm of job duties, but isn't anything much to do, and helps them...it's worth a lot more in client relations in the long run than the few minutes it may take me to do. Maybe it's scheduling a meeting for them that they were going to schedule, but we're both attending, so I’ll do it. Sometimes, a client may be just overwhelmed with their workload and really flustered, and while there may not be anything I can do for them at the moment to lessen it, they appreciate just being asked. They like to know that someone just cares as a person. (NOTE: If you’re just not that kind of person, don’t attempt this. Being disingenuous with this is worse than not doing it at all)

Another way I've been doing this, as I alluded to, is supporting documentation. I’m talking about little “extras” that help the client, and might be something we would find useful ourselves anyway. By that I mean, we're not burning cycles producing some frivolous document just to provide that "added value" (i.e. make work), but something that they can actually use, but aren’t expecting...think Lean, and the categories of Value-Added, not Value-Added but Necessary, and Waste. Avoid the Waste.

Recently, I worked on a solo project for a client. There was a basic process logic flow that was an early deliverable, but there was one extra request from the client to annotate it. The annotation wasn't in the strict SOW, but I did it and in addition, color-coded the map by processing module to make it even easier to follow. As a result, It proved to be a valuable tool to for the client to easily communicate the logic of the application to both business stakeholders and technical staff. And while a lightweight technical manual was in the deliverable, I added details that weren't defined...such as including that diagram, writing detailed install instructions, etc. Again, these weren't strictly required, but were just something I wanted to include to make things a little easier, a little nicer for my client. And they appreciated it, which is what really made it all worthwhile.

Like I said, sometimes it can be those little details that really make the difference.

Microsoft’s new SDL Perpetuates Some Misconceptions of Agile

Recently, Microsoft published its updated Security Development Lifecycle (SDL), version 4.1a. It includes provisions for incorporating security tasks into Agile development, so naturally I was interested to read it. While on balance I understand what Microsoft is trying to do with this effort, I found a few misconceptions and knocks on Agile that I felt were unfair and disconcerting.
The chief misconception of Agile that I see perpetuated in this document is that Agile releases after every sprint (iteration). While this is possible, it is not necessarily the case and certainly not required by the framework.

On p. 47, in the section on “Melding the Agile and SDL Worlds,” the authors make the statement:

“With Agile release cycles taking as little as one week, there simply isn’t enough time for teams to complete all of the SDL requirements for every release.”

There are two issues with this statement, and similar statements throughout the document. First, the statement assumes a release after each sprint. Agile focuses on producing potentially releasable product in every sprint – and this is an important distinction. As you use Agile in your organization, if you don’t need to release after a one-week sprint, then don’t release. There’s no rule that says you must. Second, the statement seemingly knocks Agile for having sprints (they say “release cycles”) that are ‘too short’ to accomplish all the necessary tasks for SDL requirements. Again, there is no hard and fast rule here for Agile, other than the strong suggestion (call it a rule if you want) that sprints should be time-boxed to 30 calendar days maximum and that sprints stay the same length for consistency. But a team and Product Owner can choose a sprint length that is appropriate for their development model and business needs…if a team is choosing one-week sprints but can’t fit in security tasks deemed necessary, then the sprint timeframe needs to be lengthened.

There were also a few statements with respect to Agile and security in general with which I took exception. In the Introduction on p. 47, the authors make these statements:

“Historically, security has not been given the attention it needs when developing software with Agile methods.”

“There is a perception today that Agile methods do not create secure code, and, on further analysis, the perception is reality. There is very little “secure Agile” expertise available in the market today.”

The problem here is that the authors blame Agile methods for this shortcoming (real or perceived), and not the implementation of those methods, or rather the prioritization of the requirements or user stories undertaken in those Agile methods. If security requirements aren’t being given the attention they need, that’s flat out a failure of prioritization of the requirements by the Product Owner, not a failure of the methodology. You could conduct a sprint consisting entirely of security-related requirements, if those are the top priority, and that would be perfectly valid. Also, the very notion that there is little “secure Agile” expertise in the market is a logical fallacy called a “Complex Question”: unrelated points conjoined as a single proposition. In other words, there’s no such animal as “secure Agile.” There’s Agile. Security is but one consideration among others that can, and should, drive the prioritization of a product backlog.

I then came across this little gem of a paragraph on p. 50 of the document:

“Although SDL-Agile was designed for teams with short release cycles, teams with longer release cycles are still eligible to use the SDL-Agile process. However, they may find that they are actually performing more security work (emphasis added) than if they had used the classic, waterfall-based SDL. Requirements that a team only needs to complete once in classic SDL may need to be met five or six (or more) times in SDL-Agile over the course of a long project. However, this is not necessarily a bad thing and may help the team to create a more secure product.”

This smells to me like the framers of Microsoft SDL-Agile decided that there were certain security requirements that needed to be performed every sprint without consideration of the release schedule of the product. And, in fact, they seem to admit to as much in the preceding paragraph. This is all well and good, I suppose, if you’re OK with doing five or six times the required work for a release as you could otherwise do. But if that’s so, why would one ever choose to do that?

I’d like to offer a couple of options for the SDL-Agile folks to consider. First, remember that Agile doesn’t require you to release after each sprint, only that you produce potentially releasable product.  Second, consider using a “Release Sprint”: a sprint of those activities required before a release that may not be required in each development sprint. This could contain security-based stories as well as other typical release-related activities like, perhaps, user acceptance testing or compliance reviews. But my overarching advice to them, and to you, is to not let misconceptions of Agile hamper your implementation of it. Instead, just understand and respect the basic framework, and look for opportunities to apply the framework, principles, and culture of Agile within your organization. Do those things and I suspect that you’ll be pleased with the results.

As always, I welcome your comments.

Running Agile With Manual Testing Part 2: Feeding the Queue

A few weeks ago, I told you about how to practice Agile with an all-manual test harness. Now I'd like to give you some additional principles to keep in mind that will help you in this challenging scenario (and come in handy as good practices even with test automation).

A key notion to focus on in this situation is keeping a flow going at a steady pace, and getting stories through to QA testing early on in the process.

(Note: I'm adapting some of these principles from research work done on the construction of the Empire State Building by Mary and Tom Poppendieck for their new book, Leading Lean Software Development: Results Are Not the Point):

1.   Get ONE to Done:
Focus the team on one user story at a time and moving it to QA testing as soon as possible. So if you have four developers on your team, instead of having them work on four separate stories and moving all four towards QA testing at a relatively equal pace (which could get you four stories ready for QA testing at the same time and create a logjam), have them team pair up, split up tasks and get two stories, or even better just one, moving to QA. Think of automotive assembly lines, but instead of each developer building their own car, the team works on one car at a time, together, to get it complete before moving on to the next car.

2.   Feed the Queue Logically:
Be sure to consult the QA testers regarding the logic of testing order for the stories in the sprint. In Sprint Planning and in the daily Standup, be sure to ask the question “which of these stories make sense to test together, or in a certain order?” It sounds like an obvious point, but if you don’t ask the question, it could be missed. Then take this into consideration in prioritizing the stories in-sprint.

3.   Prioritize by Size:
We always want to work first on the stories with the highest priority per the Product Backlog. But within a sprint, IF the relative priorities of two stories are close and there's little danger of being stopped mid-sprint, and all else being equal, focus on the largest story first. There's generally (though not always) a direct relationship between the amount of development work for a story and the amount of testing required. There's usually also more unknowns, more issues, that can crop up on a larger story than a smaller one. By putting these stories into your testers' hands sooner, you give them more time to test and uncover these issues, and therefore give your developers more time to address the issues, during the sprint.

Just to illustrate the point, let's say you have five user stories in a sprint, A - E (by priority), as illustrated in the first graph below. I've applied a rule of thumb of 25% of development time required for QA. IF all else is equal, and you have the leeway to do so, prioritizing the stories by size (as illustrated in the second graph) results in a cycle of steadily decreasing testing time required for each story flowed to testers by developers:

(click to enlarge)

Also, by leaving the smaller stories to the end (the ones requiring less testing as well, per the rule of thumb), you accomplish several things. First, you lessen the lag time between when your developers complete their work and the end of the sprint. This keeps the developers from potentially “sitting around” at the end of a sprint. Also, you make it easier for QA testers to turn around testing successfully in the limited time at the end of a sprint because the testing required on those final stories should be less.

Keeping these simple guidelines in mind should help keep your sprint queue humming along like an assembly line, and make it that much easier to practice Agile with manual testing.

As always, I welcome your comments.