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.

The Art of Servant Leadership

blogimage - Servant_LeadershipIt’s easy for people to throw around the term “servant leader,” but its another thing to actually be a servant leader. Just as our Davisbase Consulting trainers and coaches tell clients — learning Agile concepts is relatively easy, but putting them into practice is much harder. Similar to the way Agile is a philosophy, and mindset, for how teams can deliver value, servant leadership is a philosophy towards leadership. By executing the practices commonly exhibited by true servant leaders, doesn’t necessarily make you one.

During our December #BecomingAgile webinar, Leslie Morse will guide us through values, principles, and practices of servant leadership as well as provide webinar participants with a quick assessment that can help you decide where you are on your journey to becoming a true servant leader.

Register now and we hope to see you there!

Proactive Stakeholder Engagement

It seems as if many of my recent client conversations have circled around a singular topic, Business Readiness. The more we’re practicing Agile concepts (Scrum specifically), the more it becomes apparent that given the perfect conditions, adopting Agile is pretty easy. The challenge is that we’re never given the perfect conditions. As a result, much of the coaching and training I do focuses very little on Agile or Scrum. More often it focuses on the other organization complexities that exist within companies today. So today, I’m going to make a pretty bold statement, but I’m doing it in order to make a point.

Teaching a single team Agile concepts is easy, but preventing them from delivering rubbish is hard.

It’s true. Given the perfect conditions, you can teach a single team (or maybe even 3-4 teams) enough to do the basics of Agile sufficiently well in 60 – 90 days. We are seeing that basic team instruction is becoming somewhat of a commodity, however, just adopting Agile practices and mastering Scrum won’t get the benefits that Agile has to offer.

In fact, getting the true benefits of Agile starts with the business, and the idea of business readiness. Are Product Owners even asking for the right thing? Have they aligned all their stakeholder to ensure that there is consensus and understanding in order to prevent unnecessary rework that could have been avoided by a single conversation?

Here are my three suggestions for better business readiness:

  1. Stop Running, Slow Down!
    Just because the project seems like a good idea, doesn’t mean it is one. Too many projects get approved and put through the pipeline and organizations are overburdened with too much Work in Progress (WIP).
  2. Clean the Junk Drawer
    Often times the scope of new workstreams is weighted down with leftovers from previous projects, nagging production defects, enhancements, and new functionality. When defining scope it is critical to focus on the smallest set of features that, if deployed, would add value for end-users.
  3. Define a Stakeholder Engagement Strategy
    Who are the influencers on the effort, and what is the right frequency to engage them to ensure the right level of proactive input? The engagement of these individuals cannot be left to chance. They’re often busy individuals and it takes weeks to get on their calendars. That wait time is a bottleneck for teams and causes waste within the value stream.

The first two in that list are not in scope for today’s exploration, but I do want to offer a few suggestions on #3. A stakeholder engagement strategy is a key element of any successful Product Owner’s game plan. Its accomplished by completing just a few simple steps.

  • Step 1: Analyze Stakeholders
    Who are they, and how close are they to the work?
  • Step 2: Define the Cadence
    How often should you meet?
  • Step 3: Follow-Through
    Keep the discipline for the sessions.




Step 1: Analyze Stakeholders
Who are they, and how close are they to the work?

More often than not a three-tier classification model is sufficient. It all starts with the Product Owner though. The single source of truth to the Agile Team(s). They act as the funnel, aggregating input from all stakeholders in order to ensure there is a single voice guiding the “what” the team works on. Keep in mind, in your organization it may not be realistic for the PO to bear all this burden. Very often it works best to pair a Business Analyst with the PO to help with eliciting information, analyzing results, and aligning the stakeholder group.

  • Advisors
    These are the individuals closest to the work. Apply the same rule-of-thumb used for sizing Agile teams. 7 +/- 2 should be enough to compose a committee of Advisors. In practice, I often see this group include the PO’s direct leadership, someone from user experience, and a representative from architecture (or a tech lead). Other groups to consider would be training and operations support.  Product Owners should rely on Advisors to help validate priority, high-level acceptance criteria, and completeness of functionality within the backlog.
  • Supporters
    These individuals are often 2-3 degrees of separation from the work. They may be of a slightly higher leadership level, peers of the Product Owner’s direct leadership, or come from groups within the organization that are more indirectly impacted by the work the team is doing.
  • Sponsors
    Higher levels of leadership often make up this level of stakeholder. They are engaged in order to guide the overall direction of the work the PO is doing, and are very useful in resolving conflicts of opinion among other stakeholders within the group.

When analyzing stakeholders, don’t forget that all types of stakeholders should be considered. Actual end-users, business groups, leaders, and technology specialists should all be evaluated when determining stakeholder classification.

Step 2: Define the Cadence
How often should you meet?

There is no single-right answer to the idea of cadence. The figure in this post outlines an option for you. You can see it prescribes a weekly meeting time. The time each week is the same. The only variable is WHO. Based on the stakeholder map across the three groupings, a different “team” gets together. You may decide a cadence based on meetings every other week are good enough, it’s truly up to you.

In addition to cadence, its also important to determine the focus. Try not to dwell on what the team has already delivered, these sessions are intended to capture proactive input on what the team has coming up in the future. If you’ve watched the recording of the Strategies for Grooming Your Backlog webinar, then you’ve got the idea that this focus is likely 3-4 iterations ahead of where the team is currently working.

Step 3: Follow-Through
Keep the discipline for the sessions.

There is always something to discuss. Don’t cancel the sessions willy-nilly. Keep the habit of the meetings to ensure participation and engagement of the stakeholders. It may be slow to start, but over time you’ll find this invaluable, and the stakeholders will be delighted with their input is manifested in the product demos at the end of each sprint.

I hope this was useful, it’s a passion area of mine, and please share your success stories on these types of stakeholder engagement patterns!

A Summary from BBC 2014

I had the pleasure of conducting a 3-hour pre-conference tutorial at the Building Business Capability (BBC) conference earlier this week. It was truly a lovely time. The team there was welcoming, and if you’ve never attended an event at The Diplomat in Ft. Lauderdale, FL – GO! Its a wonderful facility.

Sadly, my time at the event was limited, and I did not get a chance to connect with many folks in attendance. If you missed out on my session, Advanced User Stories, then here’s a re-cap.

The Materials:

In the beginning… 
There was a room full of business analysts grouped into 7 groups (6-8 people each). There were also a lot of blank posters on the wall.

start 1start 2

Then the magic happened…
I lectured some, the groups collaborated, questions were asked & answered, the posters were filled.

general 6 general 7 general 1 general 2 general 3 general 4 general 5


The results were captured…

Lifecycle of a User Story

lifecycle 1 lifecycle 2 lifecycle 3  lifecycle 4 lifecycle 5 lifecycle 6 lifecycle 7


Techniques for Supporting & Elaborating User Stories

techniques 1 techniques 2 techniques 3 techniques 4 techniques 5 techniques 6 techniques 7


Practicing Story Elaboration – Use Cases

use case 1 use case 2


Practicing Story Elaboration – Specifications by Example

example 1 example 3


Practicing Story Elaboration – Given-When-Then


And then we reflected on how to improve…
What should we Start, Stop & Continue.

Start Stop Continue
  •  Bringing Value First
  • Leverage User Stories to define deliverables for Knowledge Management
  • Try Specifications by Example
  • Get comfortable with “Just Enough”
  • Trying to groom stories just a little every day, have longer workshops 1-2 times per sprint
  • Trying to get the perfect story on the first try
  • Bearing all the burden for refining stories
  • Using Story Mapping
  • Detailing Acceptance Criteria

Additional References:

Useful Resources & Posts from Davisbase:

Wondering what participant’s said about the session?

Great workshop, it was really interactive and provided good insights into how to create user stories and what additional information is required. User stories are not enough.
– Darcea Klein, BSA @ Alberta Pensions Services


A Valuable Insight: We need to enhance our User Story Lifecycle to ensure readiness.
– Lisa Cornelius, Manager – Product Development @ Jewelry Television


A Valuable Insight: We are new to SAFe / Agile. This helped me understand that some of our insanity is just that, insanity.
– Angela Thomas, Manager – BA Team @ The Kroger Co.


Take this workshop and walk away with real, tangible Agile techniques.
– Sandra Jones, Sr. Business Systems Analyst @ K-love & Air 1 Radio

The PMO Minefield


Photo: Tony Wheeler/Getty

First, before anyone starts firing off angry emails, let me state a few clarifying points:

  • I am a card carrying member of PMI
  • I studied the PMBOK extensively as part of my MBA program
  • I do not hate Project Management(!!!)

With that out of the way, let me further elaborate by stating that the notion of a PMO is extremely dangerous. Add an Agile culture and you have a stage set to go nuclear.

Agile and SCRUM do not eliminate the need for Project Management.

Agile and SCRUM do not eliminate the need for a PMO.

We just need to change how we look at these functions.

So why a minefield?

Lets be honest. How many of you really know what the PMO does? How many of you know what the PMO should do?

For those of you who said “yes Adam, I KNOW what a PMO is supposed to do.. it ensures value”

Ok – great! Can you define value?

BOOM! Mine detonated.

Provide a home for Project Managers. Are your PMs a part of their project teams, or apart from their project teams?

BOOM! Theres another.

Define and support a methodology. Do you and your end users define your process, or do your tools?

BOOM! Another.

YES.. the PMO was stood up to add value.. and to serve as a “home” for the project managers.. and to reinforce methodology. But please keep one point in mind: if you are in the PMO, you are evaluated based on how well YOUR process is adopted. It is in your best interest to dig your heels in, dictate process, and do things that are in the best interest of the PMO.

How Agile is that?

Lets shift that paradigm!

Agile teams are all about improving the process. Discovering new efficiencies. If, as a PMO, we change our mindset from “do as I say” to “lets talk about how we can make our lives better”, folks will likely stop running every time they see the PMO police coming.

So what does that mean? Here is a very concise list of things that a PMO purist can change in their doctrine to survive and THRIVE in an Agile culture.

1. RELAX!(!!!) It isn’t that serious. We understand that you want to do a great job, and we want to support you, just tone it down a smidge.

2. Resist the urge to dictate, and listen to where the pain points are. By listen, I mean REALLY LISTEN.

3. Become an expert in the manifesto and principals. Embody them. Sign the document.

4. Learn expert skills in teaching and coaching. Remember the foundation of the house of lean – leaders are not managers, they are teachers.

5. Understand what value is. I mean REALLY understand it. How is the PMO contributing to the bottom line? PMO purists love EVM, figure out how to apply it to your own world!

The bottom line is this: We do not want to run from the PMO. We do not want to resist the PMO. In fact, we need the support of the PMO!

Please help us, to help you, help us.

Scope & Expectations Management in Agile

Definition of DoneOne of the biggest complaints and frustrations from new Agile practitioners is, “We don’t know when we’re done!” That’s not an uncommon situation to be in if the organization falls on the side of purely self-organization. However, transparency and higher levels of customer satisfaction are two key benefits of adopting Agile practices. Achieving these benefits takes a high level of discipline and the right patterns for collaboration and engagement.

Join us on Thursday, November 6th at 12:00 PM ET for this month’s #BecomingAgile Webinar, where one of our Managing Directors, Leslie Morse, will walk us through 4 key practices that will help ensure you’re able to effectively manage stakeholder expectations and properly communicate about what teams can deliver when.  These are:

  1. Define Scope leveraging KANO analysis
  2. Project delivery dates using a Release Burn-Up Chart
  3. Track incremental delivery with Feature Burn-Up Charts
  4. Analyze Trade-Offs with a Tactile Release Plan

Sign up now!

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