Transactive Memory and Agile: An Overview

I spend a lot of time studying individuals and teams in a quest to help them learn how to deliver more value. One of the most common failure scenarios I observe is that once organizations have reached a decent level of effectiveness, someone will leave and the whole thing will come tumbling down. I am not trying to suggest that turnover and change should be stamped out (I actually think it is healthy), but rather something else is amiss. Several years ago I was able to study the implementation of an agile scaling methodology in a Fortune 100 company. The study looked at quality, productivity, and cycle time across 15 product lines. In every case, the metrics fell during implementation (this was expected) then improved spectacularly, over 80% improvement in every metric, the year after implementation. Unfortunately, things got murkier when the consultants supporting the change were withdrawn and sent elsewhere. The metrics fell by 30 to 50% from the high watermark. I am not arguing that consultants should be permanently ensconced in any organization – it is unhealthy but rather something else is amiss. Recently I forgot to call my father on his birthday. My wife remembers things like special events and then clues me in…if she is around. This time she was not. The whats amiss in all three of these scenarios is a reflection of the risks of transactive memory. 

 

Our Stories Aren’t Getting Done: Taking on More Than Possible

One of the classic issues that pop up when teams chronically don’t complete work they say they will, in the time they say they will is that they are taking too much work at once. Being somewhat hyperbolic, I liken it to eating a very large hamburger (for example) in one bite. Even if it is possible to shove the whole thing in, it would be painful to swallow. I have facilitated more than a few retrospectives that discussed taking on more work than is completable in a specific timebox. Several of the reasons that generally surface:

 

SPaMCAST 562 – The Power of No, Real Planning, Essays and Discussions

http://www.spamcast.net

 

Direct Playback
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 562 features our essay on the power of saying no.  I firmly believe that unless you have control over the amount of work you take, you are asking for a trainwreck.  The problem is that saying no is often harder than being late or over budget.  

We will also have a visit from the Software Sensei.  Kim Pries is back to kick off September with an essay titled, Real Planning. While the actual plan might not be exactly what happens in real life, the act of planning is crucial. 

 

Agile Saying Competition: Day 2: Planning

Today we continue our six-day journey through six different categories of agile sayings. This is the competition to pick the best of each category.  The competition in our journey is an attempt to deliver a bit of festivity to the yearend (perhaps a bit of an homage to the college football playoffs also). We all use metaphors and sayings to rally the teams as they embrace change, the competition provides a platform to up our game. 

Today’s five sayings addressing the topic of planning were contributed by agilistas (and some agile detractors). When I was first introduced to agile, I briefly made the mistake of seeing the lack of a big upfront plan as the absence of planning.  Experience and practice teach us the power of distributed and continuous planning over the big upfront plan.

A reminder of the logistics:  On December 26 and 27th we cross the categories for two semi-final polls with the final poll on December 28th.  The ultimate agile saying, at least according to the SPaMCAST community, will be announced on January 1st!

This poll and all of the first round polls will be until 25 December 23:55 (vote early and often – 🙂 )

 

First Round Entries:

Day 1: Fail Fast and More – https://bit.ly/2A4UxRc

 

Monte Carlo Analysis – A Brief Rationale For Use In Agile

What is the possibility

One of the most often used saying in agile is that yesterday’s weather is a good predictor of tomorrow’s performance. I have lived in Louisiana where if you blink the weather will change. I currently live near Cleveland (and I like it), and in 2014 the temperature went from 39 F to -11 F in less than 24 hours. I went running on both days; they were very different. Even if I grant that yesterday can be an important indicator of performance tomorrow, a sample size of one does not capture the degree of variability that might be present in the environment. Why does anyone care about variability in performance? As suggested in Agile Metrics: An Interlude, leaders have not stopped asking what they can get, when they can get it and how much it will cost type questions. Even if they don’t ask all of those questions there will be questions about budgets. These are not evil, unagile people; they are business people that need to plan things like cash flows and making payroll. Answering when they can deliver product to the market or when a change to the HR portal will be made are important questions. Just relying on yesterday’s weather is not always sufficient and there is no Oracle of Delphi that provides a single, unambiguous answer to any of those questions. The answers are always a range. In most circumstances, each possible outcome is more or less probable than the next. Uncertainty makes it difficult to have a conversation about when, what and how much. Monte Carlo analysis provides a way to handle answering questions with significant uncertainty in the inputs that influence the outcome of the work so you can have the difficult when, what and how much type conversations.

 

Frequently Asked Questions: Can I Resize A Story If It Is Harder Than We Thought?

I can’t resize the run even if is straight uphill both ways!

The question of resizing a story has many variations based on the rationale the asker is using. Rationales include stories:

• that the work is harder,
• take longer,
• for which someone else is going to do the work, or
• on which people missed the boat entirely.

If the answer given is no, the immediate next question is often “If not, then when does it make sense?”  Let’s start with the easy part of the answer.

 

Iteration Planning Meeting Work Preparation: Simple Checklist

Preparation is key to reaching your goals.

Successful and efficient planning of any sort represents the confluence of preparing the work to be planned and proper logistics. Earlier in this series on planning, we reviewed the basic logistics needed for a planning event and defined a simple checklist.  While both are important, preparing the work to be planned requires more effort.  Preparing the work for planning requires knowing the capacity of the team and grooming the work items (stories, requirements, support tickets and/or defects).

 

Iteration Planning Meeting Logistics: Simple Checklist

Logistics Are Part of All Meetings

Planning meetings are not terribly glamorous.  They are, however, an important first step in effectively delivering value for any sprint or increment.  I have developed a simple checklist for preparing for a planning meeting (we will explore a simple process in the near future).  Agile planning events couple the discipline of saying what will be done and then delivering on that promise with the need to embrace the dynamic nature of development and maintenance.

 

Product Roadmap: A Roadmap for Every Answer

Left and Right

 

Product roadmaps are a tool used to visually present a business strategy. Roadmaps serve multiple goals. The goals of roadmap development generally are varied, including not only the ultimate roadmap itself but also the journey to develop the roadmap.  Typical goals include:

 

Budgeting, Estimation, Planning, #NoEstimates and the Agile Planning Onion

There are many levels of estimation including budgeting, high-level estimation and task planning (detailed estimation).  We can link a more classic view of estimation to  the Agile planning onion popularized by Mike Cohn.   In the Agile planning onion, strategic planning is on the outside of the onion and the planning that occurs in the daily sprint meetings at the core of the onion. Each layer closer to the core relates more to the day-to-day activity of a team. The #NoEstimates movement eschew developing story- or task-level estimates and sometimes at higher levels of estimation. As you get closer to the core of the planning onion the case for the #NoEstimates becomes more compelling.