In pursuit of better, not best

I realize that many of you already scowl when you hear anyone talk about 'best practices'. Instead of adding to that discussion, I'd like to share a short story with you about someone who influenced me to keep looking for better and to never assume that I've reached 'best.'

I can still picture Mr. Loewen leaning on the desk at the front of my grade 9 class and settling in for a speech. The tone of his voice and even his posture indicated that what he was going to say was important. I think I expected a lecture on the importance of the subject, paying attention in class, working hard at the assignments, or being respectful to the teacher. Or maybe he was going to give his 'outstanding student' joke - students who crossed the line would end up 'out standing in the hallway'. Instead, he confessed to us. He confessed that he didn't know it all. Of course I can't remember the exact words, but it went something like this:

"In this course I'm going to teach you what I know to the best of my ability. I'm going to tell you truths as I understand them today. But, someday you will encounter ideas and truths that might make more sense than what I have taught you in this course. You will discover that some of what I have taught you is wrong. When you encounter those ideas, embrace them. And even as you embrace those new truths, remember that you, also, might be wrong again."

Those words sat with me for a long time before I saw the wisdom in them and embraced them. They have served me well and taken me through some challenging times. Thanks Mr. Loewen.

Subscribe to Winnipeg Agilist by Email

Thoughts on Beyond Deadlines by Jabe Bloom

Background

In late 2012 when Dylan Smith suggested a blog challenge in order to encourage each of us to write more often, I quickly agreed. I don't find it easy to write but I love the thought process that goes into it and I was hopeful that some extrinsic motivation ($ and deadlines) would help me write more often. I'm still in the competition as long as I finish this post by midnight tonight so it looks like extrinsic motivation is "working" in this case.

And yet, as a proponent of flow in personal and work habits I find that deadlines sometimes seem to be the wrong focus. If we can prioritize and visualize our work effectively then we should always be working on the most important items - regardless of deadlines. Even if some of our items have legitimate deadlines we should be able to add that to our prioritization criteria. If you have ever played the getKanban game, their inclusion of Fixed Delivery Date cards for auditing deadlines illustrates one way to do this.

Beyond Deadlines by Jabe Bloom

I met Jabe and some of his co-workers at TLCLabs last year at various conferences. What makes them unique in my mind is that they courageously try out agile and lean ideas within their company. So when Adam Yuret sent along a link to Jabe's presentation "Beyond Deadlines" with the text "TLC spent a year telling employees not to set deadlines. We wanted to know, can you run a business without Deadlines?" - I was eager to watch.

Here are the notes I took from the video:

1. Deadlines as [temporary] extrinsic motivation
Deadlines have their roots in motivating workers who were thought to need extrinsic motivation in order to avoid slacking off. Jabe contrasts this view with Deming's view that extrinsic motivation (deadlines, fear, money, etc) can actually rob us of our intrinsic motivation. I did a quick search on Psychology Today and found agreement on this point - "External motivation, while sometimes helpful, can also undermine intrinsic motivation."

2. Deadlines as influencers of 'crap'
Jabe credits Jim Benson for the diagram at the right. Simply put - as your deadline approaches your options are reduced and you choose options to fit the deadline rather than satisfy your customer. As I've been watching March Madness this weekend the 35 second shot clock is a good reminder of this - as the shot clock approaches zero the players end up rushing their shots and miss at a higher frequency.

3. Deadlines are a lesser goal
"We are kept from our goal not by obstacles but by a clear path to a lesser goal" - Robert Brault. Deadlines are clear goals - this may nudge you to make choices based on the deadline instead of customer need.

4. Deadlines are a measurement of our estimating accuracy
Deadlines measure your estimating accuracy, not your project success. As the Buhler study from 1995 demonstrated, even with experience we are still inadequate estimators. If this is true then when we use deadlines we are increasing our rate of failure based on something that is potentially arbitrary.

5. Use the 5 Whys on your estimates
Some deadlines are legitimate and Jabe talks about creating an ad for the Super Bowl game as one example. He recommends doing a 5 Why assessment on your deadlines to find the real reason. If the deadline is only there as a motivational tactic, then perhaps you have other better options.

6. Flow as an alternative to deadlines
One of the advantages of kanban over iterations is that you don't run out of options for a particular item as it passes through your board. With time boxed iterations, as you approach the end of your iteration and haven't yet met your commitment, you start making choices that cause 'crap'. Flow enables multiple decision points which increases the options available to you and the satisfaction of your customer.

7. Their story
Yes, they actively worked towards abolishing deadlines for a full year and made it. The video only goes into part of their story and I wish he had said a little more about this. However, from my conversations with them I understand it was a pretty big hit with both their employees and their customers. One of their employees stated: "For us, switching to kanban was great emotionally, because we don't have to fail every two weeks." From a customer stand point they changed their release cycle from 6 months (with a list of promised features) to 6 weeks (delivering whatever was ready). Their customers appreciated receiving updates more frequently and the opportunity to provide feedback on features more often. As a company, moving towards flow also enabled them to introduce 20% slack time ("do what you think you should do - you are the expert") which they believe increased their overall productivity. A side effect of abolishing deadlines is that it helped them to find their real (and few) deadlines.

In Closing

Many of us use deadlines to motivate ourselves or our teams - they are easy to use and often seemingly effective. Given both the dangers and the alternatives as described by Jabe, I'm going to try to keep this tool in the bottom of my tool box. Please be patient with me if I give you a funny look when you ask me: "When can you have that done by?"

To end this post I'd like to take you back to the blog challenge with our bi-weekly deadlines.One of the members of the challenge dropped out earlier this year. His reason? He felt the bi-weekly deadlines were influencing his content choices and quality. The deadlines were influencing him towards 'crap'.

Further Reading

• Beyond Deadlines - Jabe Bloom
• How Deadlines can be Murder on Motivation - Psychology Today
• The Surprising Truth about what Motivates us - Dan Pink
• Deadline Dread - Psychology Today

Subscribe to Winnipeg Agilist by Email

It’s the system, not (and?) the people.

I live and work with two phrases in my head that are important to me:

“It’s the system, not the people” – Deming

 And, paradoxically:

“It’s all about the people” – a statement heard often at Protegra that we try to use to guide how we work together.

An event this weekend helped me to understand these seemingly contradictory ideas. My brother (as coach) and nephew (as player) are participating in the junior varsity (gr. 9/10) provincial basketball championships. Last night I was able to watch them play in the semi-finals and could see both of the quotes above at work.

“It’s the system, not the people”

After an exciting victory by my nephew’s team, I overheard a conversation between two neutral parties as they did a postmortem on the game. In their assessment they agreed that both teams were skilled, gave it everything that they had, and played with passion. The main difference between the two teams was that the winning team had a better defensive system – not better players, but a better system. While the opposing coach did his best to exhort his players to play smarter, take better shots, make better passes, avoid the red beads, and play harder defense, ultimately they were defeated by a better system. They didn’t lose this game because of “resources” (coaches, players and refs), they lost to a better system.

“It’s all about the people”

Let’s look at the game from another angle. It was my brother the coach (a person) who researched, introduced, and taught the system to the team. It was the players (people) who bought into and committed to playing within the system. Both the offensive and defensive systems used by the team are well chosen and effective because they depend on teamwork and collaboration. Their systems require all of them to act together – if one person steps outside of the system it breaks down. The systems do not rely on one or two heroes but on the team as a whole. The systems require people to learn together, improve together, and be engaged together. The systems are all about the people. A pretty neat life lesson for a group of gr. 10 boys.

So, yes “It’s the system, not the people”, and yes, “It’s all about the people.”

“We believe it’s all about people. We believe by systematically focusing on people, treating them as the heart of organizational systems, that success will follow for all.” – Protegra.

Subscribe to Winnipeg Agilist by Email

San Jose Budget Games 2013

"Whatever is the problem, community is the answer" - Margaret J. Weatley.

I've been reading some of Margaret's writings this week and her words have been ringing in my ears as I remember participating as a volunteer facilitator in the 3rd annual San Jose Budget Games on January 26. Somewhere close to 200 community leaders, politicians, city staff, and volunteer facilitators gathered to have conversations about the city budget priorities. This wasn't a typical town hall meeting where the city presents the budget priorities and community members gather at a microphone to voice their displeasure. Instead, 20 tables of 8-10 people gathered to play a version of Buy a Feature by Innovation Games. Through the game, each table was asked to wrestle with and agree on both where to spend the budget (more police? more library hours?) and whether or not to increase city revenues (increase sales tax? create a parcel tax?) to fund more initiatives. San Jose elected officials, police chief, fire chief, city clerks and others were available to answer any questions.

As a facilitator it was interesting to watch a diverse group of people talk to each other about priorities for their city. Here are a few observations that I found interesting:

• Though they didn't always agree, the game produced some great discussions.
• Disagreements at our table ended with increased understanding.
• The discussions were neighbour to neighbour vs. citizen to politician.
• I heard citizens talking positively about their city politicians ("I don't always agree with them, but I like their approach - they are serious about engaging us in helping making the city better").
• Many citizens were playing the game a second or third time - asking a community for help and then acting on their responses creates engagement and joint commitment.
• Relationships were built rather than fractured ... at a budget meeting!
• This approach to solving problems can create a better community, neighourhood, team, company, city, etc.

San Jose isn't the only group to start embracing a community approach to problem solving. I'm sure if you reflect on your own experiences you'll recall examples of community approaches producing excellent results. Wheatley describes several similar examples in her article "It's Time for the Heroes to Go Home" and in the agile community we've embraced this approach through self organizing teams and frequent retrospectives.

I don't know if I'll be able to participate in a future budget game, but I'll always be grateful to the city of San Jose and the Every Voice Engaged foundation (the non-profit arm of Innovation Games) for the opportunity to be involved this year. If we ever do this in Winnipeg, count me in.

Finally, along with this reminder to 'take it to the team', here are a few practical methods you can use to do so:

• Innovation Games
• World Cafe
• Retrospectives
• Lean Coffee

 (You can read more about the budget games in the Financial Times and Bloomsberg Business Week)

Subscribe to Winnipeg Agilist by Email

How to Prioritize a User Story Map

At the Agile 2012 conference, Serena Software surveyed attendees about their biggest agile challenge. Here was the top answer:

User Story Mapping Series

* How to Create a User Story Map
* How to Prioritize a User Story Map
* Tips for Facilitating a User Story Mapping Session
* Don't Etch your User Story Map in Stone
* User Story Mapping Tool Review – SmartViewApp
* Story Maps - A Testing Tool After All

I don't know how accurate their results are but prioritizing customer demand was certainly a challenge for me on my first "agile" project.  We created a backlog with some pretty large user stories including "Search for items", "Maintain item attributes", "Set costs for items and groups", "Calculate prices", "Run pricing engine", etc. We then proceeded to tackle each story in order (that's what you do right?). After our first five week iteration (!!) we had created the most beautiful search screens you could possibly imagine. Our users could search by any and all combination of attributes and display the results in multiple different ways - there was even a brilliantly developed screen splitter so you could see all the extra details of one horizontal row in a vertical list at the right of the search results. We were so good that we finished our iteration commitment early and started to add in some of the nice-to-have search functionality. In truth, we were quite thrilled with our results. It was only in later iterations that the pit in our stomachs started to grow. While "Search for items" fit nicely into an iteration, "Maintain item attributes" had a tougher time and by the end we had lost all hope for "Run pricing engine". We had incredible search functionality (low priority) and sub par costing and pricing (high priority). Oops.

Thin slicing to the rescue!

It is no wonder that when Jeff Patton showed me how to create a user story map and use it to create thin application slices to prioritize agile projects effectively that I was hooked. It should also come as no surprise to you that in subsequent projects when "search" comes up as a feature request I am the first one to slice that story ruthlessly! "Search for items" is immediately sliced thinly to "Search by item number" and put in the first release. The rest of the search functionality is sliced into similarly sized user stories ("Search by description", "Search by customer item number", "Search by vendor", etc) and initially moved to the bottom of the story map.

Then we continue to slice each column in our user story map so that we can build a thin horizontal slice of our app in a short period of time (days or weeks). "Enter member, spouse, and dependent information" is sliced into "Enter member name" (first release), followed by "Enter member address", "Enter spouse information" and "Enter dependent information" in later releases of the application.

Prioritizing by risk and assumptions

Once you get the hang of ruthlessly slicing your stories and prioritizing them effectively in your map, you may notice a lot of 'easy' stories initially rise to the top of your priority list. In the case of "Search for items" this is a good thing. However, it can be dangerous to do all the easy stories first. When we've drafted our map and are ready to start prioritizing I like to ask - "Where are the risky stories? Where are our biggest assumptions?".

In the project example above, "Run Pricing Engine" was our riskiest story. It had some really aggressive performance requirements and if we couldn't meet those requirements then there was no point in building the application. In this case, choosing the 'easiest' slice of that feature would be a mistake - we should look for a slice that helps us validate our assumption that we can meet the performance requirements. Additionally, subsequent releases should continue to focus on that assumption before we work on stories like "Search by vendor".

Applying Cynefin to prioritization

This week I read an excellent article by Liz Keogh called "Cynefin for Developers". The article is well written and can help us understand how to apply Cynefin to project prioritization. One of the domains in the Cynefin model is "Complex" which Liz describes as:

"When you start writing tests, or having discussions, and the requirements begin changing underneath you because of what you discover as a result, that’s complex. You can look back at what you end up with and understand that it’s much better, but you can’t come up with it to start with, nor can you define what “better” will look like and try to reach it. It emerges as you work."

"... This is the land of high-feedback, risk and innovation: generally stuff you’ve never done before, anything that the business are unsure about, new technologies, etc."

As you are prioritizing your map, pay special attention to any stories that may fit into the Complex domain. Since these stories may change the direction of your project, I'd recommend that you tackle them earlier rather than later.

Re-prioritize often

Remember that priorities can and should change throughout your project as you learn more information. On a recent project we had a few stories that were identified as 'mandatory' but the team agreed to prioritize them towards the end of the project. Near the mid point of the project we brought in some of our external customers for a small focus group. We did a quick demo of our progress to date and also asked them to help us prioritize the remaining stories. We quickly learned that some of the previously 'mandatory' stories were no longer important and removed them from our backlog. Without that feedback and the willingness to change priorities at any point of the project we would have contributed to the famous Standish Report phrase: "64% of features are rarely or never used".

On a related note, if re-prioritization is going to happen frequently, then there isn't much point in prioritizing your whole map initially. A good rule of thumb is to prioritize the next one or two releases only. Even though prioritizing a story map can be a simple and fast exercise, it may be wasteful to slice and prioritize everything at the beginning.

In Summary

My secret recipe for prioritizing agile projects is simply this: Roll out your user story map; add some thinly sliced stories; stir in some prioritization by risk, assumption, and complexity; rinse and repeat.

Subscribe to Winnipeg Agilist by Email