A Blog About Agile from Davisbase Consulting

Becoming Agile is the Davisbase Consulting blog about all things Agile. It features regular posts by our staff, whose diverse expertise and backgrounds enable us to offer fresh perspectives and insightful observations.

Check out some of our favorite entries by visiting the top posts page, and be sure to subscribe by RSS feed or email to keep up-to-date.

Design Thinking (Part Two)

In our last blog post Design Thinking Part 1, we discussed the overarching stages of the Design Thinking process based on the book, Designing for Growth by Jeanne Liedtka and Tim Ogilvie. Those phases are, what is, what if, what wows, and what works? Now you’ll learn the 15 steps to guide you through the Design Thinking process.

Before you start

1. Identify an opportunity
Design Thinking works well for two situations in particular. First, finding solutions to problems that have many unknowns. And secondly, coming up with innovations and areas of growth in your organization.

2. Scope your project
Start with a basic statement of the area of opportunity, then write out ways that scope can be broadened, and finally, go the other direction to see how that scope can be narrowed. This is an exercise that will help you start to see the opportunity in a new light.

3. Draft a design brief
In Agile we call this our Project Charter. It’s a simple one page brief to outline the area of opportunity, any key stakeholders, scope, constraints, expected outcomes, and success metrics.

4. Make your plans
Here you will decide the basics of the process. What is the timeframe, who will be involved on the team, and/or will it be a solo effort?

What is?

5. Do your research
In this step, you will gather insights about the state of your current reality. This research can be done in any number of ways. Interviews with stakeholders and/or customers, direct observation, secondary research (about industry norms, for example), value chain mapping, creating user personas, and journey mapping are all options. Just remember that this research gathering needs to be human centered, so aim to be as empathetic as possible.

6. Identify insights
Once you’ve gathered all this research, put it into a format for your team and even possibly your stakeholders to see. One common way is to make low cost posters at your nearby FedEx Office. Then you will hang the posters in a room, and give everyone a chance to walk around and capture insights on post-it notes. After about 30 minutes have them put their insights into clusters. These will be referenced later in the brainstorming step.

7. Establish design criteria
Now that you’ve got a solid idea of the opportunity in front of you, answer the question, “the ideal solution would ____.” In this step we aren’t solving the problem, but rather making clear the end result we are looking for.

What if?

8. Brainstorm ideas
We’ve finally made it to the solution generating phase. In this step we want to explore any and every idea to give ourselves a very large base to choose from. One great brainstorming process is very similar to a retrospective technique we use in Agile. Give everyone a post-it note pad, and give them 3 minutes to quietly and individually come up with as many ideas as they can. After the 3 minutes they will share their ideas with the group. Following that, they will get a second round of 3 minutes to come up with more ideas individually.

9. Develop concepts
Put all the post-it notes from the brainstorming session on a large board or wall where they are all visible. This next phase is where we start to build concepts. These concepts can be based on multiple ideas that came out of brainstorming, or even themes that the team struck upon.

10. Create some napkin pitches
In our Davisbase Agile training courses, we teach this exercise to our classes, and call this practice an Elevator Pitch. It’s a short pitch to convince someone of the basics of the opportunity, and the value proposition attached. Once you have a few concepts developed from the last stage, practice making some napkin pitches from them. Teams can develop these together, or as individuals and then pitch them to the other members of their team.

What wows?

11. Surface key assumptions
By this point in the process, the team’s energy is high, and they are ready to take these ideas to market. Before we do that, we need to burst their bubble just a bit, and surface the key assumptions that we are making in our concepts. What are the assumptions we are making, that if proven false, would prohibit our concept from being successful?

12. Make prototypes
Start to build prototypes of your concepts that you can begin to interact with and show to your stakeholders and/or customers. These can be in any variety of formats. They could be actual 3D objects. They could also be something 2D like a flowchart, storyboard, video, or even a drawing.

What works?

13. Get feedback from stakeholders
In this step we will introduce our prototypes to our stakeholders and/or customers. There are a few key ground rules to keep in mind. First, no selling. You shouldn’t have to convince your audience that these are good ideas. Second, offer only a small number of choices. Having 2-3 options available will help you to see which one your audience gravitates to. Lastly, aim to have a diverse group in your audience. This will help to ensure that there aren’t key assumptions that you’re missing, or that are false.

14. Run your learning launches
Now that you’ve developed your prototypes and have sign-off from your stakeholders, design the framework around how you will test these concepts, and test them! In this phase, it is critical to be willing to fail. Forcing a “solution” on your customer that isn’t actually solving a problem won’t benefit you or your customer.

15. Design the on-ramp
This last step is all about putting your successful prototype into place. This is the phase where we will introduce the new feature to our Agile teams to build. Additionally, ask yourself key questions like, “What will cause our customer to begin to use this product?” and “How will we entice customers to repeat their business?”

Now you’ve learned the four overarching principles of the Design Thinking process (what is, what if, what wows, and what works), and you’ve got 15 actionable steps to put each of these phases into place. Contact us to help you through this process, and also find ways it can enrich your existing Agile process.

Achieving High Performance with Disciplined Teams

blogimage_Achieving-High-Performance-with-Disciplined-TeamsSome come to Agile assuming it involves less discipline than their traditional methods, but this is a misperception. Today, the need for discipline in software development is greater than it ever was. Agile answers that need arriving at discipline through the Team. Agile Teams must collaborate to develop strong discipline in both planning and execution.

Join Andy Painter on Thursday October 9th at 12:00 PM ET to discuss how teams can obtain Agile discipline to achieve one of our core principles of delivering “working software” frequently. We’ll explore some of the key Agile planning and engineering practices like continuous planning, Test-Driven Development, Continuous Integration and Acceptance testing. We’ll look at the discipline involved in these practices, their inter-relationship, and the benefits they realize in delivering value to the customer.

This webinar explores the qualities that a high performing team must possess in order to realize the benefits of Agile and how a team evolves from forming, storming, and norming to ultimately performing.  The webinar will also discuss the need to build teams around value streams instead of projects in order to create team permanency to maximize productivity and return on investment.

Register now!

Design Thinking (Part One)

Design Thinking is a process used by many organizations, such as IDEO, to create new areas of growth in their companies, and find solutions to problems that have many unknowns. Design Thinking is very complimentary to the Agile process. It is most often used as the design and ideation phase prior to the team building software, but also has the potential to be intertwined into the team’s existing Agile process.

How do you get started?

One great book which outlines the Design Thinking process into concrete steps that anyone can take is Designing for Growth by Jeanne Liedtka & Tim Ogilvie. Design and innovation can be uncomfortable terms for those of us who don’t consider ourselves “creative types.” However, Designing for Growth lays out the innovation process into a step-by-step plan that is easy for even the person least likely to wear thick-rimmed trendy glasses to follow. In this blog post we’ll explore the four main stages of the Design Thinking process.

Phase one: What is?

The first phase of design thinking is the “What Is?” phase. In this stage we are doing our research to find out what the status quo is. What is the state of things in our current reality? This stage is the most difficult for those of us who are quick to take action. In this phase we will gather lots of insights about the state of things, and will likely want to start right away to make decisions about how the status quo needs to change. However, do your best to avoid making judgements and resist taking action for now. Just focus on being a scientist (if you will), and simply make observations.

Phase two: What if?

The second phase of the Design Thinking process is where we start to generate ideas. Here we will generate as many possibilities as possible. The important thing to remember in this stage is that anything goes. Frequently we are critical of ideas, and that critical eye has its place and time, but not in this phase. This phase is about coming up with many ideas that will later be candidates for testing and prototypes.

Phase three: What wows?

In this third phase, we start to assimilate all the ideas from phase two into prototypes that can then be tested. But first, we will identify all the key assumptions made such as, what our stakeholders need and what our customers want. In the first phase of the process, “what is?”, you will have gathered many insights about your stakeholders needs, and the objectives of the organization. In this third phase, “what wows?”, you will look for the intersection of three key questions. Is it feasible, do the stakeholders want it, and does it meet our organizations needs?

Phase four: What works?

This final phase is about testing out the prototypes which were developed in the third phase that have been generated from the ideas created in the second phase which were built on our insights from the first phase. It’s all falling into place. This is where our already engrained Lean mindset becomes very useful. The goal of this phase is to first make small tests, fail (or succeed!) early, and move on the the next test. A key to remember in this phase is to listen to your customer. You’ve likely nurtured an idea through the whole process, and even though you may be somewhat attached to that idea by now, it’s important to stay neutral and focus on the voice of your customer.

Depending on the makeup of your organization, your engineering teams may get involved earlier on in the prototyping phase, or they may come into the process after the ideas have been tested and are ready to move forward into the building process.

By now you are sold on the Design Thinking process and are wondering how to get through all these steps. Look for part two in this series to learn the 15 steps to implementing the Design Thinking process. Thick-rimmed trendy glasses optional.

What Is Agile?

So just what is this Agile thing?

If you ask 10 different people, you will likely get 10 different answers.

A methodology.

A practice.

That thing we tried that one time.

The fact of the matter is that many groups who claim to be an Agile organization, or have tried to become Agile are lacking the very basic understanding of just what it means to be Agile.

The process of becoming Agile must start with the understanding that a cultural shift must occur. To be Agile means to embody the Agile Manifesto and the 12 Principles of Agile. Agile is not a methodology, Agile is a culture of openness, trust, and communication.

With that said, there are many methodologies that have been recognized as being Agile in nature. Methods such as Lean Software Development, Kanban, Extreme Programming (XP), and many others are considered to be Agile due to the foundations with which they work.

Probably the most popular Agile method, and what most think of when they hear Agile, is Scrum.

Scrum is an iterative development model that aligns business partners and development teams as one. The teams work together in a collaborative fashion on a daily basis with the goal of delivering working software following the completion of each iteration or sprint.

For more on “What is Agile”, please listen to our podcast below!

 

 

 

A Tribute to Bill

Bill GaiennieAfter battling brain cancer for almost a year, our co-founder Bill Gaiennie passed from this life to the next this past weekend.

There are not words to describe the love and appreciation we all have for Bill.  We will certainly mourn his passing but honor him through changing lives for the better.  We know we are all better for having had his influence and enthusiasm in our lives and we know he has touched many of your lives as well.

We want to also express our appreciation to all of our loyal customers, partners and community.  We are blessed to work with such great people.  Like Bill always did, let’s always look for the best in each other and those we serve and find ways to change lives for the better.

A celebration of Bill’s life will be held outside Austin, Texas on October 4th, 2014.

In memory of Bill, we’ve pulled together a collection of his great blog posts from the last 7 years.

Most sincerely,
Steve and Andy

Continuous Improvement Through Retrospectives

Agile RetrospectiveAgile teams use retrospectives in order to tune and adjust behavior, but when is the last time you’ve taken a moment to retrospect on retrospectives?  Join Leslie Morse, one of our Managing Directors, for a FREE 1-hour webinar on this very topic next Thursday, September 4th at 12:00 ET.
She will cover the importance of retrospectives, the various levels they occur, different approaches for conducting retrospectives, and recommendations for keeping track of a team’s improvement backlog.  
 
Attendees of this webinar will also get the first access to our new Coaching Guide for Retrospectives which includes:
  1. Why are retrospectives important?
  2. Substance and Spirit
  3. Who should participate?
  4. Preparing for a Retrospective
  5. Establishing a Safe Environment
  6. Facilitation Versus Participation
  7. Making It Happen
  8. Discovery Question for Rich and Meaningful Discussion
  9. Handling Personal Conflict
  10. Potential Pitfalls and Disruptions
  11. Retrospectives Mean a Commitment to Improve

Sign up Now!

An Intro to the Scaled Agile Framework

yogi-berra“The Future Ain’t What it Used to be!”

One of many classic quotes from the great Yogi Berra – and this one hits home when thinking about the future of Agile.

Yogi was also heard to say, “It’s tough to make predictions, especially about the future”, but Gartner and PMI may be the most credible exceptions, when it comes to prognostication in our field.

Gartner predicted that Agile methods would be used on 80 percent of all software development projects by the end of 2012, while PMI’s research shows that Agile project management tripled from December 2008 to May 2011. Top reasons cited for this growth include significant decreases in defects, improved team productivity and increased business value – Agile results, as advertised.

So, what’s next? How about planning and budgeting to effectively support this kind of growth? Enterprise-level Agile is coming your way and the Scaled Agile Framework® (SAFe) is your path to success at this level.

SAFe is the framework needed to scale Agile to the Enterprise level and effectively support teams by planning for the bigger challenges of funding, integration, architecture and role adjustments at scale. Based on proven Lean principles, further defined for Agile by Dean Leffingwell, SAFe addresses Agile at scale by enabling organizations to adopt Agile principals at the Program and Portfolio levels – beyond and in support of Team level efforts.

Successful adoption of SAFe starts with identifying a value stream, or activities sequenced to deliver consistent value to customers. An identified value stream can be worked as an Agile Release Train (ART – the vehicle that delivers value at the program level). Options to consider when identifying initial value streams may include early adopter programs with executives that are positioned and ready for transition.

The place to start exploring SAFe in more detail is http://www.scaledagileframework.com. Peruse the Big Picture. Drill down into each of the topics that pique your interest. When you’re ready for more in-depth training on SAFe, contact Davisbase. Our certified SAFe Program Consultants can get you to the next level so that you’ll be positioned for a predictable Agile future.

One last Yogi-ism as you consider SAFe and the future of Agile: “You’ve got to be very careful if you don’t know where you are going, because you might not get there”.

3 Ways to Keep Your Standup From Being a Status Report

standupThe daily standup is intended to be a planning session, not a status report. This is surprising to many since the first question is the status of what you did the day before! Many teams as a result fall into the status report habit and don’t get the benefits of an excellent standup: early impediment identification, self organization, and the efficiency of a whole-team approach.
Here are three approaches that can help break your team if they are stuck in a standup status situation:

Wear a Name tag

Have your scrum master wear a nametag to standup, but instead of their name write “DO NOT LOOK AT ME” in big letters.
People tailor their words to their audience naturally and subconsciously.  Encourage your team to talk to each other by encouraging them to look at each other at the daily standups.  Listen for “oh yeahs” here — “Oh yeah, Susan!  You’re going to want to know about this…”

Skip Roll Call

Does someone “call roll” by announcing who should speak next at your standup?  Are they the ScrumMaster?  Skip this step by having each team member ‘call on’ who should talk next.  This technique gets your team thinking about who is affected by what was shared, and since you can only call on those that haven’t spoken, keeps team members on their toes and engaged during everyone else’s updates.  This is especially effective for distributed teams doing a call-in standup!

Ask, “Who Cares?”

In order to help team members identify the right questions and the right people, try a fourth question in your standup: “Who cares about your work today?” This helps anticipate problems with handoffs and assistance.
For example, consider this interaction between Pamela the programmer, ScrumMaster Mark, and Tommy and Trisha the testers.
Pamela reports that a programming task will be completed today.  Mark prompts her to answer the fourth question: “Who cares about that?” Pamela identifies that she expects one of the team’s two testing specialists to pick up the testing that is now ready.  But Tommy and Trisha, after a glance, say that they won’t have time today or tomorrow to do that work!  Pamela realizes that her time is better spent on another more pressing task.

Trying It Out

The best way to bring these tricks into your team is at retrospective.  Ask your team: Are our standups planning sessions or status sessions?  Use the list of benefits from the top of this article (finding impediments, enabling self-organization, supporting a whole team approach) and see if they resonate.  If not, ask the team to come up with their own list of benefits from a less-status-more-planning approach. Once everyone agrees that there is a problem, then introduce these three ideas, and change them as needed or even create your own. And if you do try them, remember to review the change at your next retrospective.  And also let us know how they worked for you!

What the US Army Taught me About Agile Teams

417262_187430241371796_466345890_nQUICK: What is the first thing that comes to mind when you think about Army life?

Command? Control? Structure?

If those terms came to mind, you would be correct…to a degree. (Remind you of anything? Like, WATERFALL!)

When I enlisted, I was shipped off to the glamorous Ft. Sill, Oklahoma. Oklahoma in February is not pleasant.

My first memories of moving “across the tracks” from reception to 1/40 FA (Delta DAWGS!) consisted of freezing temps, carrying heavy duffels for what seemed like a million miles, and the shark attack.

For those of you who have never been in the military, the shark attack is something that is burned in the minds of those of us who have. The military life is new, you’re a little scared, and then these guys and gals in big brown hats start screaming at you, spitting in your face, and you’re doing a lot of pushups.  You’re not sure why, but you are doing A LOT OF PUSH-UPS!

All of the insanity is meant to do one thing: teach teamwork. The group went through something incredibly transformative together, and those experiences bonded us for life. I still keep in close contact with many of those guys today.

While it may not be quite as dramatic, new Agile teams will go through similar emotions. Teams will experience the fear of something outside of the norm, the transformational stages of forming, storming, norming, and performing. Although difficult, if the team embraces the challenge it will turn into an incredibly positive experience.

After the initial training courses, a funny thing happened: our opinions and input started to matter. Even though we were not the most experienced guys on the team, the more seasoned soldiers recognized that fresh eyes often catch things that the most seasoned guys overlooked.

Consider the similarities in the Agile model. Instead of a tech lead or senior developer assigning requirements to the team, the entire Agile team discusses and collaborates on each and every user story. The thoughts of even the most junior developers are valued and considered as much as the senior developers. Just as I have seen junior enlisted soldiers point out potential hazards (that could have cost lives if overlooked), I have seen junior developers turn complex architecture into simple solutions.

The point is: change is never easy. Regardless of if the transition is from civilian life to military, or from waterfall to Agile, the journey will be full of hard days and incredible victories. Let me assure you that it is worth it.

You will have more fun at work, you will be less stressed, and you will even stand to improve your home life as a result of a better work environment.

I challenge all new Agile teams out there to heed the words of Drill Sergeants Williams and Shoemaker: work hard, keep an open mind, respect the person next to you, and in a few months you will wonder why you ever thought ANY of this was difficult.

You can do it. Your team can do it. Hang in there.

You will be glad you did!

Agile (Cookie) Development

Can Agile Development Practices Produce a Signature Cookie Recipe?

Debbi Fields, Wally Amos, and I have something in common: we each have our own distinctive cookie recipe. Of course, their brands, Mrs. Fields and Famous Amos,are household brands; whereas, my cookie is just notorious among the relatively small number of people who have eaten my cookie.

By way of background, I’m a formally-trained chef with an economics degree and a knack for leading agile teams in designing software and solving complex problems. Software development lets me exercise both my right and left brain, but I’d really love to go the route of Debbie Fields and Wally Amos: if not with my cookie recipe, then with any of the other signature recipes I’ve got up my sleeve.

Iterating Towards a Recipe

I’ve been working on a cookie recipe for years, and it’s taken a somewhat Agile approach. You may say I’ve been working on the user story, “As a chef, I want to create a cookie that’s so delicious and distinctive that people will crave my cookies and pay me to make my cookies for them.”

I didn’t start out by doing a bunch of math formulas and writing down what I felt was the perfect recipe.

Instead, in preparation for the first batch, I weighed out the basic chocolate cookie ingredients (flour, baking soda, sugar, brown sugar, salt, vanilla, butter, eggs, and other super top secret ingredients) in grams. I made sure I had more than I needed, but minimized the amount I’d have to put back into a container or waste.

I also didn’t include chocolate chips because they’re expensive and I just needed to see how the dough portion changed in the oven: how was the spread? was it chewy enough? did it rise the right amount? The chocolate chips would contribute significant expense to my experiments without adding much information about the final output. If you consider that the chips were part of a “Chocolate Chip” user story, they were ranked lower priority; they were a feature that could be added later with minimal rework of the first set of stories.

At this point, all I had was a vision for the cookie.

Release Planning

Once I had my ingredients weighed out, I started the typical process: creamed the butter with the sugars and salt, added the wet ingredients, and then started adding the dry ingredients. I added by a fair amount of my allotted flour, mixed it in, then inspected it. I added a few spoonfuls more and inspected again. When I thought I had the right consistency, I baked it to see how it turned out. After two or three iterations of this process, I arrived at a result I liked and I wrote down the difference between the initial ingredient measurement and the remaining amount of the ingredient. This formed the basis for my recipe.

During this phase, my measurements weren’t at all precise: it was a gut feeling. If fact, I intentionally didn’t measure because I didn’t want to subconsciously add amounts that conformed to what I’ve been taught are “ideal” butter:sugar:flour ratios for different types of cookies.

At the end of this phase, I had just enough information to allow me to perfect the recipe and move to the next stage. My measurements were accurate, but not yet precise.

Sprint Planning

On the next batch, I started from my written recipe and purposefully and thoughtfully tweaked percentages of ingredients to adjust specific ratios of ingredients (flour:butter:sugar). I delved deeper into the details, and worked until I had measurements to a precision of 0.1g.

At this point, I had a very solid idea of what I wanted to make, and I was confident I had enough information to bake exactly the cookie I wanted to make.

Sprint Execution

Here’s where my current journey ends. I’ve been in sprint execution for awhile. Each time I bake a few dozen cookies for people, I’m executing sprints and doing sprint reviews with various friends, family, and coworkers. Gathering input, hearing what people believe is good or bad about the cookie, and potentially making changes in the next sprint.

Each batch is potentially shippable. I’m closer to knowing what it would take to make the cookies production ready, but I’m not quite there.

Release Overhead

If I were to take my cookies to the next level, I’d need to do some performance load testing.

The recipe is perfect right now: it’s repeatable and produces the same results. My unit tests tell me that the recipe is working on a small scale, and user acceptance tests have shown the quality is correct.

However, my ingredients have a maximum of four significant figures, because I’m only measuring less than a kilogram of any ingredient to a precision of 0.1 gram.

Let’s say my recipe calls for 302.5 grams of flour, and I want to make my cookies for the masses, so I need to make a 10,000x batch. The 302.5 grams I’m measuring may in reality be 302.5124. If I were to make a 10,000x batch, the recipe wouldn’t be right unless I used 3,025,124 grams of flour. It may be close, but it wouldn’t be perfect.

Once that final piece of testing and preparation for launch is complete, there’s only one step left: launch the product.

Agile Principles Have Broad Application Possibilities

Agile development principles can be applied to just about any problem. Even if the Scrum ceremonies aren’t present, the Agile process can be applied to iterate towards a desired end result. One of the key parallels in this analogy is that the level of precision increases at each step. With the cookie recipe, I’m getting ever closer to knowing the actual recipe with a much finer precision at each step. At some point, if I were to go into business selling my cookies, the recipe would be known.

In a software development project, we get ever closer to knowing the actual delivery date, features, and cost of the project at each step. Once the project is delivered, those three things are known. If you find yourself thinking about how many hours something will take to do during the Release Planning phase, you’re likely too deep into the weeds and it’s time to pull back. You’ll figure out how many tenths of a gram of flour belong in the recipe when it’s time. For now, just make sure your general ratio is close enough.