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.

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

Managing Your Planning Debt: Time to Cut the Credit Cards

Your team is in the middle of a sprint, they’re super-motivated to get as many stories done as possible, and it looks like they’ll be cutting it close on time. They’re an awesome team; they’ve learned not to skimp on testing or quality to “complete” more work. They’ve come up with a solution to make more time that doesn’t involve skimping on quality: “Let’s skip our Story Refinement session this sprint!”

No. Absolutely not. A goal of every sprint should be not only to finish the stories accepted into the sprint, but to reserve enough capacity to enable the successful planning and completion of work in future sprints. If a team leaves a sprint unprepared for the next sprint, then it shouldn’t be considered a successful sprint. A team that is managing their backlog well should be keeping 1-2 sprints worth of stories that meet their Definition of Ready (DoR) in the backlog at any given time.


Planning Debt is Like Credit Card Debt

  1. Credit Card: First, you spend a bit more than your monthly budget and leave a small balance on a card because the 20% interest is “just a few dollars” of interest.

Planning Debt: This is the team’s first impulse to just skip Story Refinement. In that sprint, it doesn’t seem to have a huge impact on the team’s ability to deliver.

  1.  CC: Then, you find that you can’t pay off the full credit card balance the next month because you’ve spent your usual budget and there’s still that overspend from the prior month with the little bit of interest. You’ve found that this hasn’t bankrupted you and you don’t feel the pressure of mounting debt, so you overspend again because it’s only a little more and it feels good to have what you want to buy now.

The team dips into their DoR story savings when they don’t have enough stories “Ready” for the next sprint. They spend more time in
Sprint Planning, because they’re really doing Story Refinement. They reach mental exhaustion during a lengthy Sprint Planning session and miss key details or tasks.

Then they get into sprint execution and find that – due to their poor planning caused by dipping into their DoR story savings – they’re even further behind than prior sprints, and now they definitely don’t have time to do Story Refinement if they’re going to get their work done.

  1. CC: Finally, you’ve “just-a-few-dollars” reasoned your way into thousands of dollars in debt and all you can afford to do is pay the interest each month without making a dent in the interest. At that point, the next purchase creates interest charges you can’t pay each month and your balance grows until you’re bankrupt.

PD: Eventually, if you’re lucky, someone has the epiphany that if the team doesn’t stop all new work and just sit down to do some planning to build some DoR story savings back up, they’re going to continue on the downward spiral. The team needs half a sprint or a full sprint to do nothing but planning.

The Solution

Consider me the Dave Ramsey of Planning Debt. It’s time to cut up the credit cards and only pay for what you can buy in cash. Set a budget and stick to it. If your team budgets for a certain amount of Ready story “savings” in their backlog each sprint and they want to cancel Story Refinement to get more work done, don’t give them access to the credit cards: especially new teams. Perhaps an experienced team could manage their debt wisely, but an experienced team won’t want the credit cards because they understand the value of paying in cash and having some savings for a rainy day.

Skipping planning activities because “we get more value out of developers writing code” will lead to developers having nothing to code. Either you pay today or you pay tomorrow, and if you pay tomorrow, you pay it with interest.

Print pagePDF page

A Webinar on Readiness

Join Leslie Morse next week for our November 2015 #BecomingAgile Webinar Series event, “Definition of Ready” .

Screen Shot 2015-10-29 at 6.33.04 PM
Struggling to maximize the agility of your teams, and increase quality and clarity of your Release Plans? If so, you should join us for 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.
  • Remember, the #BecomingAgile Webinars are worth 1 PDU and the last 15 minutes are reserved for open Q&A. It’s the perfect time to get input and expertise from one of our Agile coaches!

We hope you come an join us:

WHAT:     #BecomingAgile Webinar Series, Definition of Ready

WHEN:     Tuesday, November 17, 12:00pm ET

WHERE:    GoToMeeting Webinar

Register Now!

Print pagePDF page

5 Criteria for Starting a Team


Ever experienced some significantly challenging rough patches when starting an Agile team/Agile project? If so, you may have violated one of these 5 Organizational Readiness Criteria for Starting an Agile Team. Please note, these criteria are in context of an organization that is new to a Lean|Agile approach for delivering value, or one that has not yet implemented a model like Scaled Agile Framework® (SAFe®)  or some other approach for enterprise agility. Why? Because if you’re already using SAFe or some other framework, there are readiness criteria tailored to each of those approaches.


5 Organizational Readiness Criteria for Starting an Agile Team

  1. Vision is Understood
  2. Success Measures are Defined
  3. Product Owner is Prepared
  4. Funding is Secured
  5. Your Team Members are Available

Start When it is Time to Start

Please, I plead, prevent a failure to launch. Do your best to to follow these guidelines before engaging an Agile team, it will help your organization set teams up for early success.

  • Vision is Understood
    Are you working on the right thing? Do you understand what you’re asking for? Far too often, organizations approve “any ol’ good idea” without having done due diligence to ensure teams are working on the highest value. Before sending an Agile team off for incremental delivery ensure there is collective shared understanding of the vision by Sr. Leaders & Sponsors that are funding and supporting the initiative.
  • Success Measures are Defined
    Another aspect of understanding a vision is defining how you will measure whether or not it delivers the expected results. Having these upfront ensure that the vision has a potential ROI, but also help to “gamify” the initiative for the team.  Challenge them to find ways to meet and exceed the measurable objectives.
  • Product Owner is Prepared
    We often use a boat analogy to describe the relationship between team roles. (Imagine one of the old boat with rowers sitting in the hull, and a captain up top steering the vessel.) The Agile team members are the rowers. The engine that powers the delivery of value. The ScrumMaster is the coach (or more formally, the cockswain) chanting, “row, row, row,” and the Product Owner is at the helm setting the course and direction for the voyage. Not much would be worse than embarking on a quest when the Captain is not ready to steer the ship. Think about these three guidelines when ensuring a PO is prepared.
    • Available – He or She must be AVAILABLE to engage with the team. Every day the team is waiting on a PO for clarification, they run the risk of building the wrong thing.
    • Knowledgeable – Does the PO have the heartbeat of the vision? This person is the single source of truth about ‘what’ the team should build. If you feel like you’re in a hard place about the PO’s knowledge, it’s OK; if you start with AVAILABLE, then he or she will acquire the knowledge in no time.
    • Empowered – This may be a challenge if the person has a gap in knowledge, but over time as knowledge is gained the PO will earn trust and then empowerment to make decisions on shaping the vision and maximizing value delivered to the customer.
  • Funding is Secured
    Once or twice I’ve seen organizations try to jump-start teams before funding is secured. In many organizations this results in early enthusiasm followed by a dramatic screeching halt. If you haven’t had a chance to adopt a model for “funding teams” versus “funding work,” please be patient and wait for funding to be approved before you get going. While you’re waiting, consider reading Implementing Beyond Budgeting: Unlocking the Performance Potential
  • Team Members are Available
    Similar to staring without a budget ready to go, I’ve seen organizations try to get a team going without all the team members there. “Oh, we have a Product Owner, tech lead, and business analyst. The rest of the people will be showing up over the next several weeks.” (maybe months.) This is classic when you hire people (contractors) upon funding approval. The success of teams, and all planning that surrounds the 5 Levels of Planning we’re talking about here, are about cultivating SHARED UNDERSTANDING. If you piecemeal the team together over time, you elongate the j-curve for an unnecessary amount of time and find that the re-learning and re-work from constant personnel causes things to take longer than they would have if you would have just waiting for everyone to be there before starting.

I hope this brief checklist stimulates a conversation about readiness at your organization, and if you’ve got other ideas you want to share, please comment on this post. I’d love to start a conversation!

Good luck #BecomingAgile!

PS – The criteria in this post are directly from a slide in my Analysis Across 5 Levels of Agile Planning talk offered at dsmAgile on 9/25/15 and at Southern Fried Agile on 10/15/15. You can learn more about the details of the presentation by reviewing the posts summarizing the conferences.


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

Print pagePDF page

30|60|90 Days to Testing Automation, pt. 3

Thanks for returning to catch part 3 of this series. If you didn’t get a chance to read the previous 2 posts, check them out now:

Within this post we will explore details behind the second 30 days of the plan, before we get into those details, here is the overall plan once again. Think of it as a check-list of spikes, foundation stories & new tasks your team needs to account for during backlog refinement & sprint planning.




  • Select an Acceptance Test Tool
  • Create a Test Repository
  • Task-out Automation of Acceptance Scenarios
  • Begin Local Box Automation
  • Begin Consistent Unit Testing
  • Introduce Scenario Analysis during Refinement
  • Define a Clean Test Environment
  • Write a Script to Trigger Tests on Build of the Code
  • Automating Reporting of Pass/Fail
  • Require Locally-Passing Unit Tests
  • Use Acceptance Tests to Elaborate Acceptance Criteria
  • Unit Test all Components
  • Implement an Automated Build Schedule
  • Update the Definition of Done..
Automation on
Local Boxes
Automation in the Test Environment Initial levels of
Continuous Integration

Days 31-60

The set of items focused on in this batch are focused on helping the team push all of their work to a central test environment and initiate automation within that shared workspace.

Start Scenario Analysis in Refinement SessionsWhat is your story- shutterstock_91133444
There is a robbing Peter to pay Paul situation that occurs with Backlog Refinement. The more you invest in refining stories, the less time you’re focused on the sprint tasks at hand. However, by incorporating scenario analysis into your library of techniques for refinement workshops you’re able to get a jump-start on automation. Defining scenarios just ahead of the sprint where the work is occurring allows the PO to be thoughtful and fully vet that you’re looking at the right scenarios. It also enables you to begin automation earlier in the sprint this incorporating beginning ideas of Behavior-Driven Development, Acceptance-Test-Driven Development and basic Test-Driven Development.

Define a Clean Test Environment
Testing automation practices become vastly more complicated when you do not have a clean and consistent environment for running tests. “A large part of making tests repeatable and robust is ensuring that the test fixture is torn down after each test. Leftover objects and database records, open files and connections can at best cause performance degradations and at worst cause tests to fail or systems to crash.1” By collectively agreeing to a definition for a clean test environment you have a common definition for all team members to use when writing and automating tests.  Taking time to have commonality across multiple teams working on the same platform will enable the tests to scale and be reusable across multiple environments.

Write a Script to Trigger Tests on Build of the Code
Save your team one additional step of the process. Automate the execution of automated tests. Every team starts in the same place. Create a build of the code, then trigger tests to run. But, that is a repeatable step you have to do on every single build. Instead of spending a few precious moments on a redundant task, take the time to write a script that automatically triggers the tests to run every time there is a build of the code.

Automated Reporting of Pass/Fail
This is all about fast feedback. Whether it’s an e-mail, desktop notification, or a loud buzzer – make sure the team knows the results of the tests. The faster you get the feedback, the sooner you can resolve defects. Team members should not need to hunt and find the results of the tests.

Require Locally-Passing Unit Tests
This is a first step towards gated check-ins. Modify your team working agreements as well as Definition of Done to require that team members 1st pass all unit test locally before checking into the shared test environment. This forces you to start building quality in from the very beginning of the process and reduces the costs of defect remediation over the long-haul of the initiative.


Almost done…

This series is almost done. Come back next week and look for part 4 that uncovers extra detail behind the last segment of the plan! 


Upcoming Webinar Opportunity

If you are struggling to maximize the agility of your teams and increase the quality and clarity of your release plans, be sure to register for our “Definition of Ready” webinar that is taking place on November 17th.



Print pagePDF page