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

Live Tweeting from Agile 2015

Agile2015 Live Tweet Image

Unable to attend Agile2015? Don’t worry, we’ve got you covered. Below is a list of our 6 team members who will be live tweeting the event, we have also created a list called “Agile2015″.

All of our tweets will have the hashtag #Agile2015 to insure that they are categorized and easy for you to access. Just give the “Agile 2015″ list  a follow, tweet at us, and become a part of the event!

Follow The DAVISBASE Team on Twitter

CV Photo - Steve Davis - thumbnail web
Steve Davis, CEO
Twitter: @stevedavisbase
CV Photo - Troy Plant - thumbnail web
Troy Plant, Director
Twitter: @troy_plant
CV Photo - Leslie Morse - thumbnail web
Leslie Morse, Director
Twitter: @lesliejdotnet
CV Photo - Josh Fruit - thumbnail web
Josh Fruit, Agile Coach
Twitter: @joshfruit
CV Photo - Barry Gavril - thumbnail web
Barry Gavril, Agile Coach
Twitter: @barrygavril
CV Photo - Bonnie Bennion - thumbnail web
Bonnie Bennion, Agile Coach
Twitter: @bonnsbee

Follow Our Strategic Partners on Twitter

Twitter: @VersionOne
Twitter: @ICAgile
Scaled Agile
Twitter: @ScaledAgile

Print pagePDF page

Celebrating Successes, DriveTime

Q&A with Adam Swofford, IT Director of Product at DriveTime

Author’s Note: Adam and I worked together back in 2004 at a small start-up company that ended up being sold to Merrill Lynch. The first thing I remember about Adam is that on his first day of work he managed to reset the administrative password to our system without having any credentials. I remember our seasoned CTO’s reaction to having some young kid fresh out of college steal the administrative password to our system: it was one of those moments you can’t forget.

Needless to say, I knew there was something special about Adam from the start, and he’s as amazing a human being outside the office as he is inside.

I remember pairing (before I knew what it was called!) with Adam literally all night long as I’d write code and he’d run tests; then we’d sit side-by-side and evaluate the cause of any bugs Adam found. Those all-nighters and the time we spent developing that system was one of  the best times I’ve ever had working for a company. There was something special about our small group, and Adam was a standout among us.

It didn’t surprise me in the least when Adam recently posted to Facebook about Computerworld adding DriveTime to its top 100 Best Places to Work in IT, and ranking DriveTime at #15 for its first appearance on the list.

Dan Moody, Davisbase (DM): Adam, first, congratulations on DriveTime being named #15 on Computerworld’s 2015 Top 100 Best Places to Work in IT; I’m sure you are a driving force to promote a culture that would be recognized as a top place to work. In the article, I really enjoyed the quoted phrase, “speak up and think fast.” Because it was in quotes, I presume this is a mantra coined by DriveTime and something that you live by. Two-part question: 1) How did this slogan come to be (if you know) and how is it applied in the day-to-day IT operations at DriveTime? 2) How do you think this fits in with Agile Values and Principles?

Adam Swofford, DriveTime (AS): Honestly, “speak up and think fast” is a shorter version of our “Way” of execution.  It’s another phrase in quotes that is used to help us all execute as a team.  We feel the way to successful execution is through five core values: urgency, ownership, flexibility, an optimistic attitude, and over communication.  This “Way” is the way we approach Agile Values.

I honestly didn’t know they were called “Agile Values”…look, more quotes, but we have them as the background to all of the stand-up screens in our office.  Don’t get me wrong, when I say that we over communicate, I don’t mean comprehensive documentation.  We feel it is better to error on the side of communication than not.  We change a plan when necessary and if you spend a little time communicating why (normally a better understood customer need) we will all support the change and work together to course correct.

DM: Clearly, whatever you’re doing at DriveTime is working. What advice would you give to companies just starting out on their Agile journey?

AS:  DriveTime has been Agile for 10 years.  It is always a work in progress.  We have changed from Scrum to Kanban, we have changed tools countless times, we have grown 7 fold, and we have spun off many groups to start new ventures.  I would say, always look for that next improvement and try something.  Pilot a change.  Maybe a third of our pilots are successful, but that is still a lot of success.  When you fail, realize it, fall back to what you know works, and then tweak it and try again.

DM: Many companies just starting on their Agile journey may look to your success and want to emulate all of your practices. If you could suggest one and only one practice at DriveTime for others to emulate, what would it be and why?

AS: An important practice that is not a simple step in the process, but rather something to work on throughout the process is focus.  Focus on your role, responsibilities, and the task at hand.  In an open environment, communication and collaboration are high but so are distractions.  It’s a hard balance but one that is important to get right.

DM: When we teach our Agile Bootcamps, we will often ask our class to choose both one of the 12 Agile principles that they think is the most important, and one that they think will be most challenging to live by at their company. I pose the question to you: Which of the 12 Agile principles do you think is the most important? Which is the most challenging to live by at DriveTime? Why?

AS: We are here to solve business problems.  Working software is the way we do that and the primary measure of our progress.  We can’t lose sight of that.  We have a lot of people that bring continuous attention to technical excellence and good design, however it is hard to keep that focus.

The focus is always on what problem we are solving and how soon we can provide the solution.  That leads to a push for a solution and not wasting time to determine how best to solve the problem.  We need to remind ourselves that the right technical solution will itself be more agile and will provide us a better building block for future solutions, which in turn will save us time. It’s the “think fast” part of our mantra.

DM: Do you think DriveTime’s commitment to Agile Values and Principles played a role in creating the corporate culture that caused Computerworld to recognize DriveTime as the 15th Best Place to Work in IT? And, give me virtual a fist of five on how important DriveTime’s commitment to Agile Values and Principles is to creating that culture: 1 being “not at all important” and 5 being “the single most important factor.”

AS: Lucky for us, DriveTime’s corporate culture pushed IT into Agile practices a decade ago.   Our executives are 100% bought into technology being the solution, so the support we’ve received along the way has been incredible.

Our commitment to Agile within IT has encouraged our teams co-create, innovate and work on projects that drive them, which are all reasons why we have such a great culture.  I’d rank our commitment to Agile at least a 4 in promoting our corporate culture and a 5 in IT.  The IT layout of open spaces and rolling desks has spread over the years as more areas of our corporate headquarters embrace Agile practices.  Today the entire building and nearly every department is structured around Agile philosophies.

DM: Last question: Is there anything you’d like to say about your personal Agile journey, or advice you’d give to someone just starting on their own journey?

AS: Implementing change is hard.  Implementing change in yourself is harder.  If you can be Agile in thought and not just in practice you will be open to solutions that were not previously available to you.  That was the hardest thing for me to figure out.

DM: Adam, thank you so much for your time today. I appreciate you making time to answer some questions for our readers. I’ve discussed your success with everyone here at Davisbase, and on behalf of all of us, I’d like to tell you how thrilled we are for you and DriveTime and to offer our congratulations. Personally, I know there are more great things to come in your future; I’m looking forward to seeing what’s next. Congratulations again to you and to DriveTime’s success in IT.

Print pagePDF page

Learn to Lead in a Lean|Agile Organization

Enhance Your Leadership?

Contact us about scheduling an event for your organization.

Contact Us

What does it mean to be a Lean|Agile Leader? Lean|Agile Leaders are devoted to amplifying the success of the people within their organization. They do not necessarily need to have authority within an organization. Lean|Agile Leaders can naturally exhibit behaviors aligned with Agile values, principles, and practices, and enable a Kaizen approach for influencing good change. Learn more about becoming a Lean|Agile Leader at Davisbase’s new course: Lean|Agile Leadership.

The course covers five modules:

    1. Refresher of values, principles, and practices at the core of Lean|Agile
    2. How values and culture can help or hinder a transitioning organization
    3. Qualities the manager/leader must develop to be a servant leader
    4. Team dynamics and how to enable teams to become more empowered
    5. How to lead the change management process from current to future state


The Lean|Agile Leadership course is a  two-day course for directors, managers, team leads, and program/project managers. By the end of the course, leaders will understand how to promote and advocate Agile principles and practices within their organization and, ultimately, how to support a Lean|Agile transformation.


Print pagePDF page

Flash Sale, Today at 2:00ET!

 unnamed (1)Our Flash Sale starts today at 2pm ET and will last 48 hours! During this time you will get deep discounts on select Leading SAFe events, regularly priced at $1395. In order to take advantage of this offer, use promo code FLASH715.

What You Need To Know:

Print pagePDF page

Meet us at Agile2015!

Are you attending the Agile2015 conference?
agile2015  Steve, Leslie and Josh will be attending the Executive Forum.

If you haven’t already made your Agile2015 plans, time is running out, and tickets will likely sell out soon. Festivities in Washington, DC kickoff on Sunday evening with orientation & a casual meet-and-greet. Folks from the Davisbase team will be there!  Also, if you didn’t know, on Monday, August 3rd there is an Agile Executive Forum that runs in parallel to the first day of the conference. Registration is limited to 125 participants, so be sure to act fast!

Let us know you’re attending Agile2015!

Lunch, Dinner, or an Informal Conversation
We’re truly interested in getting to know you better, and there’s no better place than our industry’s largest annual conference with Agile Alliance. Please complete the form linked below and we’ll be in touch to plan a time we can meet.

Register Now

If you’re a current Davisbase client, and attending the conference, be sure to sign-up because we will be hosting a client dinner and would love for you to come!

Be sure to look for these faces when you’re in DC!

CV Photo - Steve Davis - thumbnail web
Steve Davis, CEO
Executive Forum + Conference
CV Photo - Troy Plant - thumbnail web
Troy Plant, Director
Conference Only
CV Photo - Leslie Morse - thumbnail web
Leslie Morse, Director
Executive Forum + Conference
CV Photo - Josh Fruit - thumbnail web
Josh Fruit, Agile Coach
Executive Forum Only
CV Photo - Barry Gavril - thumbnail web
Barry Gavril, Agile Coach
Conference Only
CV Photo - Bonnie Bennion - thumbnail web
Bonnie Bennion, Agile Coach
Conference Only

Print pagePDF page

The What vs. The How

The What vs. The HowI drew this picture last summer when co-coaching with Dan Moody for a client down in South Carolina. It was one of those cool moments where I magically drew something on the white board and everyone loved it.

Since then, I’ve used this image with other clients, captured it (in this form via Paper by FiftyThree) to use in conference presentations, and shown it to my Davisbase colleagues at our all-team meeting last week in Utah during an open space session on Info-graphics (thanks Bonnie!). Now, I’m sharing it  here for you to use as well. Hope you enjoy!

The What vs. The How

User Stories are not a once-and-done sort of thing. They are a placeholder for conversation.  They should be written on a card in order to keep them brief, and they are ABSOLUTELY negotiable.

The challenge is that team’s often jump straight to the solution (the how) before having a clear understanding of the what. There is progressive elaboration that must occur for each user story, and it’s nearly impossible for a team to derive the best solution unless the “what” for the story is clearly articulated up-front.

The lifecycle of a user story has 6 main stages. (Visual on the lifecycle of a user story to come in some future post. Perhaps co-authored with Jeffrey Davidson.)

1. Rough Cut 2. Clear What 3. Planned
Something on a card, with high-level acceptance criteria. Enough for the team to make a guess at its relative size. Refined story content with more detailed acceptance criteria and a more confident sizing. Its also now prioritized. The story has been targeted for a specific iteration within the release horizon (see Sizing to the Horizon).
4. Ready 5. Committed 6. Accepted
The team has refined the content, talked enough about the “how” to feel it matches a Definition of Ready. The team has committed to the story during a Sprint Planning session. The team has demo’d the story to the Product Owner and it has been accepted.

As you move through the stages, the “what” conversation becomes more of a “how” conversation. I also don’t expect a team to know 100% about the story before they commit to it. You learn more as you go. Its a good thing, and requires collaboration among ALL team members. I suggest you try it!

The What vs. The How

PS – You probably don’t even know 100% about the story at the end of the sprint. You don’t really know if it satisfies customers until it is in production! ;-)

PPS – It’s nearly impossible for me to write about, or talk about, user story refinement and the idea of “rough cut” versus “good what” without fondly remembering one of our fearless and inspirational leaders, Bill Gaiennie. He will forever be missed.

Print pagePDF page

Definition of Ready – Revisited.


Since authoring my first post on Definition of Ready (Getting a Story “Ready”) back in December 2012 (wow… that long), I’ve slightly refined my 4 questions, and have added a few other guidelines for avoiding a failure to launch within the sprint.

In this post, I’ll give you the most important highlights and guidelines you’ll need to be successful!

Definition of Ready User Story

The 4 Must-Haves in a Definition of Ready

  1. All team members have a shared understanding.
  2. The story is sized accurately & appropriately.
  3. The team knows “enough” to plan the tasks.
  4. All incoming dependencies have been fulfilled.

Struggling with “Sized Appropriately?” Check out Sizing to the Horizon.

Three Questions to Determine Shared Understanding

Individuals OTHER THAN the Product Owner, Tech Lead, QA Lead or other “lead” type team members are able to describe (using their own words)…

  1. The technology approach for building that increment of the solution.
  2. The testing approach and key scenarios to ensure it’s fully functioning and hasn’t broken anything else.
  3. How to demo the functionality to prove it has met the Acceptance Criteria.

Print pagePDF page

Coaching Office Hours, Installment #2: The Agile Manager

Welcome to our second installment of Coaching Office Hours with Davisbase! Last installment, we spoke with Jeffrey Davidson on the topic of change. If you missed it, be sure to check out his insights on the topic of change here!

Our topic today is about management and leadership, specifically the role of the manager in an Agile transformation. The role of management has often been overlooked in Agile transformations in the past. Fortunately, it is now receiving far greater attention and support as seen in the SAFe framework, conference talks, and myriad articles and papers around the web. The message to management is changing from “give the teams some training and coaching and get out of the way” to “you are needed as a key enabler and an active contributor for the success of the transformation”.

At Davisbase, we’re committed to helping not just the teams become Agile, but their management as well. So today we are speaking with Scott Frost, Agile Coach & Trainer, to help shine some light on how you as a manager can be a key enabler and active contributor to your organization’s Agile transformation.

DBC: One of the most common challenges in an Agile transformation is the changing role of the team manager. First, though, help us understand why the manager role needs to change.

Scott:  In past Agile team implementations, it was all about the teams: good Scrum, skilled Scrum Masters and inspiringly focused Product Owners.  But when we talk about Agile “transformation” today, we are talking first and foremost about leading broader organizational “systemic” change, which can only be done by the managers and supervisors (and their managers and supervisors).

“People are already doing their best; the problems are not the people but are with the system.  Only management can change the system.” ~W. Edwards Deming

 If managers have not had this type of leadership experience, then they should read John Kotter’s book, “Leading Change”.

DBC: Now that we better understand why the manager’s role needs to change, how does the manager role change in an Agile transformation?

Scott:  In three ways.  Decentralize many existing decisions you make today; become a Lean-Agile Thinking-Teaching manager; become a servant leader.

First, a manager needs to recognize that in a Lean-Agile transformation it is not enough to commit your teams to change: you have to openly hand them decisions you used to make and coach them how to make them – never assume they know how.  Do not use ubiquitous, management fluff-words like ‘empowerment’ that will do nothing but make your teams roll their eyes, whether in front of your or behind your back.  Instead, take immediate and tangible actions to let them know you are taking responsibility for the change.

Second, become a Lean-Agile Thinking-Teaching manager. Read several Lean-Agile books and take a class or two, then buy some books for your teams (or subscribe them  to Safari or Scribd).  Acknowledge that, as a manager, you may not be educated enough to help LEAD the change, then take action to correct your knowledge gap because the responsibility to lead cannot be delegated: to develop your people you must develop yourself.

Finally, become a servant leader.  Agile leaders are there to help remove impediments, take a long-term view, and create a culture which anchors everyone in Agile principles.  Agile managers should provide structured problem solving workshops and teach their teams to find and solve their own problems, then they need to get out of the way.

DBC: What are some things to focus on getting right and some pitfalls to look out for as a new Agile manager?

Scott:  Focus on enabling behaviors. Changing a culture is done by modifying the principles and habits of the organization.  At whatever level a manager may reside, there are people to be developed, inspiration and alignment to missions to be fostered, and knowledge workers to be motivated.  It is not enough to have an “IT Strategy” to move an ineffective culture toward better and sustainable habits.  As Peter Drucker once said, “Culture eats strategy for breakfast.”  Culture is systemic.  Remember: only management can change the system.

DBC: How can Agile managers help all team members regardless of their positional rank or power become leaders in the agile transformation?

Scott:  Leadership is a task, not a title or a role.  I like to use the analogy from the Matrix movies:  In the first movie, Keanu Reeves goes to see the Oracle for the first time and marvels at a little girl bending a spoon with her mind.  She tells Keanu that the trick is, “There is no spoon.”  In other words, the constraints he places on his own mind create impediments to accomplishing his objectives inside the Matrix.

It’s similarly true for Agile managers:  you must first let go of your prior cultural and organizational biases that leadership is granted through title or position.  Leadership is a task which is freely picked up by the best person for the task at a given time and handed to another person for other tasks.  Anyone may perform a leadership task just as any manager may serve the teams, irrespective of organizational reporting structures.

DBC: Last question – what didn’t I ask you about Agile management and leadership that I should have?

Scott:  Dean Leffingwell, author of Scaled Agile Framework (SAFe), promotes being a lifelong learner.  Leffingwell says, “Lean-Agile Leaders are lifelong learners who help teams build better software systems through understanding and exhibiting the values, principles and practices of Lean, systems thinking, and Agile development.”

So is that accomplished by a one-time read of a collection of books or a couple of classes? Well, that’s a start, but not enough.  Fundamental shifts are taking place in our industry.  I find it amazing that literature from the 80’s and 90’s are still so under-read yet very relevant today.  Even so, there’s an endless list of new works being published which an agile manager should challenge themselves and their teams to read. How about setting a goal of 2-4 books a month?

What?  Is this guy kidding?  Nope, no joke.

If you have experienced success in Agile teams then you know that one of the fundamental tenets of Lean and Agile is to continuously bring to light the issues and impediments of a team or a team of agile teams.  If the impediments are continuously and evermore increasingly complex, how does a good Agile manager stay ahead? Yep, that’s right: always be reading, learning from others, talking to peers, and challenging your own knowledge.

If you have team issues,read The Five Dysfunctions of a Team by Patrick Lencioni If you do not understand flow-based systems and lean principles, read Don Reinertsen’s Principles of Product Development Flow.f your teams struggle with basic scrum, read Jeff Sutherland or many other Scrum authors. If your teams are discussing Set-based Design or Emergent Architecture, read Dean Leffingwell’s Agile Software Requirements and The Lean Machine by Dantar Oosterwald…..and the list goes on and on.

Final thoughts: trust your people to make good change and trust yourself to stand alongside them and assist.  Take the journey. Seek mastery and purpose. Enjoy the ride.

– – – –

Alright, that’s it for this month! Thanks to Scott for his time and keen insights! You can continue the conversation on Agile management and leadership with Scott on twitter @getfrosty and Davisbase @davisbase. Check back soon for the next installment!

As always, we hope you find this series relevant, informative and helpful on your journey to becoming Agile. We would love to hear from you so you can help us make it even more relevant! Submit your questions or suggested topics on Agile transformations to us via twitter @davisbase with hashtag #askDavisbase, or via email at coaching-questions@davisbase.com.



Print pagePDF page

Sizing to the Horizon

Sizing to the HorizonIt’s never fun to have to use the go-to consultant response “It Depends.”  Sadly, it’s part of my vocabulary when working with teams and it inevitably is used when teaching teams about “Sized Appropriately” aka “Small Enough” from Bill Wake’s INVEST model.

It’s true though: “it depends.” Every team has a different definition of what “small enough” is. The key to a good, high-quality backlog is having your highest priority items “sized appropriately.” So today, I will give you a few models and guidelines for how to know if things are “small enough” and why its important to “size appropriately.”  (Think I’ve used the phrases enough to drive home the point it’s important?)

Understand the Horizons

There are four horizons your team should understand.

  1. Now – The stories the team has committed to and are part of your Sprint Backlog
  2. Next – The stories at the very top of the product backlog and likely to be pulled into next sprint. (Hopefully they are already laid out on your Release Plan / PI Plan / Sprint Forecast.)
  3. Soon – The stories prioritized to work on within the current Release / PI Cycle / the next 2 – 4 iterations (aka Sprint Forecast).
  4. Later – The stories outside (or beyond) the current Release/PI/Sprint Forecast.

Know the Sizing Guidelines for each Horizon

Stories within each horizon should start and finish in…

Now Next Soon Later
< 50% of a sprint < 50% of a sprint < 1 sprint > 1 sprint is OK

Why do Now & Next have the same guideline? Because it is a best-practice to have the next sprint’s stories already in a “Ready” state in case you need to pull them in early or make trade-offs mid-sprint due to blockers/severe impediments.

What does 50% of a sprint mean?  An example will probably help you understand.

Consider a team with an average velocity of 35 points. (We will assume they are using the standard modified Fibonacci sequence for sizing.)

  •      Size of 20 – This is more than 50% of the team’s velocity, and likely takes the majority of the sprint to complete.
  •      Size of 13 – Nearly 40% of the team’s velocity, and likely takes about half of the sprint to complete.

In this case, we would say the following guidelines would apply:

Now Next Soon Later
< 13pts < 13pts ≤ 20pts > 20pts is OK

Here is another way to think about the guidelines based on passing time. Let’s consider a team with a 2-week sprint cadence. (Note: days = “working days.”)

Now Next Soon Later
3-5 days 3-5 days < 10 days > 10 days is OK

Why Small Enough is Important

Ultimately, it’s related to three things:

  1.     Ensuring Quality
  2.     Mitigating Risk
  3.     Minimizing Bottlenecks

Here is a brief description of each:

Ensuring Quality

“Test Early, Test Often” is a mantra in the Agile community. Small stories enable you to test early in the sprint and create a continuous pattern of inspect and adapt cycles for the product throughout the entire sprint

Why does CvC Matter? Because it measures the accuracy of a team’s commitment and is a primary way of measuring team performance.

Mitigating Risk

If something goes wrong with a large story and it doesn’t get finished, then a considerable percentage of the sprint backlog will not be delivered. This is important because it would result in a low CvC (Complete vs Commit) metric.

Minimizing Bottlenecks

Large stories take nearly the entire sprint to complete; thus, all the quality assurance and testing activities will be piled into the last 2-3 days of the sprint. This bottleneck doesn’t really give much time for defect remediation either (see Ensuring Quality above).


Alternate Models to Consider

If the term “horizon” is not resonating for you, then consider these alternatives:

Now & Next Front Burner Good Rut
Soon Back Burner Clear What
Later The Fridge Rough Cut

Print pagePDF page