Do unmade decisions cause you stress?
- Decision Time, or is it?
At the last Lean Software Meetup, Jeffrey Fredrick quoted a line in David Allen’s book Getting Things Done book that stuck in my mind: “Decisions not made cause stress.” As someone who has been on and off the GTD wagon for the last 4 years, this made sense to me. And yet and as one who practices Lean thinking, this has been causing me some degree of a dilemma, as a core Lean principle is deferring commitment. Maybe you can help me sort this out.
The idea of Allen’s book is that there are many open loops in your life. You may have 503 email messages laying in your inbox, a garage full of boxes from your last move, a shoe box full of story cards from last week’s user story workshop, (and my personal favorite) a large heap of easel pad paper with multiple facilitation sessions worth of stuff. What causes you stress is not that you have this stuff out there, but that you haven’t decided what you want to do with it. In GTD lingo, it’s “unprocessed stuff”. Each time your mind “reminds you” about this stuff, it causes you stress, because you haven’t decided what you are going to do it. Like rubbing a cancer sore in your mouth, it causes a little bit of psychologically resistance each time your mind passes over this stuff. You’re mind says: “You need to decide what to do with your mountain of junk in your garage.”
Once you recognize this as a source of stress, then Allen advocates making executive decisions about this stuff so that you can live more flexibly and responsively to new input. There is a process of capturing and making decisions in handy flowchart that appeals to my inner geek. More than just putting more systems in my life than are necessary, it generally makes things better for me. This is especially true for me given my tempermant.
Four years ago, I was a stressed knowledge worker. I had a high volume of incoming stuff that caused me a lot of angst. I adopted GTD and things improved. What gives?
Personality Typing, such as Myer’s Briggs, gives some insight. As a type Perceiving (INTP), I tend to be more comfortable when options are open. Those who are Judging temperments (not judgemental) tend to feel comfortable right after a decision is made. I recall a recent example where a colleague of mine who I suspect is a J, was very tense before a decision was made on the CMS decision of choice. When the decision was made, he was very relaxed, congenial. So, it may be that for the types J, they are stressed at unmade decisions. Those with personality preferences P, like me, are stressed when I’m forced to make a decision, which causes me to put things off.
Therefore, as a P, Allen’s book represented a light at the end of a tunnel for me. Suddenly I was making decisions about my voicemail messages, my overflowing inbox and personal life with ease, before it got too late. While this was a little unnatural, that dentist appointment was scheduled, the conference booked, the retrospective occurred without a hitch, my mother was phoned and happy. And much of my angst over email was no longer plaguing me, thanks to inbox zero. I was generally getting more of the administrivia done in less time than I used to so I could focus on the stuff I loved.
- Are you committing too early?
OK. So this has generally been a net benefit for me personally. But what about this the lean notion of deferring commitment, last responsible moment, real options, etc? This concept is essentially the idea that it’s unwise to close off an option early, because options have value. Like a pilot who is flying to Ohare during a snowstorm from Seattle. She knows that the last responsible moment is when she is over Denver. Deciding early to divert to Detroit is unwise, because things may clear up. Your passengers would value making their other connections. But deciding after Denver would be unwise, “the last irresponsible moment” because you are committed to one action or the other. Options have value and exercising them early causes you to loose potential value.
Does GTD and the habit of deciding before you have to, cause me to make poor decisions in the here and now for the benefit of feeling less stress, when I could be better off delaying those decisions when I had more information? Does this occur in boardrooms all across the US where management make decisions because of the generally accepted principle of “no decision is worse than indecision.” Or in teams for that instance, where we make decisions on API’s, languages and databases too early, because having an unmade decision was causing our management britches to get in a bundle. What’s a girl to do?
One faint glimmer that comes to me is the idea in Allen’s flowchart again. Not all decisions are the same. There are the 2 minute actions that you can quickly dispose of, like a “thanks” email or a “Yes, I will be home for dinner”. And there are those things you can delegate (either up or down). Taking a moment to decide that you don’t have to decide is a net benefit. And what about those decisions that may not be appropriate to make now? The important thing, he advises, is for these decisions to be deferred in calendars, tickler files or other trusted systems so they can be evaluated at the appropriate time. This could be done for conference deadlines, dinner plans, or deadlines to place orders for hardware for your new load balancer. As long as you will be certain to revisit that decision at that time, and your information is correct on when you need to revisit the decision, this type of thinking could reduce stress and simultaneously defer commitment, enabling you to make decisions when you have the most information.
Will this cause you to lower your anxiety about unmade decisions? Maybe, maybe not, depending on your temperament on the P/J scale. Will it cause me to justify my natural tendency to delay what I need to do, aka the student syndrome, cauing me more long term stress? I think that as long as you give yourself a reasonable buffer and use your trusted systems to remind you when you have to decide (whether it is a physical tickler file, or an iphone alert, or a google calendar event), it shouldn’t.
What do you think? Have you had a situation where you had less stress and made better decisions by deferring commitment? Or have you had a situation where it paid to make decisions early, before the last responsible moment?
Good to Great now not so Great
Esther Derby tweeted a great question that stuck in my noodle the last week: estherderby: skimming Good to Great. some profiled companies ain’t so great anymore.
Since Good to Great provided great inspiration for me, this caused me some consternation. Circuit City, Fannie Mae, and Wells Fargo aren’t doing so well. Turns out, Esther isn’t the only one asking this. As Peter Levitt (of Freakonomics Fame) asks, and blog author Peter Galuzska points out, it’s not exactly fair criticizing Jim Collins for things that happened 8 years after he published his book, since he was looking at historical market performance. True, but makes you wonder at taking the advice in the book.
Good to Great analyzes 11 companies that had average stock returns, and then had a dramatic jump in returns after a certain inflection point. It analyzes them for patterns in the data and comes up with a number of principles for what catapulted them to greatness including: level 5 leaders — leaders with personal humilty and great professional will; a hedgehog concept — focus on the intersection between the three circles of what you are best at the world at, what you can make money doing, and what you love; turning the flywheel — iterating on your plan so that you evolve into greatness; the stockdale paradox - having absolute faith you will survive and simultaneously confronting the most brutal facts of your current situation. Then I recalled that what Jim Collins states at the end of the book is that what may take your company from good to great is not what will make it an enduringly great company.
For those, he points to the Built to Last book principles:preserve the core ideology and stimulate change, create BHAG’s (Big Hairy Audacious Goals) — like the 747 at Boeing; don’t tell time, build clocks — build a lasting organization, having a core ideology other than maximizing profits - like 3M’s innovation culture or Nordstrom’s cultlike focus on customer satisfaction. These businesses from Built to Last are still enduring, not all are great…but they all endure. I wonder if Circuit City and Fannie Mae had followed these principles if they would have survived. Did Circuit City not follow its core ideology when it fired all its senior sales people and replaced them with people who knew nothing about their products? Or was Fannie Mae the victim of the unforeseeable challenges in the lending market?
It’s hard to know without doing original research of what went wrong. That is one of the great things about these books is that they are built on rigorous research. This is unlike many of the avalanche of business books based on success stories that have little or no data to back them up, like Who moved my cheese. Some have rightly argued that they suffer from selection bias, selecting the winners from a group of companies and finding what was common about them, while not looking for those same factors in the businesses that failed. Yes, this is true, and is the challenge with any research where you are trying to uncover causality without using the scientific method. It’s hard to create a true scientific test when there are human lives at stake. All you can do in the real world is experiment, see what works, and then measure your results. Hmmm…this is starting to sound a lot like Scrum to me.
So what does this have to do with Software Project Management? These books provide useful ideas of what you can do in your organization with teams to get unstuck. For instance, it gives you a lesson for how great leadership behaves to encourage greatness. A level 5 leader looks surprisingly like a servant leader in Scrum (personal humilty and a high degree of professional will). Or building a core set of values that you don’t change and experimenting with everything else (like adopting team values in your project charter ).
So, while the underlying research may be called into question, the ideas in these books stick, because they make sense, because they are sometimes paradoxical, and they are based on some research. I wonder what a similar research project would be like for Software Projects? Is this analysis similar to the Chaos report, where researchers look at common factors for failed and successful projects and try to isolate those factors? If we wanted to study what a successful project was what factor would we use to measure success? We couldn’t use market returns. Traditional measures like “on time, on budget on scope” also fall flat, as projects where that was the case, called challenged projects, are often a market success. What do you think?
Action your impediments daily for continual improvement
ScrumMaster actioning impediments directly after the daily standup.
Here is a very clear blog article by Chris Sterling outlining the rationale behind capturing and assigning actions for impediments at the daily standup. He explains the connection to the continual improvement philosophy of Kaizen. Spot-on, Chris.
We’ve used this technique in teams I’ve worked with, along with longer bi-weekly retrospectives to drum up the individual, team and organizaitonal impediments that stand in the way to high performance. This is a way to radically improve their team performance and mitigate risks early in a project. Whether you don’t have a continuous build system or a team member is out due to an emergency medevac for his pet poodle, these things all deserve space on the impediments wall. By making the rule that there must be at least one impediment a day, and by assigning impediments to individuals for daily resolution you drive accountability for continual improvement to the members of the Scrum team. It also builds trust with teams for the ScrumMaster, that you are doing your job in clearing roadblocks for the team. I encourage all Scrum teams to capture their impediments at daily standup in this way.
Peter Gibbons and his pals 'actioning' an impediment.
This part of your daily standup should feel energizing. You should leave feeling like things are being done, like in some small way, things are better. It should not feel like a catalogue of all the ways your team and organization suck. You may recall the office space scene where they take the life-sucking fax machine to the field and beat it to bits. It should feel like that. Like you are liberated and empowered to remove these obstacles today. (Note, I don’t condone violence to ‘human impediments’, they must be resolved in a different way.)
A way to consider this is to focus on the next action needed to resolve your impediment. List the next physical verb step on your impediments wall that you need to do in order to eliminate your impediment. Do you need to go to Boeing Surplus to buy cheap hardware? Do you need to get an appointment with the CEO to lift the travel restriction so your test team can have face time with your dev team?
Pay close attention that you are avoiding all yak shaving activities. It’s better to do something OK today than do something perfectly tomorrow. This applies to impediment removal also.
Leading from the Middle
“The Key role of middle management is reinvention.” Tom DeMarco
Often I hear of Agile Adoption best occurring top down. Salesforce.com did that, from zero to Agile overnight. Other times I hear about bottom up Agile , or Agile in “Stealth Mode”. for a development team is tired of death-marches, a bottom up agile transition can be effective and motivating. This was how most Agile Adoption occurred 5 years ago when I was learning Agile.
And I rarely hear about Agile Adoption from the middle. Yet this is where, from my experience, change typically comes from. This is due to the fact that your middle management is typically where you have slack in a traditional organization. Slack is where you get your adaptability, because it is there that you have the bandwidth to try new things and aren’t under the optimization and efficiency pressure. If an organism or organisation is optimized, then it will be unable to change. Like the Cheetah who is far too specialized to adapt to new environments or prey, it will die off. Humans, however, can adapt to many environments because they are not optimized at any one thing, (except arguable solving problems and using tools).
Middle management has a role even in top-down and bottom up adoption. While they are typically directing operations and ongoing activities, they are the ones who are in charge of implementing change. As the Harvard Business Review states “First, virtually all major strategic initiatives have to be carried out by the middle managers.” In a top-down Agile adoption, while upper management might fund an adoption or read the “The Agile CIO” whitepaper they will need to ask someone to “go do it”.
This is hard work, in my opinion, especially in a situation where you are learning how to become a servant leader and drive change in the organization. This is why I think Scrum prepares teams particularly well for the role of change agent, as a Scrum Master is in charge of serving and protecting the team, which after the team gets its house in order moves to getting the organization’s house in order to support the team.
In the case when Agile is done in stealth mode, the team is doing the hard work of change. However, you need a line manager who interfaces with the other parts of the org, protecting the team while Agile is in its infancy, and heralding success when it has proven its value. This is where a good middle manager will be able to network with other middle managers, directors etc and socialize and herald change through the organization. Hallway conversations can reduce fear about the new “threat” and familiar faces can introduce it as a new option worth exploring. Again, a key element of this is adopting the courage to try new things and introduce change, without fear.
When I was first learning about Agile, I had a terrific manager (Philip Ljubicich) who empowered me to try new things and managed by exception. His motto was “If you’re not making mistakes you’re not trying hard enough.” A Microsoft vet from the very early days, he understood the concept that the minute you mange by methods, you’ve created a system that can’t cure itself. Microsoft, despite all its faults, has created a culture that believes it is anathema to tell your development teams how to work. It has kept their organization adaptable to many changes in the tech world for the last 30 years.
When I discovered this Agile thing, he encouraged me to try it out and see what worked. We tried it, it worked, adapted it and achieved great results. My point here is that had I not been there, had the capacity to learn and the support to try new things, we may have never tried this out. Only because I had a great manager, and because I had the slack to be able to adapt did we change course. If you’re organization doesn’ have managers like Phil, then your job is harder, which is why pilot projects where you demonstrate that Agile is safe and “we’re not switching to anything” until they prove their worth are a good idea. It’s easier to support what I know has worked in our organizaiton than a new untested theory.
In the nineties there was the empowerment craze of flattening org structures, of leaders with inspired vision and teams who shared that vision. People were doing trust-falls and climbing walls and holding hands and singing kumabya. Middle management was seen as waste. Yet in this craze to flatten org structures organizations they flattened their capacity to change.
Toyota, which has shown itself to be remarkably resilient, past four recessions and the oil crisis, has a surprisingly deep org chart, with many managers for each of its employees. These line managers, however, aren’t career managers, they are those who have great technical expertise in the teams they manage. Why is this important? What happens when you have a spike in the work for a production line, or have a problem that you need to solve? This can go to the middle management core, who can help to eliminate impediments and educate and advocate for their teams throughout the organization.
Of course, the culture of middle management must support these changes, and have the courage to try new things. Otherwise, middle management can often be the biggest impediments to successful adoption, as they work alone, try to cover themselves so they rise to the top and otherwise try to optimize their own organizaitonal silos. Great companies have their middle managers frequently working together, learning and sharing ideas in a culture of collaboration, so they can achieve the strategic objectives of the top brass.
Tags: agile, middle management, Scrum
“Hitting the wall” with your Agile Adoption? Try adding technical practices…
This is a great post that uses the familiar metaphor of the gym and physical fitness to apply to adopting Agile. I’ve seen the pattern described here too often.
Developers start out the first three sprints and produce production ready software every iteration. It seems like everything is going well. Then under the gun of the ScrumMaster to keep their velocity high, they build up technical debt (like sprinters developing lactic acid) by not paying attention to technical excellence and practices that will maintain a sustainable pace. This slows their speed to a halt until they clean up their technical practices and adopt test driven development, continuous integration, mercilous refactoring.
The question for me is not whether or not this pattern occurs, but how to best introduce Agile so teams can recognize when it is happening and address it.
On the Scrum side, folks like Mike Cohn suggest introducing Scrum first (using the iterative or requirements first pattern described in his outstanding Agile Adoption presentation). This has the advantage of allowing the team to self organize around the practices needed to maintain agility.
On the XP side, folks like James Shore recommend introducing the 12 XP Practices first (Mike Cohn describes this as “Technical Practices First” Pattern). The tradeoffs to Jim’s approach is that it is costly to start with all 12 practices from day one. Teams may reject the approach altogether, while getting none of the benefits of the practices. But the teams that do will have sustainable pace and agility. The benefits to Iterative first or requirements first are that the teams learn how to self organize and undergo the cultural change necessary for bottom up commitment based planning. The downside is that somce Scrum is silent on engineering principles, and focuses on developing a self healing system rather than prescriptive practices. The down side to this is that teams may fail. Yet if they are using the retrospective and sprint review effectively, however, effects of failure are minimized (since they can inspect and adapt) and teams will have the added benefit of becoming a self healing system.
My experience is that the end state of having Scrum teams that us XP is a great combination. The paths to getting there are varied, and I’d rather a group learn how to think for itself then think implementing a set of practices will make them Agile. It’s the mind set shift to Agile principles that is important in my opinion, not the discrete practices used. This prevents Agile and Scrum from becoming yet another prescriptive methodology that says “do these steps in these ways and you will be guaranteed success”. What do you think? Have you experienced the pattern described above?
The connection between sailing and software
I wrote this post about sailing “inside” vs “outside” the boat. I learned much from participating as a crew member on a sailing team. It positively influenced my work with software teams, as I’m sure any team sport would.
Bay Area Agile Philanthropy Group
A group of folks interested in using agile values and principles to give back to the community is going to meet in January to charter the Bay Area Agile Philanthropy User Group (BAAPUG). This will be on January 17 at Tacit Knowledge headquarters and we will define the community, the mission, vision and values of the group. If you’re interested in attending the chartering meeting, or discussion what we’re about further, you can join the Yahoo! group here. This group is based on inspiration from Bob Payne at Code Green Labs, creating events where people could both participate in an agile project and help out a non-profit at the same time.
Tags: agile, philanthropy
How will we demo?
If you are struggling with concrete enough acceptance criteria, acceptance criteria that doesn’t specify the “how”, just the “what”, one technique that I find especially helpful is specifying “How will we demo?” to the story. This usually puts the product owner and the team in the right frame of mind for what we’re getting at with acceptance criteria something both specific and actionable. For instance, if you are designing a shopping cart, the question “How will we demo this” may bring up a discussion of one book from the catalogue being searched for and added to a shopping cart and displayed for view. Typically I’ll have this as part of the template for a story card. Part of the beauty of this method lies in the act of imagining what will count as done in the future. There is something about the act of forcing humans to “remember the future”, of what the screen or web service will look like in two weeks during the iteration demo, that helps substantially when trying to get enough detail to estimate or commit to a story.
Tags: Scrum, sprint planning
Restickable Glue Stick - Another reason 3M has a stranglehold on the Scrum Community
I like 3M post-it notes for sprint and release planning. It makes it really easy to have multiple people interact with stories and tasks. Unlike electronic tools, I don’t become a bottleneck for planning. However, I’m not against electronic tools. In fact they make sense for distributed teams and for backing up data that is on cards. So, what’s a girl to do?
3M Restickable Glue
This is where the 3M restickable glue stick comes in. It’s like regular glue stick, except you can use it to make anything into a repositionable sticky note. This means you can print your backlog from Excel, Google docs, Rally, VersionOne, etc. onto paper sheets or Avery card stock, slap some restickable glue stick on each story, cut them out and stick-em to the wall. When the product owner wants to change priority on a story, just pull it up and move it and stick it where you want it. Rather than hard to use clear Scotch tape, which is hard to unstick, or bright blue painters tape which may cover your story card, this is hidden and easy to use.
One stick of this stuff lasted me about 10 sprint planning meetings.I recommend a stick in every Scrum Master’s kit.
In a later episode, I’ll explain how I like to print out my backlog to Avery card stock to make planning easy.
David Anderson Speaks at Bay Area APLN
I attended a special meeting of the Bay area APLN chapter. David Anderson gave a talk on his recipe for success with Agile. Here are the notes. It was a good talk. I especially liked his description of how he pulled his development teams in to an all hands meeting on his second day on the job to give the teams permission to not write bugs any more. That is great servant leadership.
Admission Ticket for Quality Work
This reminds me of a similar struggle I had once with an individual on a development team when I was a team lead. The team wanted to try TDD and he was very opposed. He was the technical lead on the team, and we had a good relationship. After trying various techniques, tutorials, pairing with those who knew TDD, an “intervention” meeting with upper management, I realized that it wasn’t the lack of knowledge or clarity around our support for for TDD that was the issue. So in our one on one meeting, I asked him what is holding him back from endorsing this. After a long while of discussion, it came out that he felt that using TDD would slow the team down, and we wouldn’t deliver as much value to the client and might miss the date.
Aha! There was the tyranny of the schedule rearing its ugly head again. I realize that I had put him in a position where he had to both A) be in charge of the technical quality and B) was responsible for hitting a date with a fixed amount of functionality. I was the problem! So, rather than go into argument about why TDD is a good idea (he knew it was, but was under an impossible iron triangle problem) I told him that he was no longer in charge of making us hit the date. He was only in charge of delivering high quality software. I would take care of the delivery problem.
Rolling the Dice on Quality
And you know what happened? The team embraced TDD, quality went up and we went faster because we stopped having to track and fix bugs from previous sprints. This all came back when David was discussing his slide on Giving Teams a Permission Slip for Quality.
