April 23, 2014

Agile Coaching Blog

Agile Coaching Blog

This agile coaching blog has news & articles from BigVisible coaches and trainers. Find agile topics like Scrum and Kanban. Read about collaboration, communication, & enterprise agile. See hints for better daily meetings, retrospectives, and Scrum reviews. Learn about leading edge tools for lean startup and customer development. Discover information geared toward agile teams as well as leaders & executives.

We hope the information you find here will help your organization become more agile, adaptive, and innovative. Our goal is to help you delight your customers & succeed beautifully.

Estimation is a Cruel Mistress

Estimation is a thing of beauty.  It’s the crystal ball that every business wants to allow perfect decisions to be made.  It’s sort of a yearning, a siren song that calls to us and tells us everything will be wonderful.  If only we could estimate well, then we could have perfect insight beforehand into what things will cost (in terms of research and development, marketing, etc.) and what those things will produce in benefit (in terms of both extrinsic as well as intrinsic values).  Our decisions would be risk free, and therefore we could make perfect decisions.

But estimation is also a shiny object that can become very distracting.  Unhappily, what far too many people fail to realize is that, no matter how careful we try, estimates are not exactimates, and decisions have to be made with less than perfect accuracy.

Estimation is Bad – It is Nothing More Than Waste

Why do we feel compelled to estimate our work before we start work?  There are many reasons, but the first one that we should dispel is that we need to estimate before we work.  Estimating before work starts is something that we’ve been told since the days when project managers were first conceived of.  Estimate, analyze, design, code, and test.  We were also told that we needed to get “signoff” before we moved from one stage to the next.  And estimation was always fundamental in those moves.  If the estimates were high, and the benefits were low, then our manager would tell us to not work on the project now.

But what if we challenged that assumption?  What if we could produce solid working software, ready to use to make our company money, and do it efficiently without any sort of documentation whatsoever?  Why wouldn’t we do that?  In fact, if those assumptions are actually false (that is, you could produce positive value without estimating), then you’d be certifiably insane to create all of that documentation which isn’t needed!  Why would you create unnecessary documentation when you could be creating code instead?  After all, we get paid for the software and the value it produces.  No one buys our documentation about the process to get to software!

Estimation is Good – It is Needed to Plan

Well, there actually is a use for estimation.  Even in that perfect world where software is getting created with only conversations between the business and the technical sides of the project, there’s still one thing missing.  And that’s planning.

A business needs to plan and mold its customer expectations based on the capacity of the organization to produce useful and valuable software on a timetable that makes sense to both the business in terms of revenues, and the customers in terms of value received.  Unless we can have some form of plan, we can’t set those expectations.  And getting expectations from customers, and therefore expectations of things like revenue from customers is important.  It’s how we plan our business.  We need to marry and couple those plans together to have a viable business, pay salaries, and so on and so forth.

The job of the business will be to set broad expectations for what might be available in what approximate timeframe, and then manage those expectations as the dates begin to get close.  So, when the organization plans its roadmap, the huge epics on the backlog will need some sort of rough estimates to couple to the velocity of the teams creating the software.  That coupling of plans allows the business to derive the expectations of when things might be available.  It’s simply not acceptable for customers to ask, “So, what features are on the horizon for the software?” and get a response of “Oh, gee.  We don’t know yet.  But we’ll let you know what we did when things are done!”

The Evolving Role of Estimation in an Agile/Scrum Setting

Estimation in Agile and Scrum is not a one-time learned skill.  Because of the true difficulty of actually creating accurate estimates, it is rarely done well.  The real point of this piece is say that accurate estimates are really never needed for development, but only estimates good enough to set reasonable expectations are needed for planning.  But there is another reality that estimation clarifies.  As the Delivery Team moves from more traditional development into an Agile model, their ability to estimate appropriately increases.  There are at least two causes of this: the Delivery Team remains constant over time, so people learn their collective capacity, and the Delivery Team begins to understand that estimation, by itself, is not needed to actually produce software!

So, what progression can one expect a Delivery Team to go through when making the transformation from traditional to Agile development?

At first, when the team works on very large epic type stories, many times the team is so poor at estimating that they routinely miss iteration commitments.  When we examine how the software is being created, we see that the team is actually practicing a form of “Scrumfall”, where a story starts in one iteration or two with analysis and design, followed by another iteration with implementation, followed by testing, etc.  Tasking is used to try to figure out what is possible, and the iteration planning sessions are laborious, lengthy, and end with poor results.

As the Agile transformation proceeds, it is common for the team to still be using fairly large epic type stories. Many times, these stories are “assigned” one story per developer per iteration. Since the stories have large story point sizes, tasks are still used to assure that story will fit into iteration.  The results may be marginally better and the iteration goals may be somewhat more predicable.  But the iteration planning sessions are still intolerable.  Yet somehow, the fragrant scent of change wafts in the air.

Then, as the transformation progresses, smaller user stories, perhaps around 5 for each developer per iteration, start becoming common.  The stories will now still vary in size, but we no longer see things like a story that eats an entire iteration.  The Delivery Team becomes much better with sizing these stories using relative estimation.  Tasks are still used to ensure that adequate capacity will likely be available from the entire team.  But the tasks are now more of a cross-check rather than the way that the iteration is planned.

As the transformation progresses further, even smaller user stories get written and used for iteration planning.  Those smaller stories have better foreseeability, so less uncertainty is present, which makes the estimates better.  Additionally, because of its experience working together, the team starts feeling comfortable with relying entirely on velocity to get to an iteration commitment.  It’s at this point that tasking becomes a waste.  Iteration commitment can be done purely by looking at team availability and story point commitment!

Further down the road, the transformation starts having even smaller detailed user stories that all are fairly similar in size. The act of negotiating while writing the right story (with appropriate acceptance criteria) now allows the team to not even estimate anymore. We begin to start writing stories that are more or less uniform in size.  Iteration commitment can be done purely by looking to the team availability for the iteration and just counting stories.  Oh, and by the way, once we can avoid doing estimation during iteration planning, we get back a significant amount of time for creating even more product value per iteration.  Of course, all of this reduction in estimation is really just continuous improvement doing its job!


Estimation, like beauty, is something that we are drawn to.  We are attracted to the idea of estimation and feel that somehow if we possess a great way to be comfortable and good at it that our lives will be better.  But, at least for most of us, we have to be careful to not fall prey to its deception.  Our lives are immensely better with things like openness and honesty, not just crass momentary illusions of what seems beautiful.  In the product development world, at least, those values help us achieve the goals that really matter.

Thandie Newton as Stella in Guy Richie’s 2008 film “RocknRolla” (http://www.imdb.com/title/tt1032755/). “Beauty is a cruel mistress.”

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



What Big User Stories Could be Telling You

User stories are intended to be a high level description of some functionality. It is, however, common to find user stories growing into specs or large use cases that resemble whatever the organization used to do, back when they did large requirements documents. Comments like “The stories are not detailed enough to start development” or “This took much longer than expected so we should have more acceptance criteria for next time” can become common. There is a balance here that we should watch and adjust carefully. And most of the time we think the solution is more story documentation.

Here is the story card AND all the acceptance criteria, wire frames, specs, use cases, test plans, flow diagrams, architecture...

Why User Stories Get Big

I like user stories as an easy to understand idea for a company to start thinking about a light weight way to communicate needs, features and benefits. It is hard to describe in brief sentences all the forces that pull organizations to keep them thinking in lots of details. A few might be:

  • A culture and history of Big Design Up Front that makes it hard for feature definition to happen just in time.
  • A continued need for long range planning requiring estimates for work that will possibly take months before it actually starts.
  • Skilled technical people who are accustomed to talking about technical details instead of the needs of the user.
  • And more…

Lack of Focus

The most powerful and subtle force to cause “user stories” to grow is a continued lack of focus for the people defining features and those creating the features.

For example, if I am Product Owner of 5-12 products working with 3 teams who are all working on multiple products, I am not able to think of a feature, collaborate on it’s definition as it is built, see it created and then think about the next feature. I have to document my thinking of every feature because one hour from now I have to think about other features that also might not be built right away.

The key to being truly Agile is to finish stuff. The more inventory of ideas, features, undeployed code, etc. that we have, the less Agile we can be.

Have Conversations

In short, Ron Jeffries, the inventor of User Stories, said that the user story should have “3Cs” of attributes: Card (small enough to fit on an index card), Conversation (is a place holder for conversation) and Confirmation (a definition of when we are done, such as acceptance criteria). Most of the symptoms prevalent when stories grow big are likely indicators that the Conversations are not taking place and people are writing stuff down in an attempt to fill the gap.

Don’t write more stuff down. Figure out why the right conversations are not happening. i.e. “Individuals and interactions over processes and tools.” That said, sometimes what we see as an over-documented abuse of the user story is a vast improvement on what the organization used to do. We have to temper our zeal with a dose of client reality as we work to get incrementally better.

Do you see user stories getting too big? If you don’t use user stories, does what you use help or hinder conversations? What is your balance between the ability to deliver vs. the need to document thinking?

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Scrum Meeting Success for Distributed Teams

In a previous blog, I discussed ways to make distributed daily scrum meetings more effective. This blog reinforces those ideas and provides additional tips to run successful scrum meetings with geographically distributed teams.

Productive, timely, 15-minute Daily Scrum meetings, remain a challenge. As many practitioners will attest, co-located Daily Scrum meetings are nearly as challenging for some of the same reasons:
- Meetings go beyond 15 minutes
- Not everyone has a chance to be heard
- Conversations wander into resolutions and opinion
- Impediments are not captured and addressed
- Others interrupt
And more…

Holding team meetings where members are not in the same physical or mental space is quite challenging, and it becomes more so when the team is geographically distributed. As I mentioned previously, the initial rule of thumb was to breakdown the daily meeting into small deliverables and then focus on each part of the meeting. The overall Definition of Done is the teams take ownership of the Daily Scrum meeting and use this as a foundation/basis. This idea has evolved into a goal for Daily Scrum meetings of having the team take ownership and management of their daily meeting. With this, we can create “Definitions of Done” for each part of the meeting.

For example:
Part 1: The team listens to each other’s ‘questions 3’ with no interruptions.
- Definition of Done: each team member has an equal voice to state their answers and be heard by their team members.

Part 2: The ScrumMaster reads the impediments/issues they recorded and the team adds, corrects and confirms the list is correct
- Definition of Done: the ScrumMaster reads off the impediments and has the team approve them

Part 3: The participants in the Daily Scrum meeting organize additional conversations around the Sprint and the results of the Daily Scrum Meeting the team.
- Definition of Done: the team members self-organize and work on the issues at hand and have these groups communicate what they did before the next scrum meeting, to the rest of the team.

When it comes to implementation there‘s a way to execute this process. For example:.
The meeting begins with one team member (initially the ScrumMaster) asking a team member the ‘questions 3’.
- The team member identifies the task and the story they are working on. They describe at a high level what they are doing and how much more time they need to finish.
- The team member then describes what they plan on doing tomorrow. If they will be moving to a new task, they should state which task.
- The team member then states what issues/impediments/ concerns they have about getting the work done or completing the sprint..
- Team member #1 then asks another team member the ‘questions 3’. This is a sure way to transfer ownership of the meeting to the team.

This is not a ritual. It is a basic pattern of action that can be used to start off a new team, orient new team members and get a team back into a rhythm. I have found that getting back on track is a lot easier if there is a simple base or foundation to structure and define roles. From there, teams can quickly self-organize…and it works well when things get stressful!

Roles and Actions for the Daily Scrum
ScrumMasters don’t run the Daily Scrum – they guide the team to run it themselves. Their primary focus is to collect the impediment list and get it approved by the Team. There should be a task on the task board regarding impediments for reporting the status of impediments.

Team Members individually and collectively run the meeting.

The Product Owner should be there listening and ready to answer questions immediately after the meeting closes.

Anyone who has committed to deliver something to the team during the Sprint must have a task on the task board and attend and answer the questions 3. This includes Product Owners, stakeholders, and management.

Guidelines and Techniques for the Daily Scrum
1) Turn the meeting ownership over to the team by having each team member ask another member the ‘questions 3’. Since there is no pattern or set order when one team member asks another, people on phones pay attention because they do not know when the questions will come their way.

2) The ScrumMaster is the servant leader, helping the team stay focused on the conversation, the task board, and the questions. It’s surprising how quickly the rest of the team picks up on this focus and brings the more loquacious and “off tangent” teammates back on track by asking “what task are you talking about?” Some teams go as far as including a protocol statement in their team charter stating all questions in the daily Scrum meeting begin with the user story and the task.

3) At the end of the first part of the meeting, the ScrumMaster, who may have been taking notes on the impediments, begins the second portion of the meeting by going over the impediment list to see if any were missed. This action reinforces that this meeting is for the team and that all issues are visible and noted.

4) The third and final part is a call for the issues to be discussed immediately after the meeting. Any team member, including the Product Owner may ask for conversations on story or task issues.

5) As soon as that is sorted out, the ScrumMaster requests that all decisions resulting from the upcoming conversations be communicated before the next daily meeting.

6) The daily meeting is closed and the conversations continue.


Video: Thoughts On Agile Design with Dave Gray and Alan Dayley!

Gamestorming is one of the foundational books on interactive and highly collaborative meetings. Dave Gray, one of the book’s authors, has begun working on a new book titled “Agile Design Principles.” He is interviewing various people who work and write about Agile ways of working. I was pleased to be interviewed.

Our discussion ranged fairly wide, as you can see from the topic list below the video. Enjoy!

  • 0:01:00 – What does Agile Design mean?
  • 0:03:38 – The utility of “open plan” offices and what makes them work or fail
  • 0:09:30 – Teams should control how they work
  • 0:10:13 – Good interruptions vs. bad interruptions
  • 0:12:58 – Working before Agile and getting to it
  • 0:14:55 – Technical debt can be the spur to change
  • 0:18:38 – W. Edwards Deming and seeing “the system” when software is ephemeral
  • 0:21:58 – Distributed teams can work by paying attention to communication
  • 0:24:01 – The social part of Agile and how it helps
  • 0:26:04 – Division of labor is not necessarily as good as we think
  • 0:30:52 – Teams of teams keeping coordinated with Product Walls
  • 0:38:30 – Leadership gives the place to start, the framework to catalyze self-organization
  • 0:39:30 – What Agile and self-organization means for managers
  • 0:42:35 – Common obstacles to transitioning to Agile ways of working
  • 0:47:32 – Capacity in full-time equivalent hours vs. empirical measure of capacity
  • 0:52:05 – Definition of Done
  • 0:53:39 – Is there a “no excuses rule” in Agile?
  • 0:56:38 – Empowerment vs. power
  • 0:58:45 – Going back to Deming, the “system” of sports teams and hero experts
  • 1:02:40 – Create a culture of safety and trust in order to innovate

I enjoyed talking with Dave and I hope you can gain some tips and insights from our conversation.

Want more Alan Dayley in your life? Dive in.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Strong Teams: The Foundation of Scaled Agile Success

Agile at scale is BigVisible’s specialty. Our coaches have been developing and refining practices for scaling agile methodologies in large enterprises for over a decade. The “BV Way” was developed as BigVisible’s approach to implementation at scale. Recently other scaling frameworks have emerged and are gaining tremendous interest in large enterprises.

The current market-leader among these enterprise scaling models is the Scaled Agile Framework (SAFe). BigVisible has embraced SAFe and hybrid solutions that incorporate SAFe and elements of other scaling models, along with our BV Way.

Each approach has its strengths and weaknesses, but any scaling of agile to large programs and portfolios must be built on a firm foundation of team practices that support scale and complexity.

As the agile adoption curve has progressed to the point that many mainstream organizations have experienced benefits using Agile at the team-level, many now want to multiply those benefits by using agile practices to manage large programs and product suites involving many teams. Some are moving to “agile-ize” their steering and portfolio functions across dozens or hundreds of projects or products.

At this juncture, organizations trying to use agile methods at scale, usually find themselves grappling with substantial additional complexity related to planning and rolling up or consolidating information at higher levels of planning and tracking. Often early attempts are troubled by poor transparency of organizational capacity at different levels, which leads to high levels of variability in forecasting (a fancy way of saying their plans are inaccurate).

In conversations with clients and prospective clients, we often find they are eager to scale agile at the program and portfolio levels before they have reached even modest levels of proficiency in technical and project management practices for delivery execution at the team level. Some think their teams are doing Scrum pretty well, others think that introducing program and portfolio level planning structures will somehow strengthen their teams’ weak execution, from the top down. This is a dangerous misconception, analogous to thinking that adding additional floors to a tottering building will somehow strengthen its weak foundation.

When I was VP of Professional Services at Rally, we developed a model for maturing an organization’s Agile capabilities. The “Flow, Pull, Innovate” model nicely illustrates the importance of establishing foundational delivery capabilities at the team level before adding scale and complexity:

- Rally Software

BigVisible’s “BV Way” similarly ensures that the critical base factors of software production, the development teams, are demonstrably in control BEFORE we expect program and portfolio planning functions to be predictable and managed.

Businesses need to make intelligent tradeoff decisions for scarce development recourses. To do this they need reliable data that is accumulated from observations of historical performance. This historical data populates a statistical model that supports higher-level plans, larger organizational structures, and longer time horizons through the aggregation of data.

To forecast accurately, our base-element statistics must provide sufficient data points of low standard deviation. Our confidence in the predictive utility of our data, its accuracy and precision, should be known and communicated transparently. Rolling up weak stats with high variability and/or artificially high precision will inspire false confidence. Both are damaging to the delivery organization’s credibility, morale, and the agile brand in the organization.

Assuming there’s a consensus that it’s bad to rely on a complex structure built on a foundation of marshmallows, what are some key traits and behaviors demonstrated by agile delivery teams that do provide a solid foundation for scaling?

Here are some specific indicators of Delivery Team maturity:

    1. Measures of velocity, throughput, and/or cycle time: If these stats aren’t tracked, you can’t know the team’s capacity and you can’t forecast. If the data varies widely (high standard deviation) the team’s capacity estimates inspire low confidence, and they probably have underlying issues that contribute variability and risk. These stats can be gamed, so ensure process disciplines are adhered to (eg: accepting only done stories of productizeable increments).

    2. Short cycle times with high fidelity feedback: Longer cycle times and larger batches yield infrequent feedback/sampling rates and mask variability. Relatively more data points should be provided if cycle times are long (4 week iterations, for example).

    3. Consistently high acceptance rates: Teams should consistently deliver by the end of the iteration what they committed to in the beginning. If the percentage of story points accepted over those committed (plus pulled in), is consistently >90%, for example, it indicates several positive behaviors and capabilities are probably present: the team understands their work, their relative estimates of PBIs are consistent, they swarm to complete stories and limit work in progress. Teams with low acceptance rates tend to generate highly variable velocities.

    4. Thorough Definition of Done (D of D): High acceptance rates don’t mean much if we accept software that isn’t fully validated and integrated, or produce software that may not deploy predictably. A Definition of Done that allows acceptance of anything less than a potentially shippable increment creates batches of risk and introduces variability near release time.

    5. Comprehensive test strategy and continuous delivery: It is critical to fast feedback that every code change initiates progressive stages of high-coverage automated test suites in a continuous delivery pipeline. Even if not releasing to production, demonstrating the capability offers assurance that code assets integrate and deliver value predictably. No pipeline promotion step (except maybe a “DEPLOY TO PROD” button) should be vulnerable to human frailties. Software that relies on humans to read or remember or type to build, test, deploy, configure, migrate (or whatever), will suffer exponentially greater variability when scaled to larger programs.

    6. Measured and managed technical-debt: High levels of technical debt are often related to a weak D of D, or it may simply be the fruit of sins past. Technical-debt increases variability and risk. Technical debt includes untested code, code lacking automated test coverage, unmerged code, unintegrated system components, design flaws, and code smells that require refactoring. The lack of enabling infrastructure can also be considered a form of debt or underinvestment.

    7. A well-groomed backlog: We generally advise teams and Product Owners to maintain 1.5 to 2.5 iterations of “ready” stories in the backlog (maybe more going into release planning). Well-groomed and ready means more than story cards with estimates. It means ready to code- acceptance criteria everyone on the team really understands, and a viable high-level design approach everyone has an informed consensus on.

    8. Continuous planning at all 5 levels: Agile planning at 5 levels suggests an appropriate level of granularity for work items at each time horizon. How many teams have you seen who do standups and sprint planning, and think that’s sufficient to kick scrum butt? Without a roadmap and vision, and a release plan to map strategy to tactical execution, a team is operating myopically with too short a planning horizon. They will fail to address risks, architecture, and design in a timely way (through dialog, spikes, reference implementation, UI guidelines, feature tests/experiments, etc). These teams will fail to provide transparency to stakeholders at the level (feature and release) required to make key decisions.

These elements are mutually reinforcing. It’s hard for a team to deliver well and consistently over the long term with significant shortcomings in any area above. Critically, because variability compounds exponentially with the scale and complexity of a system, it is perilous to believe your program is in control if its constituent teams exhibit significant shortcomings in any of these areas.

Please understand that I am NOT suggesting that if your teams aren’t perfect you mustn’t do release planning, or shouldn’t start implementing SAFe, or that you should delay implementing a “Release Train” to manage your big complex program. By all means, do those things in an informed and deliberate manner, while understanding the limitations of the plan, and aggressively improving the capabilities of the teams.

Indeed, planning should be done early and often, and planning at all five levels continuously is an important element of achieving flow and pull. Just remember that it’s essential to set expectations about the accuracy of plans generated, and to use the appropriate level of precision for the confidence you have in your stats, and for the time horizons in the plan, as errors compound over time.

Some corporate cultures make it very hard to share a plan without it being misconstrued as a cast in concrete “promise” in a destructive game that inevitably ends in finger pointing, recriminations, demoralized employees, and consequently retarded value delivery. Strive to set stakeholders’ expectations that a release plan generated at an early stage of agile maturity is:

1. based on a changeable (agile) backlog, thus is NOT a commitment
2. based on weak foundational stats, thus inherently inaccurate

If you want to scale agile, any significant shortcomings in critical team-level capabilities should immediately trigger an aggressive improvement program involving training, intensive coaching, technology investment, and organization and employee development. This is critical to scale to the program and portfolio levels with the transparency and consistent value delivery your organization demands, and it’s best to begin while leadership and team members have the energy and enthusiasm to effectively embrace the changes necessary to succeed with agile.

A Note on Metrics and Measures

Important Note: In any discussion of metrics and measures, I feel compelled to repeat some classic considerations to help avoid their (all too common) misuse:

    • Measure what’s important, not what’s easy to measure.
    • Poor metrics are worse than none (and incentives even more so).
    • No one metric tells a whole story- a balanced set is essential.
    • Understanding trends is more useful than trying to manage by snapshots.
    • Mismanagement will engender gaming. People are smart. Feeding gamed metrics to disengaged managers is easy if managers create reasons to do so.
    • Numbers don’t replace leadership and people, insight and active engagement, and can’t replace the need to collaborate and care.

There is more where that came from. Download our latest SAFe webinar”Hit the Ground Running:Design and Manage Your SAFe Implementation”



A Very Agile Thanksgiving – Using Personal Kanban

A Very Agile Thanksgiving
Using Personal Kanban To Plan Your Holiday Dinner


Thanksgiving is almost upon us. For many, this is a joyous time of celebrating family and friends and giving thanks. For others (like those preparing for the actual celebration) the long list of To-Dos can seem a bit overwhelming.

One of the easiest ways to cope with this stress is to start practicing agile at home and using Personal Kanban is a great way to get started. Below is a step-by-step guide to taking the list of To-Dos and turning it into something that may give you another reason to give thanks this November.

Step 1 – Set up your Personal Kanban board

If you’ve got a big blank space on a wall near where you’ll be doing the work preparing for Thanksgiving, that would work great. If you don’t have that available, you could use BigVisible’s SeeNowDo or one of the many web based Kanban Tools like LeanKit. If you are working on a tablet computer, KanbanPad.

The easiest way to get started with this is to create a board with 3 columns: Ready, Doing and Done.  If you are really trying to keep with the practice of Kanban, you’ll also want to create a Work in Progress (WIP) limit, at least for the Doing column. The idea behind this is to minimize the amount of things you are working on at one time. If you set a WIP limit of 2 in the Doing column, then it means you can’t be working on more than 2 things at any given time. (Ideally you want a WIP limit of 1, but if you are new to this kind of thing and still believe in multitasking, this may help you keep from trying to do everything at once.

And if you have people helping you with the work, you may want to set the limit a little higher.

Step 2 – Build your Backlog

Grab a stack of Post-Its and make a list of all the things you know you have to do in order to prepare for Thanksgiving. Put one idea per Post-It and place all of them in the Ready Column. This will serve as your backlog of work. You may find it helpful to order (or prioritize) the list of items. If you are going to prioritize the list, you may want to order the items based on what is the most stressful, what takes the most time, or what is going to be the hardest thing to do. You should also factor in some idea of the order in which these things will logically happen. For example, it wouldn’t make sense to prioritize a work item to “Clean the Dishes” so that it reaches the top of the list before you get to “Cook the Turkey”.

Step 3 – Working the Backlog

Once you are ready to get started, pull the top item(s) into the Doing column and begin working on them. If you have a WIP limit, you should only pull in as many items as the WIP limit allows. So, if my WIP is 2, then I can have only 2 items in the Doing column at any one time. If you feel like you need to get started on a new item from the Ready column, you’ll need to complete one of the items in the Doing column first.

Each time you complete an item, move it to Done. It may not seem like much, but you’ll be surprised at the increasing level of satisfaction you get each time you get to move something into the final Done column.

If you’ve got people helping you, they can take and move items as well (keeping to the WIP limit). The idea behind all of this is to limit the amount of things we are working on at one time, get one thing completed and then start on the next item. If you are preparing the Thanksgiving-feast-that-will-be- talked-about-for-generations, you’ve got a lot to do in order to get ready. Staying focused on one item at a time will help reduce your stress, give you greater visibility into exactly what is left, and also help you coordinate the work with anyone on your team.

Step 4 – Lather, Rinse, Repeat

Keep working your backlog until everything is done, moving tasks across the board as you make progress each step of the way. As you move more items to the Done column, you’ll find that the overwhelming pile of things you need to complete is rapidly taken care of, allowing you to spend less time fretting about what has to be done, and more time celebrating with your family members.

Some Tips for Trying Personal Kanban

You may be tempted to skip the WIP limits and just pull everything into Done. This is a tough one – especially if you feel like everything has to be done anyway. Trust in this system, if only as an experiment. It’s been used successfully on projects far more complex than Thanksgiving and it really does work…if you let it.

If you have the ability to set up your “board” space near where you’ll be working (like your refrigerator), you will find it helpful to have it out in the open and easily accessible as you make progress. It will also let others know what you are doing, and hopefully they’ll join in to help.

One of the things I learned from my Personal Kanban experiment earlier this year was that it taught me how incredibly inefficient I have been with my work. If you find the same, just make a note of what you learn and keep it for after Thanksgiving. Once the dinner is over, the dishes are clean and you’ve recovered from the massive intake of turkey, cranberry sauce and pie, take time to hold a Retrospective. If you had helpers for the preparation, include them as well and talk about what you learned during your Personal Kanban Thanksgiving. Try to find some lessons you can take away and improve upon when you begin preparing for your next big holiday meal.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



The SAFe Framework: Rigid & Prescriptive? Or Adaptable & Evolving?

SAFe: Rigid & Prescriptive? Or Adaptable & Evolving?

The Scaled Agile Framework (SAFe) is a hot topic in the Agile community these days. The Coaches and Consultants at BigVisible, like many elsewhere, have been debating the pros and cons of the SAFe framework for a year or two now. We’ve attempted to dispassionately compare and contrast results from our experiences rolling out SAFe at clients who requested it, to the results at Agile transformations done “The BV Way” in large enterprises over more than a decade. While specific differences between the approaches will be addressed in a later edition, let’s begin by examining common objections to SAFe, and considering their validity.

If you are new to the Scaled Agile Framework, start here. For information on the BV Way, contact BV or start here.

Constructive criticisms of SAFe usually address the apparent prescriptiveness and comprehensiveness of this intricate integrated framework.

These criticisms are based on the proven principles that:

1. Organizations are complex systems that evolve their optimal practices and structures as a result of observation, experimentation, and learning over time. One-size-fits-all solution frameworks can’t be as effective as self-tailored solutions evolved organically, nor do they teach the organization to learn and adapt, a critical capability.

2. Change “sticks” when buy-in and ownership of new practices and structures result from shared observation and learning; when new ways of working are developed by those doing the work.

3. People tend to underestimate the complexity, difficulty, and importance of change-management when you can just “buy” an “off the shelf” process framework. The appealing illusion that meaningful change can be prescribed in a nicely packaged graphic may actually diminish the likelihood of successful change, because organizations fail to embrace the commitment and investment necessary to implement change in large organizations.

4. The importance of leadership styles and the need to evolve legacy organizational cultures can be overlooked when one can just “implement a framework”. The foundations of Lean and Agile depend, above all, on the investment in, and empowerment of, people.The critics presenting these arguments correctly emphasize the tremendous value of having experienced coaches and consultants guide organizations through the journey of discovering and adopting new ways of working to implement successful and lasting change. Unique improvement objectives and business and cultural environments produce unique solutions.

These criticisms of SAFe emphasize some very important points, but they assume a dichotomy that doesn’t exist. They imply SAFe’s sponsors disagree,or would knowingly advise a client to underinvest in change management and self-discovery as a basis for continuous improvement.They present a straw-man argument that implies 1) the framework is intended to be implemented verbatim in its entirety, irrespective of context, and 2) that there is no need for a professionally managed change-management initiative to successfully implement SAFe in a complex enterprise. In my interactions with the SAFe community, and my experience becoming a SAFe Program Consultant, I have observed that the SAFe community values and supports:

• Encouraging organizations to inspect and adapt the way they work and support continuous improvement, to include customizing SAFe

• Engaging coaches and investing in the sponsorship and structures to support successful change management

• Embracing leadership and culture as crucial to any significant organizational improvement

Perhaps these points should be illustrated and emphasized more forcefully in the SAFe literature, but nobody I’ve met in the SAFe community is denying their importance.We have established that there are risks to providing too-pat answers to complex organizational challenges. Are there benefits from the SAFe framework’s comprehensive and prescriptive appearance? My experience is that there are.

For example:

BigVisible has observed that large enterprise clients often doubt their own organization’s ability to change. They reject case-studies because their challenges are “unique”, but often demand an illustration of their Agile end-state. Responsible coaches answer that a client’s future state will be emergent and non-deterministic, but the SAFe framework provides value because it helps clients see one concrete instantiation that probably supports many of their critical functions. SAFe’s clear and seemingly complete organizational archetype of Agile for large complex organizations reduces fear and trepidation. By illustrating a rich set of patterns proven effective in large enterprises,SAFe provides people confidence that they don’t have to invent every element themselves.

SAFe also provides an implementation template for getting a “release train” of teams rolling with a solid release-planning model. Giving clients confidence that SAFe is built on tested and proven structures that large complex enterprises have implemented successfully gives them confidence to move forward more aggressively. Many of us in the coaching community have long espoused release planning as crucial to program-level effectiveness. My initial reaction was that SAFe advocated release planning at an earlier stage of team maturity than I was comfortable with.In practice, though, I have observed the SAFe approach work as a forcing function to dramatically accelerate line-of-business planning,improve communication, and aid cross- team alignment. Like any pattern language, SAFe allows us to streamline communication and “get to the meat” of our process and structure debates by starting with a universally understood standard. Using known templates as a default or a position to offset from, helps us shortcut poor time investments, so we can focus our efforts on areas that reward innovation. I hope some of the points above have helped illustrate some of the risks of misusing a framework, as well as providing some practical insights to where and how SAFe has real benefits to large organizations attempting to scale Agile. Like any good craftsman, we have a wonderful variety of tools in our consulting toolbox.

I’m convinced that in the right setting, used by the right hands, SAFe is a tool that can provide great value to enterprises. In the next installment, we’ll emphasize the basics to have in place for successful scaling; the foundation of team practices and structures essential to support the scale and complexity addressed by the program and portfolio levels of the SAFe Framework.

Want more SAfe Framework Implementation Tips & Techniques?Join us for our upcoming webinar on December 13th, 10 a.m. PST/ 1 p.m. EST

“Hit the Ground Running: Design and Manage Your SAFe Implementation”

BigVisible Webinars CTA


Practical Systems Thinking: Don’t Let Inertia Become the Constraint

Congratulations! You’ve gotten to the fifth step in the Five Focusing Steps of the “Theory of Constraints”. That means you’ve broken the constraint in your system!

But, your work is not done. As a matter of fact, it’s just starting. You see, once you break a constraint in your system, a new constraint will always emerge. Yes, you elevated the throughput of your system, but, as you’ll see in this segment, you must be relentless about breaking the constraints that continue to emerge.

In Eliyahu Goldratt’s CD Series, “Beyond the Goal”, he discusses the dangers of inertia and what he means when he says ‘don’t let inertia become your constraint’. He’s referring to Internal Inertia, something we must combat against within our own team(s). In other words, don’t become content or complacent.

But, beware! There’s another form of inertia, one that is much more difficult to identify and overcome: External Inertia. It’s the “inertia” caused by the set “rules” within your organization, the “that’s the way we’ve always done it” mentality that may resist the changes you implemented when you broke your constraint. The challenge with these rules is that they were good, and even helpful, at one time, so people are reluctant to give them up. Teams realize that these directives were put in place to help the organization be more effective based upon the way it was operating. But now, they may not realize these precedents are no longer relevant since we’ve changed the game and the way we think about the system.

Check out this video as I expand on the concept. And if you missed any of the previous installments of “Practical Systems Thinking”, check out the “You May Also Enjoy” section below this clip.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Practical Systems Thinking: Elevate the Constraint

Practical Systems Thinking: Elevate the Constraint – The saga continues!

If subordinating to the constraint is the most challenging, elevating the constraint is the easiest…to get wrong. Elevating the constraint is the fourth step in the “Five Focusing Steps” of the Theory of Constraints, and all too often, teams do it first, before exploiting and subordinating. Sometimes we even attempt to elevate the system’s throughput by putting more resources on the project without even knowing where the constraint is in the system! (Does that sound like the Mythical Man Month to you?)

Elevating the Constraint is the first step that has us actually investing money in our system, so it would be wise to see if we can break the constraint by exploiting it and subordinating to it first. If you’ve broken the first constraint then move on to the new constraint. If the first constraint isn’t broken yet, then wisely invest by elevating it.

For this segment, I’m going to ask you to think a little deeper than just adding resources to the constraint in your project. I’ll ask you to look further into the constraint to understand what is really happening at the constraint to see what is constraining it. Check out this week’s video to see an example of what I mean.

Practical Systems Thinking: Elevate the Constraint

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.



Practical Systems Thinking: Subordinate to the Constraint

Subordinate to the constraint?? That doesn’t sound right! But that’s the third step in the “Five Focusing Steps” of the Theory of Constraints. It’s possibly the most challenging part of the process because it seems counter-intuitive and requires tremendous discipline when implementing it. Does that mean we’re “hitting the breaks” in this process? After all, “subordinating to the constraint” means that if you want to get more work through your system, you essentially have to do less.

In this fourth installment in the Practical Systems Thinking series, I’ll show you how introducing too much work into your system will cause inventory build-up in front of your constraint which, in turn, has a detrimental effect on your system. I’ll also show you how 100% utilization of resources in front of your constraint will cause you to lose your ability to exploit your constraint, ultimately reducing the throughput of your system.

Miss our previous installments? Check them out below, under the “You might also enjoy section”.

Want additional actionable tidbits that can help you improve your agile practices? Sign up for our weekly ‘Agile Eats’ email, with “bite-sized” tips and techniques from our coaches…they’re too good not to share.