The #BecomingAgile Blog will be Moving to

As part of our exciting transition to the new SolutionsIQ, we will begin cross-posting our #BecomingAgile blog content on starting the week of 11/30/2015. And don’t worry, all the content you’ve grown to love here on the Davisbase site will be migrated over so you don’t lose anything.

We’re thrilled that the breadth and expertise of authors will be growing as the Davisbase and SolutionsIQ teams merge. Look for many great things to come over the next several months!

Print pagePDF page

Agenda and Ideas


Retrospectives can easily devolve into chaotic gripe sessions or dull affairs with low participation unless they are well-planned and executed. At each extreme, the meeting suffers from poor facilitation, which hurts morale and makes it difficult to generate concrete action items. To steer the meeting toward successful outcomes, the Scrum Master has a full set of meeting facilitation tools at his or her disposal.

One such tool is the Retrospective agenda, which is a time-boxed outline that serves as the template for the meeting’s activities. It ensures that the Retrospective progresses in a logical, step-wise fashion. With a thoughtfully crafted agenda in hand, the Scrum Master can lead the team from behind to its own fresh and actionable insights, while ensuring it doesn’t go off course into unproductive territory.

Below, we’ll look at various activity types that comprise an effective agenda. Each generates specific outcomes; in combination, they lead to agreement on actionable improvements. Within each type, you can select from an array of popular and tested activities. This allows you to keep your meetings fresh and get your participants to think outside the box. Note that your agenda is filled with “activities” rather than “discussions.” Activities can and do lead to discussions, but they can generate more personal and unexpected insights than asking the three Retrospective questions directly, sprint after sprint.

The following is a recommended agenda for a 1 hour Retrospective. There are different formulas out there for retrospective time per weeks in the sprint. 1 hour to 1-1/2 hours for a 2-week sprint should serve quite well. If you engage your soft skills of scanning the room and leading from behind, you’ll be able to judge what’s best for your team. If the activities are tightly run without rambling discussions, 1 hour should work fine for a standard team of 6-9 members. You’ll get better results if you keep things fairly fast paced, so lean towards a shorter versus a longer meeting and keep things moving. Your team will thank you for getting to a quick conclusion.



Getting people into the same room doesn’t constitute a meeting if you’ve co-located their bodies without co-locating their minds. As stated earlier, you are essentially architecting a network of complex hardware (brains) and software (personalities). Check-in activities boot that system up. Minds tend to wander, especially among high performing individuals who obsessively multitask. Even though electronics may be put away, you can be sure someone is working out a line of code or writing an e-mail or grocery list in their head. Your check-in activity will break these pre-meeting thought strings and get all those minds co-located and ready to collaborate.

Another function of check-ins is to establish an upbeat, friendly, and dare I say, FUN, atmosphere. We want to shake off any self-consciousness, hesitation, or insecurity. We want to open up the flood gates of free, honest, and creative contributions. Seriousness puts a damper on participation, as people tend to censor themselves and share only the most carefully considered, “right” answers. When it comes to brainstorming, we want all ideas on the table without prejudice. This is easiest when people are in a somewhat playful, unrestrained mood. So we have a two-fold purpose for our check-in: 1) clear away distracting concerns; 2) set an upbeat and collaborative tone.

Here are just a few activities to choose from:


Mind Dump

A very direct way to defuse external distractions is the “Mind Dump.” Each participant has two large sticky notes. On one, they write what they were doing before the meeting; on the other, they write what they’ll be doing immediately after the meeting. They post these on a white board or wall under the labels “Before” and “After.” The Scrum Master reads each list, asking, “Is there anything here that can’t wait?” or “Is there something here that you need help with?” Any such wording will work. The goal is to identify and quell any potential distractions.


Identification Exercises

These allow people to reveal something unique about themselves to each other. Some options include: “Which super hero or movie character would you like to be, and why?” “If we could hold this meeting in the place of your choice, where would we be, and why?” “What’s the best thing that happened last weekend?” You can ask any open-ended question which reveals personal preferences. The goal is to help team members relate to each other and set the stage for uninhibited collaboration.


Improv Exercises

Various improvisation exercises can be used to get people interacting. In “What’s in my Box?” team members pair up, with one partner holding an imaginary box. The other partner mimes removing items from the box and announces what they are. “Here’s a nice chocolate cake.” To which the partner replies, “Yes, that’s a nice chocolate cake.” This continues for two minutes and then the partners reverse roles. Yes, this is silly! That’s the point. In the Retrospective they may be confronting sensitive issues. The purpose of this check-in is to encourage freedom of expression and empathetic listening. Participants will sometimes pull strange items like airplanes, planets, or dinosaurs from their boxes, but the only acceptable response is, “That’s a nice ________.”

Check-ins may be light-hearted, but they’re not lightweight. As long as humans are involved, there will be underlying inhibitions and distractions that impede free and productive brainstorming sessions. Once those are addressed, people will lower their guards and contribute more openly and honestly. The check-in sets the stage for the upcoming more serious swork.


HARD DATA REVIEW (5 minutes)

In the Retrospective, you want to elicit personal reflections on how the sprint went and get unique insights on what can be improved. First, you must be sure everyone is looking at the same sprint. Presenting hard sprint data for group review narrows their focus to the facts at hand. Clear and easily digested charts should be visible to all in the room. A dashboard view of the sprint should include your burndown, defect counts, stories completed, stories deferred, outcomes of any critical meetings, sprint impacting events, etc. The raw data is presented objectively and free from any interpretation by the Scrum Master, the Product Owner, or any other team member. There are no “good” or “bad” facts here; there are only facts


Have the team look, but don’t allow any discussions just yet. You want them to absorb the information, process it individually, and stir up their own personal opinions about what to do better in the next sprint. Because group discussions can get quite unwieldy and unproductive, Scrum best practices tend to favor silent brainstorming, using a highly sophisticated information management tool – the Post-it note!


ELICITING (10 minutes)

Once your team has been allowed to reflect on the simple, mathematical facts of the sprint, you will want to elicit their feedback as to what went well, what didn’t go so well, and what could be done better. The most straightforward way to do this is to hand each member a small pad of 3X5 inch Post-it notes and a fine-tipped marker. Have them answer each question as many times as they wish, putting each brief response on a separate note. They will stick them to a prepared white board or wall with a column set up for each question: What did we do well? What didn’t we do so well? What could we do better?

In time, you may want to vary the elicitation activity to keep things interesting and encourage fresh perspectives. For example, the “Speedboat Retrospective” uses the metaphor of a speedboat for the sprint and elicits replies to four boating-inspired questions: 1) What propels us forward? (represented by an outboard motor); 2) What slows us down? (represented by an anchor); 3) Where do we crash? (represented by rocks); and 4) What rescues us? (represented by a life preserver). The scrum master sets these four quadrants up on a wall or white board, with images of the four icons (motor, anchor, rocks, and life preserver) as headers. Participants attach their notes in the appropriate quadrants.

Another fairly flexible template I created is what I call the “Wheel of Fortune.” I draw a large, six-sectioned pie chart with 3 pairs of opposite categories, for example: fast/slow, easy/hard, clear/unclear; or won/lost, coordinated/uncoordinated, continue/stop. Partner categories are located opposite each other to keep the concepts clear and simplify posting. The key is to keep the categories as general as possible, so as not to limit potential responses.

Varying your elicitation exercise will keep the team on their toes and lead them towards less obvious problems and solutions. They may come into the meeting armed with pre-conceived answers to the three basic questions, but if you stir things up with unusual or unexpected questions you’re likely to generate some fresh ideas. The key here is to elicit a wide range of responses. They will be organized into manageable groups after they surface.


GROUPING (10 minutes)

Once you’ve captured these impressions, you can start grouping identical, similar, or related responses. Identical, or very similar, responses can be placed over each other; related responses can be placed near each other, and unrelated responses should be kept apart. This first phase of grouping can be done as the scrum master reads out the responses in a particular section, identifies similarities, and asks the team if particular items should be grouped together. Alternatively, the team can gather around the board and group items themselves, with minimal discussion for clarification and consensus only. When replies are grouped, the Scrum Master or another team member should write a summary statement on a new Post-it and place it over the group. Once the notes are grouped they can be sorted in the next activity.


SORTING (10 minutes)

Once you’ve grouped your Post-its to eliminate redundancies and show dependencies, you can sort them into action oriented categories to identify potential action items. A fairly simple and robust framework is Stop, Continue, and Start. Work with the team to identify which notes represent practices which should be stopped, continued, or started, or let them sort amongst themselves. For example, un-productive activities would be placed under a “Stop” heading. Items that call for new and better ways to do things would be placed under “Start.” Successful actions would be placed under “Continue” to ensure they’re not forgotten. Moving notes from the previous activities into these three categories is a precursor to creating concrete action items with assigned owners. Not all of them could or should be moved. The idea of this sorting activity is to deliberately slow down the thinking process. The team isn’t deciding what to do yet; it’s only considering what it might do (stop, start, or continue something) to address an issue. In the final activity, the team will choose action items from this pre-sorted list.


ACTION ITEMS (10-15 minutes)

The team has already narrowed down its improvement candidates with the Stop-Start-Continue list, now they can decide which items to commit to. This is an activity where group discussion is most likely to be manageable and productive, since the scope of that discussion is fairly limited.  As consensus builds around particular items, they are moved to an “Action Items” list, but that shouldn’t happen unless someone steps up as the “owner.” The owner drives and monitors progress. He or she may contribute directly, may coordinate the contributions of others, or may do both, but regardless, that person will spearhead the effort and drive it to conclusion. This is an area where volunteerism is your best friend. Unless someone is motivated to drive results, an action item is useless.  So, it is okay if “more important” items aren’t taken up because no one steps up to own them. Without owners, they wouldn’t be completed anyway. It’s far better to complete lesser initiatives than to do nothing about the more important ones. The only criteria that matter are group consensus and individual ownership.

It’s the Scrum Master’s responsibility to record and disseminate these improvement items so that they’re not forgotten, remove impediments and ensure that progress is reported to the team. Some teams place these improvement items in their sprint backlog to give high visibility. The daily scrum is an opportunity to report progress; the team can also utilize team discussion pages, posters, email/chat communication, etc., to get the word out on any behavioral changes needed to support the action items.



In the Retrospective, we’re not just dealing with simple facts and computations; we’re dealing with human beings in all their complexity. We are consulting them individually and collectively to elicit their insights on what they might do better. There are no obviously right or wrong answers, there are only recommendations that are implemented and tested.

It takes good planning and execution to have a successful Retrospective.  An agenda of activities safeguards the team from distractions, diversions, and divisions.  As the team moves through a logical progression of activities, they are led to individual insights and group consensus on improvement opportunities.



The Agile mantra, “Inspect and Adapt” is realized in the Sprint Retrospective. High performing teams are always reaching for the next level of excellence. The Retrospective exposes strengths, weaknesses, and opportunities for improvement. Some call these “improvement experiments” or “hypotheses,” since there are no guarantees they’ll have the desired impact. That may be so, but as long as intelligent and deliberate effort is made, and as long as the team continues to course correct and explore new opportunities with each Retrospective, overall improvement is inevitable as successful new practices are adopted and detrimental practices are eliminated.

Print pagePDF page

Kaizen Your Vocabulary

The words we choose carry more weight than we really know. The connotation of many words in American-English-Business vocabulary unfortunately carry a tone of command-and-control, dehumanization, and to some extent – violence.

Non-Violent Communication

“Violent” versus “Nonviolent” communication is a real thing.

Read More about It

As we prepare to enter the new year, take a moment to reflect on the vernacular you, your team, and you overall organization use on a day-in-day-out basis.  What one (or several) good changes can you make to ensure you cultivate a safe and motivating environment for all knowledge workers?

Try these suggestions to get things going:

  • Resources
    Human are not endlessly replicable widgets that organizations can buy more of. Please don’t call people resources. As our late leader Bill Gaiennie said, “How would it end up if you went home to a significant other and called them a resource?”
  • Methodology (when used in reference to “what Agile is”)
    Agile is NOT a methodology. Agile IS a philosophy for how we as humans get knowledge work done. It is the word used to summarize a set of values and principles that drive the way we work together. There are many methodologies, frameworks, and processes that are in alignment with Agile values & principles. But Agile, by itself, is NOT a methodology.
  • Utilization
    This relates to the idea of resources. Yes, inanimate objects that are capable of getting work done can be fully utilized, space can be well utilized, but people – should not be FULLY utilized. In fact, don’t even talk about humans in terms of utilization. Slack (spare time) is necessary for creativity, problem solving and innovation. All key aspects of a Lean|Agile enterprise.
  • But (or “Yes, but”)
    While subtle, using the word “but” when responding to someone immediately shuts-down and negates most of what they said. Instead, practice “and.” You may have seen this in improv groups as an exercise, or done something like this in a team building event or communications workshop. When responding to someone, try “yes, and” to amplify the conversation and keep everyone engaged.

Here’s a Tip: Create a wall for people to post anti-Agile words for everyone to see. Crowdsource prioritization, and make a monthly commitment to removing 1 word from your team’s vocabulary. (Always be sure to talk about the why.)

Happy Holidays, have a great December!

Print pagePDF page

Tips on Facilitation

Sprint Retrospectives are a Scrum activity which supports continuous team improvement. In the Retrospective, the development team reviews the recently completed sprint and generates ideas to improve future performance (code quality, test automation, work assignment, environments, external coordination, etc). Anything the team wishes to improve upon is appropriate provided they have bandwidth and consensus.

Leading a team to consensus is the job of the scrum master. In theory, getting a team to answer the basic retrospective questions, “What did we do well?” “What didn’t we do well?” and “What can we do better?” should be fairly straightforward. In practice, getting high-quality participation and managing diverse opinions requires leadership skills which go beyond knowing the basics of Scrum.


So-called “soft” skills and “hard” skills are two contributors that lead to successful retrospectives. Hard skills are concrete techniques derived from the field of meeting facilitation and, in particular, how to run brainstorming sessions. Getting the most out of these activities depends on certain intangibles which fall under the category of soft skills, or social competencies. We’ll explore the topic of soft skills first, with a follow up post on the hard skills of crafting well-structured retrospective agendas.

BUILDING RELATIONSHIPSshutterstock_129083750

To lead a team on the retrospective journey, a scrum master must create a safe, positive environment where the team can openly discuss weaknesses and failures without blame, excuses, or embarrassment. Building trusting relationships and setting a friendly, cooperative tone begins outside the retrospective as the scrum master interacts with teammates: coaching, removing impediments, engaging in small talk, etc. Building rapport and maintaining a history of pleasant interactions will encourage cooperation and prevent misunderstandings or animosity should the scrum master need to redirect discussions or “correct” non-optimal behavior.

Demonstrating that you value your teammates is a professional, peer-leadership tactic that may require conscious application (“…value individuals and interactions over processes and tools…” Agile Manifesto). If relationship management isn’t part of your natural skill set consult with a mentor, model yourself after someone who led you well, or seek out programs such as Toastmasters or Dale Carnegie. The scrum master must earn the team’s trust in order to set the stage for full and open participation; consequently, the Retrospective will be more of a conversation among friends than a formal meeting with tentative participation.


The expression, “leading from behind” may sum up the attitude and actions of the scrum master, particularly when running retrospectives. Although leading from behind seems counter-intuitive, with this concept you actually lead by following. To clarify, here’s an example from sports coaching. A coach can only work with what the team has to offer. A good coach carefully observes the team, noting their current capabilities. With those strengths and weaknesses in mind, the coach leads the team from behind by anticipating the next steps for development and ensuring the team progresses.

In the Retrospective, the scrum master leads from behind by actively observing the meeting’s progress and intervening to keeping it on course. Here’s an area where the Agile principle of inspecting and adapting is relevant: At times the scrum master should be active by clearing communication jams, keeping activities on schedule, etc., and at other times the scrum master should step back and let the team hash things out without interruption. In either case, the scrum master gauges progress “from behind” and intervenes only as needed. Interventions are often as simple as giving time checks, explaining activities, ensuring all perspectives are captured, driving consensus, etc.

Leading the team from behind allows them to freely explore their own insights in a well-managed environment. The team provides the meeting content and the scrum master establishes and protects the meeting structure.


Effective trainers and facilitators continually “scan the room” to observe and assess participation and comprehension. In the Retrospective, the scrum master should observe body language indicating energy, mood, engagement, disagreement, etc., and respond appropriately.

By scanning the room and making deliberate, but friendly, eye contact with all participants, the scrum master establishes soft control and the team senses that the scrum master is addressing them personally.

Beware of getting distracted by the meeting’s content, especially if you have expertise or interest in a particular topic. Discipline yourself to continue scanning the room and gauging progress. If the scrum master becomes a participant, no one will be “watching the hen house” and the meeting can quickly go off course. (In the rare event that the scrum master’s contribution is critical to a solution, excuse yourself temporarily from the facilitation role and hand it over to another team member while you participate. They should watch the time and referee the meeting until you take it back.)


We shouldn’t confuse leading from behind with not leading at all. As you scan the room, respond to what you observe. Don’t hold back from guiding or correcting behavior for fear of offending. As long as your goal is to help the team have a successful Retrospective, they’ll accept your leadership and thank you for keeping the meeting productive.

For example, the scrum master should remind the team of good practices, particularly if things appear to be going off the rails. This is much easier to do if those practices are agreed to beforehand and reiterated at the start of the meeting. Basic courtesies such as not interrupting the speaker, putting away cell phones and laptops, not criticizing teammates, not engaging in side conversations, etc., can be captured in a team agreements document for reference.

Enforcing good participation requires tact and respect for the “offender.” Start with the premise that people are basically good, if somewhat careless in their social manners. The respect the scrum master shows to each team member will make him or her more amenable to correction, particularly if seen as a trusted peer-leader. Don’t underestimate people’s social intuition; they’ll know if the respect is absent, so reboot your own attitude as needed.

It is within the scrum master’s role to maintain full, quality participation, so don’t stand back and allow participants to derail the meeting by going off-topic or off-agenda. Actively orchestrate participation with reference to the agenda, recommended practices, and team agreements. Be assertive, but respectful, and the team will appreciate your leadership.


While social capabilities are invariably labeled as “soft” skills, they are quite solid when it comes to scrum mastering and, in particular, running retrospectives. You are essentially architecting a network of complex hardware (brains) and software (personalities) to generate, evaluate, and act on objective and subjective data. Getting optimum, coordinated performance from the team takes skill. Among your tools are: building relationships, leading from behind, scanning the room, and addressing non-optimal behaviors. These will support the post coming soon on  facilitation techniques.


Make sure you check out our Reference Guides on Retrospectives

  1. Coaching Guide – Retrospectives
  2. Coaching Worksheet – Basic Retrospective
  3. Coaching Worksheet – Quick Retrospective

Also feel free to checkout our webinar on Retrospectives from earlier this year.

Print pagePDF page

The Next Era for Davisbase Consulting

Learn More

Check out the press release announcing the combination of SolutionsIQ & Davisbase Consulting.

Read Press Release

It is an important day in the history of Davisbase Consulting. We are excited to let you know that as of today, we are joining the premier Agile Transformation and Management Consultancy, SolutionsIQ. This combined entity will create the richest and most expansive pattern library for how to increase business, organization, and delivery agility in Fortune 1000 organizations.

As a #BecomingAgile reader, you’ve probably got questions about what this means for the knowledge, resources, and guides you find here on We’ve done our best to summarize some of the key changes, and will continue to update the blog with pertinent details as they become available. For now, we invite you to visit to learn more about the combination of our firms.


#BecomingAgile Communications

The Blog
Starting this week we will begin co-posting content on both the #BecomingAgile blog as well as on the SolutionsIQ site ( Our authors will start posting content there consistently in 2016.

The Webinar Series
The December #BecomingAgile Webinar, A Kaizen Culture, will still run on Tuesday, December 8th at 12:00ET (Register Now). Starting in January, we will transition the Webinar series to the SolutionsIQ site. Be sure to register for our newsletter to get all of the updates on future Webinar events.

The Newsletter
We will continue the #BecomingAgile newsletter through December and begin assisting each subscriber with migrating to the SolutionsIQ distribution list early next year.

The Tool-Kit & Resources
These will stay right where they are at, over time you’ll notice the links start redirecting to the SolutionsIQ site.


Now you can be #AGILEAMPED!

Excitement is going to increase as well, because SolutionsIQ regularly publishes an Agile Amped podcast featuring SolutionsIQ coaches, trainers, and other industry experts. Dig in, dive deep. Check out Agile Amped now!


Thanks for your loyalty & engagement over the years, we’re excited to bring you along on the journey!

Print pagePDF page

The Pie of Life

Pie-SliceI love pie. A lot. So when November rolls around, I get really excited for the winter holiday season (read: pie season). Time with family and friends, days away from work, delicious food, beautiful decorations – all these aspects of the holidays are amazing, but the pie is one of my favorite parts. It’s safe to say, I’m thankful for pie.

This week I started thinking about why I have this obsession with pie. Here is what I figure: Pie has a delicious flaky crust that, if made correctly, melts in your mouth. Then you have the filling that can be a variety of fruity, chocolaty, or tart flavors. Finally, you have the whipped cream, the meringue, or even a drizzle of chocolate syrup to top it off. What’s not to love about this?

As I was thinking about why I love pie so much, I realized that pie can be directly compared to life. Let’s talk about the Pie of Life:


Every amazing pie needs some sort of crust. It’s the crust that holds the filling in and provides the foundation to the pie. Much like pie crust, we all need a foundation in our life to feel grounded and secure. We create this foundation from various aspects of our life – friends and family, faith/religion, a fulfilling job, love, a sense of belonging, etc. The ingredients that make up the foundation will likely be different for each person, but ultimately this foundation holds together the Pie of Life. What ingredients make up your pie crust?


Now we come to the filling, which is the main portion of the pie. I have learned that even when you have a sweet pie filling, a little salt needs to be added to offset the sweet. Anything that is overly one flavor is boring and bland; when the sweet is balanced with salty, sour, or bitter flavor it adds interest. Isn’t life like this, too?

Our daily lives are all full of sweet and challenging moments, but both are necessary to fully experience life. The Classical violinist Isaac Stern sums it up nicely, “It is only through failure and through experiment that we learn and grow.” As much as we only want those happy and easy moments, the challenging, sad, and frustrating experiences in life are also necessary for our development.


Eating PieCan a pie be delicious without the whipped cream (or other) topping? I believe the answer is yes. There are times I’m perfectly fine eating pie without a topping, and there are other times I feel it’s necessary. However, in certain situations (for example, a lemon meringue pie) is the pie better with the topping? Again, I believe the answer is yes. There are certain areas in life where the little “extras” really add flavor to the Pie of Life. Some examples of these toppings are: providing service, enjoying hobbies, developing talents, exploring, etc. Without these experiences can we survive? Yes, we can; however, these toppings often add variety and additional fulfillment to our Pie of Life.


I am thankful for all the ingredients that make up my Pie of Life: the foundation of my family, friends, and faith; the filling of both sweet and salty moments; and the toppings that add interest and variety. So join me and lift your fork to pie – both in the literal and the symbolic sense. Take a moment and think about your Pie of Life and give thanks for all of your pie’s ingredients. From everyone here at Davisbase – Happy Thanksgiving!

Print pagePDF page

Don’t Listen to Your Customers: Fix Their Problems

Amazing Product Managers and Product Owners (“PMs” and “POs”, respectively) are more than just people who have a vision for their products and have a pulse on the latest technology so they can deliver the best products possible to their customers. Amazing Product Managers don’t just manage the product, they also manage their customers, internal and external.

While I could probably generate a list of core principles (on which I’d include things like honesty and transparency), my focus here is on three key activities that Product Managers and Product Owners must do to successfully manage their customers.

  1. Present a Clear Vision/Roadmap
  2. Deliver Valuable Features that Solve Customers’ Problems
  3. Tell Customers “No”

What I love about Agile methodologies is that they emphasize the above key activities, even though these are activities that PM/POs should be doing regardless of whether they are managing products using predictive or adaptive methods.

Present a Clear Vision/Roadmapfolding-map-360382_1920

This almost seems like a no-brainer.

In the past, when I wanted to present a roadmap to clients, my leadership had two objections: 1) they didn’t want our competitors to get ahold of it and know where we were going, and 2) they didn’t want to give our clients a roadmap that we likely wouldn’t hit anyway.

Competitors may get ahold of it…

In a waterfall world, where you plan for a year and produce 2-5 year roadmaps, it may be scary to give out your roadmap because a more (little “A”) agile competitor could come and eat your lunch. In an Agile world, your roadmap should be maybe 6 months out at best, and you should understand the features well enough to know you can actually deliver those features in 6 months. If a competitor gets their hands on that roadmap, does it really matter? You’ll have delivered it by the time they are able to plan and deliver that feature.

We won’t hit our roadmap and don’t want to fan the flames of wishful thinking…

I couldn’t agree more. You don’t want to set unrealistic expectations. But if you are basically admitting that you’re so unpredictable as a development team that you can’t present a roadmap with some reasonable degree of certainty that you’ll hit it, isn’t that the real problem? The focus should be on how to become so predictable that you can present your roadmap to your clients. Luckily, Agile methodologies have robust estimation techniques to help teams become more predictable in their delivery.

Deliver Valuable Features that Solve Customers’ Problems

Delivering your customers’ most needed features demonstrates they are important more powerfully than “listening to them.”

From time to time, depending on technical debt and how good the company has been historically at prioritizing features, it may be necessary to hold therapy sessions during which customers get to complain about all the things they don’t like or ask for things they’d really like to have. Those therapy sessions can be valuable, but actually delivering is how you demonstrate you’ve heard them.

If you deliver the defect fixes, minor enhancements, and new features that your customers truly value the most, you won’t need to tell them that you’re listening or hold meetings to listen to them as a demonstration of how much you care, because they’ll already know. They’ll already be happy. If they’re not, then you need to ask yourself how you can improve at delivering value: odds are in that case, you’re not really delivering the highest value items first.

The Weighted Shortest Job First (WSJF) method popularized by SAFe® is very effective at prioritizing features to maximize value delivery to your customers.

Tell Your Customers “No”

I gained the support of my customers when I was a PM because I actually said “No.”

The people who preceded me used to give squishy answers about delivery, and would say everything was a great suggestion that would be considered at some point. Their theory, I suppose, is that they didn’t want to say “no” to a customer; however, that behavior infuriated our customers because they were being told we were considering everything, yet we never delivered anything.

The truth is, saying every idea is a great idea that we’ll consider at some point is a lie. Every product has a giant backlog with new business features, architectural features, defect fixes, minor enhancements, etc. If every idea is added to the backlog, your backlog becomes a junk drawer. Realistically, the stuff at the bottom will never get done.

Be honest about that and say “No.”

Customers don’t want to be shined-on or glad-handled. They want honest answers. They may not agree, and they may temporarily be dissatisfied that you didn’t view their “want” as important enough to consider, but they’ll ultimately be glad they got a straight answer.

Nothing is more malignant to the satisfaction of your customers than constantly being “listened to” without anything changing. At some point, your customers will stop giving feedback because they know it’s not really going to change anything; rather, they’ll become cynical when they don’t feel valued. It’s insidious.

Remember: Your customers don’t get in a room to tell you about their problems because they need free therapy. They have jobs that require their attention and they would rather not spend time explaining their problems. The conversations are a means to an end. People don’t want to be heard; they want their problems fixed.

Print pagePDF page

Why Definition of Ready is Essential for Maximizing Your Agility

Struggling to maximize the agility of your teams, and increase quality and clarity of your Release Plans? If so, you should watch our 1 hour #BecomingAgile webinar, Definition of Ready. Just as it is important for an Agile Team to be “ready” to commit to a backlog item, It is critical for Product Owners & Product Managers to be “ready” to engage Agile teams.

During this 1-hour webinar we will explore:

  • Readiness criteria for each level of Agile Planning.
  • A stakeholder engagement model for getting proactive input.
  • A cadence for backlog refinement to keep team’s in a “ready” state.

Make sure you take a look at the questions that were asked during the live webinar session and see what Leslie had to say in response.

Print pagePDF page

Featured Coach: Bonnie Bennion

Here at Davisbase we believe that our strength lies in our people and it is our people that make it possible for us to develop teams that deliver value. Therefore, we have decided to focus on the people at Davisbase and what makes them so special.

How did you first becoming involved with Agile?20150724_122727

Once upon a time,I was a front-end developer who became frustrated with people promising deadlines.I experienced a lot of overtime and all-nighters. I figured there had to be a better way to collaborate on projects with clients and customers, so I switched my career into Project Management. After a few frustrating years trying to manage scope with heavy documentation, I was finally introduced to Agile by a CIO at a software company where I was employed. After a LOT of personal research and trial-and-error, I helped implement an Agile solution for the company which, consequently, helped the business make better decisions through daily interaction with IT peers and continuous delivery of valuable software.

What would your advice be to an organization just beginning their Agile journey?

Educate yourself, your teams, and your leadership. Help make sure people are trained so they have a good foundation prior to kicking off the Agile transformation. And then keep learning. Go to conferences, read blogs and articles, read books. The beauty with Agile and supporting frameworks is that you can tailor it to your organization’s needs. In order to do that, you need to know what your options are and potentially what has worked for other organizations. The learning never ends!

Which Agile or SAFe®principle are you most inspired by?

Often, I think people get caught up in the details of “how things are supposed to work,” sprint metrics, and other distractions. The bottom line is that “working software is the primary measure of progress.” What are teams doing to successfully deliver working software (with a preference to the shorter timescale)? Keep doing it! What may be inhibiting your teams? Do a retrospective on it and come up with solutions. But above all, focus on delivering working software to the customer (because working software makes customers happy!).
IMG_2300What is your passion?

My passion lies in the process of “creating.” I am completely passionate about creating a better working environment for the teams I coach and creating channels of communication that ultimately enrich working relationships. I enjoy seeing teams create (and continuously deliver) working software that contribute to business goals. This passion of “creating” actually originated from my interest in fine art painting. My ultimate passion is in creating paintings that tell a story or evoke a specific emotion; right now, my focus is on painting scenes that show people with “quiet strength.” Every weekend you will either find me painting at my easel or traveling to collect inspiration.

Print pagePDF page

Manage Your WIP or It Will Manage You

If you’re as ancient as me, you started your career in the pre-internet, pre-cell-phone, pre-email days before the world suffered from technology-induced ADD. In the height of the yuppie era, “multi-tasker” was a legitimate badge of honor, a resume buzzword that meant: “I am self-directed, possess cross-functional skills, and can manage multiple, parallel work streams.”  The key concept was manage: you actively prioritized your own work-in-progress (WIP) to support strategic objectives without your boss having to micro-manage you.

FireToday, with overlapping meetings and notifications constantly screaming for our attention on multiple devices and apps, multi-tasking isn’t something to be proud of.  It means incessant context shifting. We nibble at this, we peck at that, and we’re interrupted in the middle of something else.  It means “attending” two or more meetings simultaneously on multiple devices and saying, “Excuse me, can you repeat the question?” when we hear our name.

The Eisenhower Decision Matrix reinforces an unmistakable piece of common sense – manage your WIP or it will manage you. Dedicate enough time to Not-Urgent/Important issues to prevent them from flaring up into Urgent/Important fires. Eliminate Not-Urgent/Not-Important waste. Delay or delegate Urgent/Not-Important demands, which cause the most insidious distractions.

What does this mean in practical terms?  Here are some suggestions, in no particular order, to help you manage your own WIP:

  • IGNORE e-mails – Did that get your attention? Allow me to elaborate. If you’re in the middle of a meeting or a 20-minute work block (explained below) ignore e-mails, IMs, texts, etc.  Don’t let your work, your thoughts, your peace of mind be constantly interrupted. Respond to incoming communication in pre-determined time boxes that YOU control. Ask yourself, is there anything in a typical workday that can’t wait 20 minutes? After all, we’re developing software, not performing heart surgery.
  • Be In the Moment – The cerebral cortex is a SINGLE CORE processor. Its WIP limit is ONE cognitive task at a time. Let’s not kill processor performance with incessant context shifting. Instead, be in the moment by doing ONE thing at a time. If a task/activity is not important enough to get your full attention, it can wait.
  • Block your time – The minimum recommended time block for productive knowledge work is 20 minutes.  If you’re shifting context more frequently, you’re probably being interrupted by a lot of Urgent/Not-Important items like e-mails. Instead of being distracted by this background noise, stick to 20-minute task minimums and use separate, 20-minute blocks to bundle shorter administrative tasks like reading/responding to e-mail, entering time sheets, answering surveys, scheduling meetings, expense reporting, etc.
  • Decline Meetings – You can’t be everywhere hearing everything all the time. If you’re not a subject matter expert or a decision maker for a particular meeting, you’re probably not providing or receiving enough value for your time. Could that be why you’re multi-tasking in the background? Don’t you instinctively know that you’ve got more important things to do? But what if your name gets called?  What if something comes up that impacts you? See the next recommendation.
  • Demand and expect meeting agendas – You have a right to know when and if your active participation is required in a meeting. Ask the organizer to provide an agenda which clearly states the meeting’s purpose, topics, and key contributors. If it’s not obvious, find out what your role is before you accept the invitation. If you have no role, decline the meeting and ask for meeting notes instead. Read them during your admin time block, not as soon as your e-mail pings.
  • Use a personal Kanban – Identify your Important-Not-Urgent tasks and put them on a personal Kanban board. Kanban is Japanese for visual card and is a quick way to track work as it flows through the system. It helps you visually manage WIP, identifying bottlenecks and reordering priorities as needed. Using Post-it notes on your cubicle wall are high-tech enough. Track those tasks as they move through Not-Started, In-Progress, Impeded, and Completed.

Trivia question: Why do so many of these Lean productivity tools/practices use Japanese terms like kanban, gemba, muda, etc.? Answer: Because they come from Toyota Production System (TPS), which allowed Toyota, Honda, and Nissan to crush the U.S. auto industry in the 80’s by producing higher quality cars cheaper and faster. They even broke into the luxury market with Lexus, Acura, and Infinity, embarrassing Cadillac and Lincoln and giving BMW, Audi, and Mercedes a good scare. It took the U.S. industry nearly 20 years to apply TPS/Lean to it’s own manufacturing and product development and restore consumer confidence. Conclusion – this Lean stuff really works!


Print pagePDF page

Getting Straight Into SAFe

Coaching and mentoring can help organizations attempt to scale Agile adoptions and larger reengineering efforts with models like SAFe®. However, coaching and mentoring only work if people are open to learn, and if enterprises adopt Agile values and principles not only in their organizational structure and practices, but within their culture.

This will be part of a series on Agile, SAFe, and Lean adoptions in medium to large enterprises.  I will cover several topics. The first topic is ‘How will I know when we are ready to start?’

Steps for a Successful ART Implementation

The Scaled Agile Academy provides a set of preparation steps for organizations adopting the framework:

  1. Train your Lean-Agile Change Agents
  2. Train all Executives, Managers and Leaders
  3. Train Teams and Launch Agile Release Trains 
  4. Deliver Value


Seems pretty simple and straightforward, right? Sometimes a simple picture is harder to understand than one might think.  As a SAFe Program Consultant (SPC) I have launched many Agile Release Trains (ARTs) and gained experience avoiding the potential pitfalls of an initial launch. Let’s talk in detail about launching an ART and some of the points you might want to consider prior to the launch. I will discuss some high level work that your SPC will assist with and how they will help ‘prepare the battlefield.’ (My Senior Drill Instructor carved that into my vocabulary.)

A Larger Vision for SAFe

Implementing an ART is more than just aligning several Agile teams to a single purpose. In my experience, most ART launches are a combination of the following:

  • An attempt to leverage Agile on a large program
  • An attempt to implement a ‘buzzy’ buzzword: ‘Agile‘ or ‘SAFe’ or ‘Scaled Agile’
  • An attempt to fix/recover another Agile adoption

Here’s what implementing SAFe actually accomplishes, or more accurately what it touches: SAFe is a reengineering opportunity that touches every part of an organization and allows it to align its products and service delivery mechanisms to better align and deliver value to internal and external customers by applying lean principles.

There are several things to focus on here:

  1. SAFe touches every part of an organization: SAFe is best applied to an organization that recognizes that they do not need an incremental adjustment. Changing the way you fund your portfolio work, align your teams, and deliver solutions is not an incremental adjustment.
  2. SAFe allows the organization to align its products and service delivery mechanisms: Better alignment includes responding to change faster and delivering faster at portfolio-level value.  Today, most organizations have multiple programs and projects trying to align across work streams to add value at the portfolio level. According to the latest CHAOS report, that isn’t working too well!
  3. SAFe applies Lean Principles: Minimize waste, Create Better Flow, Deliver Value, Create Demand (see: Lean Product Development).

Preparation is Key

Now that we have some background, let’s talk about how to prepare the ART for success!

  • Review the Agile Release Train (ART) Preparation Checklistst.
    A couple of notes regarding this list: It is NOT exhaustive, but intended to make you think about what your goals and objectives are. It will help you align your goals and objectives to SAFe. Remember: the Framework is not a one size fits all. It is designed for you to use the foundational values and principles to maximize your organization’s value delivery.
  • If you have not done a preliminary assessment of what you are doing for the reengineering activity, get one done!
  • If you don’t already have an experienced SPC, hire one! Investing time and money in preparing for this effort should not be taken lightly. An experienced SPC will have launched as many as 20, 30 or even 100 ARTs. You can bet they have dealt with problems that will arise on your attempt to launch and can help you shape your plans with real world experiences!
  • Lastly, don’t ASSUME! Just because this makes sense to you, does NOT mean there is a common understanding with an ART of potentially 125 people. Communicate early, often, and on cadence.

Good luck!

In the next installment, we will do a deeper dive on some of the more challenging topics of the SAFe model and discuss some effective strategies for implementing reengineering efforts using SAFe.


Scaled Agile Framework® and SAFe® are trademarks of Scaled Agile, Inc

Print pagePDF page