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 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.

Scaling Agile

SAFe_BigPic_3.0_MediumAs organizations move beyond implementing Agile at the team level, the need to scale across multiple teams within a Program or Portfolio grows.  Scaling Agile requires a greater degree of structure, governance and measurement to support this effort.

This webinar introduces strategies for scaling Agile, including Scaled Agile Framework (SAFe), within an organization and how to create traceability from a business strategy to value creation at the team level.

We will take you through the origin of the Scaled Agile Framework and cover the foundations that anyone interested in scaling Agile needs to know.  These include:

  • Accelerating value delivery
  • SAFe Core Values
  • Goals: Speed, Quality, Value
  • Lean Pillars: Respect for People, Product Development Flow and Kaizen
  • Lean Foundation: Leadership
  • Scaling to the portfolio and program levels.

This event takes place at 12:00 PM EST on Thursday August 7, 2014 and is hosted by Davisbase CEO, Steve Davis.  Sign up now!

Purpose and Community

2 Keys to a More Engaged, Productive Organization

blogimage_purpose-communityWhat’s your purpose?

Who do you share it with?

I believe these two questions point the way forward for creative networkers and successful organizations now and into the future.

Two years ago, while working for a large company, I had the privilege of collaborating with a small team of peers, real internal hustlers, to guide the implementation and use of Agile for a large, multi-year corporate initiative. While this was of course a serious responsibility, it was not our full time job. We were constantly searching for the necessary time to devote to it in order to ensure it would be successful. Despite this challenge, our group’s level of engagement and list of accomplishments was more significant than many of us had seen in a long time.

As I have reflected on this experience in the time since, I have come to realize that something deeper had occurred that led to such results. We had a clear and compelling vision with the autonomy and empowerment needed to make progress quickly. We knew what our unique and important purpose was in the organization. There was a small group of us that were committed to this purpose and beyond that to each other – we even had a secret name for our group and maybe a faux gang sign too. We definitely had that team “ba”.

Since then, the two concepts of Purpose and Community have continued to stand out to me as keys to unlocking greater potential in our organizations.

Purpose

“The capacity for logical thought is one of the things that makes us human. But in a world of ubiquitous information and advanced analytical tools, logic alone won’t do. What will distinguish those who thrive will be their ability to understand what makes their fellow woman or man tick, to forge relationships, and to care for others.” ~Dan Pink

At a very young age, we begin talking about who we want to be and what we want to do when we grow up. Recently, I’ve enjoyed observing my niece, not even five years old yet, talk with great passion about food, recipes and being a baker when she grows up. My sister reports that when they go to a bookstore somehow my little niece-with-an-already-discerning-palate always finds her way to the cooking section and begins flipping through books page by page. Whether or not she will one day pursue the culinary arts is of course anyone’s guess – we all know that our career ideas and aspirations sometimes morph and change as we grow older. Ultimately, though, our search for purpose seems to be a constant throughout our lives.

That’s because we want to know that what we do matters.

Some years ago, as a new manager in corporate IT, I struggled with a lack of a sense of purpose. My team was responsible for a variety of important systems and applications but they did not seem to have any real common thread. That was until the day our new boss entered the picture.

Having the benefit of many more years of management experience, he was quickly able to see a common thread running through our systems from both a business and technology perspective. He moved quickly to define our team and its purpose and did so with startling simplicity and clarity. While team performance didn’t radically increase overnight, that clarity of purpose was the beginning of a laser-like focus for us on who we were and what we provided for the organization. It laid the groundwork for increased team engagement and performance in the long run.

That early management experience for me was formative, but my belief in the power of purpose isn’t based solely on my own experiences. More and more we are learning about the science and psychology behind purpose in our work. Recently, published results from a study by The Energy Project and Harvard Business Review showed that purpose was one of our most important needs at work and that when that need is met we are 1.4 times more engaged at work, 1.7 times more satisfied with our job, and more than 3 times as likely to stay with our organizations.

It’s becoming clear that the concept of purpose is quite powerful.

Put simply, purpose cuts to the very core of who we perceive ourselves to be, why we exist and what we should be doing with the very limited time we have given to us. When we understand our purpose and when our work is aligned with that purpose, we are poised to accomplish far more than we previously thought possible.

Having an understanding of the power of purpose, we might consider asking questions like:

  • What is my personal purpose?
  • Is my personal purpose aligned with my professional work?
  • What do my colleagues and team members perceive their purpose to be?
  • What is our team’s purpose within the organization?
  • Is our team’s purpose strongly aligned with our organization’s purpose?

 

Community

“Organizations are communities of human beings, not collections of human resources”.  ~Henry Mintzberg

Just as we want to know what our purpose is from a young age, we also want to know others and be known by others. We are intrinsically wired for community, for sharing our lives with one another, our joys, our fears, our struggles, our successes. We bond together in family units and share the very core of who we are in these relationships. We come together for all manner of activities in life from athletics to academics to religious worship and more.

Why then do so many of our modern day corporate institutions feel devoid of a sense of community? Might we be settling for less?

It might help to revisit the definition of community:

a feeling of fellowship with others, as a result of sharing common attitudes, interests, and goals; a similarity or identity.

If you’re like me, you might have experienced this type of community a handful of times throughout your career. And these are probably the teams and experiences you remember the most fondly and speak of with pride. Typically though we don’t expect this kind of experience in the workplace. We expect and settle for the opposite – lack of meaningful connections, infrequent fellowship, fear and distrust run amok, disparate identities, and conflicting goals.

It seems to me that some significant contributors to this problem are a lack of awareness of the power of community in the workplace and numerous traditional corporate practices that are usually left unquestioned yet undermine or outright prevent the possibility of community. Some examples that come to mind…

  • Regularly creating and then dismantling project teams
  • Assigning workers to multiple project teams
  • Frequently shifting individual and team priorities
  • Vague sense of organizational vision at the team and individual levels
  • Creating individual performance goals that inadvertently pit individuals, teams and departments against one another
  • Treating professional craftsmen and craftswomen as resources, or more bluntly, easily swappable warm bodies
  • Narrowly defining people by their primary skillset (e.g. Java developer) and thereby limiting their growth, creativity and potential contributions

The list could go on.

I think it’s worth exploring what the idea of community means in our workplace because I’ve experienced its immense power on a couple of rare occasions. I’ve witnessed the deeper human meaning derived from work done in community, the improved relationships and collaboration, the lowered stress, and the resulting increases in team and organizational performance. I also continue to read stories and studies from companies like SpotifyBufferZappos, and others who are exploring this same path and experiencing similar results. I think organizations like this are onto something significant in the creative networker age.

If you’re interested in this notion of community, you might consider asking questions such as these:

  • Do I have a strong sense of community in my workplace? Why or why not?
  • If not, what could the idea of community mean and look like in our workplace?
  • How might a stronger sense of community improve our sense of meaning and our performance at work?
  • What might we together achieve if we had a stronger sense of community aligned to a common purpose?
  • What current notions and practices in our workplace might be undermining the possibility of community?

Success in the creative networker age hinges on understanding our purpose and who is in it with us.

What’s your purpose?

Who do you share it with?

Further Reading

Visualize your Purpose by Jurgen Appelo

Rebuilding Companies as Communities by Henry Mintzberg