Running a Positive Retrospective (and avoiding a gripe session)

A few times recently I've been asked about retrospectives - specifically how to keep them from becoming a gripe session. Here are a few things that I've found effective:

1. Start with the positive 

While we certainly want to talk about and address any issues, I like to talk about the positive things that have occurred during the last period before we delve into things we might want to change. I haven't yet been involved in a retrospective where the list of positive things wasn't long. This helps set the tone for the rest of the retrospective.

2. Wording matters 

I still have strong memories of watching Linda Rising run a retrospective for the Agile Vancouver organizing team in 2010. The words she chose as facilitator were powerful in keeping the retrospective positive yet useful. Instead of writing down "what went well", participants were asked to complete the phrase "it was great because..." (see the full quote and story at the link above). Instead of writing down "what didn't go well", they were reminded that no process is perfect and to write down "what they would do differently the next time". This simple re-wording of the phrases is powerful.

3. Every voice is heard 

If you've met me in person or even just through this blog, you probably know my passion for silent brainstorming. Generating in silence and discussing out loud isn't just a great way to get more ideas on the table, it is also a fantastic way to make sure every voice is heard. We've all been at retrospectives where one or more people with loud voices carry the conversation and the ideas. That isn't fun and doesn't encourage a positive atmosphere.

4. Build up Trust 

Using the 3 things above have shown themselves to be important in building up trust but sometimes you need to go a little farther. With new teams I've found that walking through Norm Kerth's prime directive can be a helpful way to eliminate blame from the discssion. They don't even have to believe the prime directive is true, they just have to act as if it is true for the period of the retrospective. I have found this pattern to be important to building up trust over time.

5. Do the (small) change

Finally, the point of all of this is to find ways to improve. If your team is having positive discussions about change and then doesn't follow through, the retrospectives become a waste of time. One simple way to make sure the change happens is to put the action items into your backlog and then start off the next retrospective by reviewing them to see if they were done and if they were helpful.

All the best in making your retrospectives more powerful by making them a positive experience. Feel free to add your tips in the comments.

Subscribe to Winnipeg Agilist by Email

Don't Etch your User Story Map in Stone

I was having a chat with Adam Yuret last week about user story maps. A concern that he expressed and others have voiced is that by putting your ideas into a user story map it might discourage you from changing the map as you start delivering the stories and learn more information. He's right - it might and it probably does. Kent Beck recently expressed a similar concern about product roadmaps on twitter.

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

So, here is your reminder that your map isn't just a list of features, but is really a list of unvalidated ideas. Whether you are working on a startup or an enterprise project, you begin with a list of questions or assumptions. Here are some examples:

• Will anyone use it?
• Will anyone pay?
• Does anyone care?
• How will we make $?
• Can we build it?
• Do we understand the problem?
• Will this solve the problem?
• Will it perform adequately?
• Will it integrate with other applications successfully?
• Can we build this with the budget & schedule we have?
• What is the best architecture for this project?

When you build and prioritize your map, you should be doing so with these questions in mind. As you resolve each of those questions, your map should change. It is one of the great reasons to put your map on the wall using post-it notes instead of putting the map into a tool - post-it notes are easy (and fun) to move. (Aside: Yes, there are sometimes excellent reasons to put things into a tool.)

Two quick stories to illustrate:

At a recent Agile Winnipeg event a local company (UnionWare) told a story of how they are using story maps. They had an idea for a project and quickly built a story map around that idea. At their customer conference they reviewed their ideas and realized they had missed the mark. They quickly (and easily) adjusted their map to confirm with their customers the new priorities and direction before they had even started building anything. The map itself was enough to help them walk through some of the questions above. As they told this story, their CEO recounted how he thought to himself: "This visualization stuff, it's going to be good."

For a project that I worked on this year we built a large map outlining all of the stories. We spent time going through the map with our customers slicing, scoping, prioritizing, identifying risks and assumptions, etc. We were pretty proud of the result and eagerly started delivering. As we started working on the first small release, we quickly realized that the answer to one of the main questions "Can we build this with the budget & schedule we have?" was "no". At this point, we had conversations with our users and sliced, scoped, and prioritized even more so that we could deliver something that would still meet the goals of our upcoming deadline.

In summary, "You cannot plan the future. Only presumptuous fools plan. The wise man steers." - Terry Pratchet. Don't etch your user story map in stone - build it with paper and expect to change it as you learn.

Subscribe to Winnipeg Agilist by Email

Visualizing Retrospective Priorities

We tried a new retrospective prioritization/voting technique this week that worked really well. After we had generated and discussed all of our ideas for improvement, it was clear to me that there were several excellent ideas and it would be hard to use our regular voting technique to single out one or two. In fact, it seemed clear that there were several ideas that should all be done and were somewhat related. I decided to try a technique in order to visualize the priorities, grouping, and weighting of the ideas.

I drew a line on the whiteboard from the bottom right to the top left and put all the ideas we had generated in the middle of the board. I then asked the team to approach the board and move the items they believed would have the most impact to the top left and the least impact to the bottom right. Yes, I was a little worried about the priming effect of having everyone voting together but I decided to ignore my own advice this time.

After the post-it notes on the board 'settled into position', we held another brief discussion to confirm the position of the ideas. It was clear that there were several high impact ideas on the board that needed to be implemented right away and some interesting clusters formed at the top left. The position of the post-it notes also visibly identified the ideas that the team thought would have a lower impact and could be dealt with another time.

The final confirmation that this visualization of priorities was effective came later that day - the team met and started implementing their ideas.

P.S. Yet again the 'take it to the team' approach resulted in a better solution than the ones I had envisioned prior to the retrospective. #TeamGenius

Subscribe to Winnipeg Agilist by Email

Q: Why Silence? A: Priming.

I'm a big fan of using silent brainstorming in order to generate ideas as individuals before processing those ideas as a group. "Priming" is yet another reason why using silence is important.

System 1 & System 2.
(Not to be confused with Thing 1 and Thing 2)

I'm currently reading Daniel Kahneman's book "Thinking, Fast and Slow" - a behavioural psychology and economics book that describes his research on how our mind thinks. In the book, Kahneman describes the two systems that make up how we think. System one is the unconscious, fast, intuitive, relational thinker. System two is the conscious, slower, lazier, and more logical thinker. For example, when I ask you what 2+2 is, system one jumps in and gives you the answer of 4. When I ask you what 453 * 23 is, system two jumps in to help you calculate the answer.

One of the experiments that Kahneman describes demonstrates how you can 'prime' system one and influence its answers. The experiment asked people to look at one word and then fill in the blank in a subsequent incomplete word. The first word they were shown was either "Eat" or "Wash" and the second incomplete word was "So_p". When shown "Eat", system one's relational thinking kicked in and people more often said "Soup" for the second word. On the other hand, when shown "Wash", system one more often produced the related word "Soap". Showing the first word to the participants 'primed' system one and influenced it to think of a second word that was related to the first.

So, if you start a brainstorming meeting with "What can we do better? My idea is [X].", you have now primed people to think about [X]. However, if you let people generate ideas on their own first you will start with a larger base of ideas to work with. Once people have written down their own ideas [X,Y,Z], saying those ideas out loud will allow system one to find relational words on the whole set rather than just one idea.

Generate ideas in silence, process the ideas out loud.

References:
- Daniel Kahneman's Book: Thinking, Fast and Slow
- Slides and video from my related talk: The Silence of Agile

Subscribe to Winnipeg Agilist by Email

Facilitating a retrospective with 50 people in an hour

As one of the volunteers at Agile 2012 I was honoured to be asked to facilitate the volunteer retrospective.

There were a few constraints that made this retrospective challenging. First, due to our volunteer responsibilities we had just under an hour to eat lunch and complete the retrospective. Second, there are about 50 volunteers - allowing everyone to have a voice in such a short time frame would be a challenge. Third, it was important to all of us to celebrate the things that went well and also give a clear, prioritized list of ideas to future volunteer teams.

After discussing the constraints and various facilitation options with some of you, here is what we did:

1. Instead of building a timeline of our experiences we held the retrospective in our volunteer room. Throughout the week we had plastered the walls with our schedules (including happy/sad faces), guidelines, issues, ideas for improvement, etc which then served as visual provocations for the retrospective.

Picture courtesy of Adam Yuret

2. We used silent brainstorming liberally in order to speed up the retrospective while still including every voice. In general we followed the Rising Patton Fusion retrospective model that combines silent brainstorming, silent grouping, and silent voting.

3. We split into 5 groups of 10. Each group would perform a retrospective step together before sharing their results with the larger group.

4. The two major prompts we used in the retrospective were:

The combined 'greats'

- "It was great because...". Each table wrote these in silence, read them out loud to each other, grouped them in silence and then named the groups. The named groups were then shared with the rest of the tables and consolidated into one larger list.
- "Do differently". Once again, each table wrote these in silence, read them out loud to each other, and then voted in silence. The top 3 items from each table were again shared with the rest of the tables and consolidated into one larger list.

5. Finally, we posted pictures of all the results (yes, every single post-it note) on the Agile Conference Volunteers Facebook page for later reference and comments.

It was a lot of fun and seemed to work well given the constraints. We achieved our goal of giving everyone a voice in a short time period, celebrating what went well, and also producing a nice list of actionable ideas for next year. Anything you would do differently?

Subscribe to Winnipeg Agilist by Email

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

Golden Nuggets from the Innovation Games Summit

My friend Chad Holdorf describes golden nuggets as those practical things you learned from a conference that you can use on Monday at work. After attending the Innovation Games Summit this week in Santa Clara here are six golden nuggets I'd like to share with you:

1. Many of the attendees at my Silence of Agile talk were trained and experienced facilitators and during our discussions offered two specific tips that I plan on trying at one of our team's next retrospectives.

• The first tip was to change the voting so that people vote not only for their top 3 ideas but also their bottom 3. When tallying the results use the net votes (top minus bottom) as your top items to work on for that period. 
• The second tip involves changing the silent writing portion of the retrospective. Instead of writing each individual idea on one post-it, ask each team member to write all their ideas on one paper in a list format. Once everyone has written their list, pass it to the person on your left. Each person then reads their neighbour's list and adds to it. Keep passing the lists to the left until everyone has read and contributed to all the lists. Finally, put the individual items on your board and prioritize them as usual.

2. Innovation Games help you have better conversations and make better decisions. I had already experienced this myself when using these games for retrospectives. However it became even more explicit as we facilitated and observed the San Jose 2013 Budget Games. We had a diverse group of community members at our table who had honest conversations and made tough decisions about topics that are important for San Jose. I can imagine that a great facilitator could also have achieved the same results, but the game did this without much need for facilitation. I'll be looking for more places to try out these games.

3. As a facilitator, it is important to trust the Innovation Game and let the group create their own process and flow within the context of the game. Gerry Kirk was my facilitation partner for the Budget Games and I watched (sometimes in trepidation) as he deftly used good questions to nudge the group along rather than directing the flow. Their process was sometimes a little scary as they tried to work within the game to come to decisions. However, in the end it was their process and their results. The game did its job to provide structure and Gerry's gentle questioning prodded them to a good result much more effectively than a directive approach would have.

4. A new podcast source! Look for Jack Dorsey and others on Standford University's Entrepreneurship Corner.

5. A new book that was highly recommended by Mr. Holdorf: The Radical Leap Re-Energized by Steve Farber.

6. Two 'S's. These aren't agile tips, but useful nonetheless

• Have sinus trouble when flying? A client of mine recommended Sinusalia by Boiron. Take two pills before you get on the plane and then every two hours during your flight - they are magical.
• Need music for your training sessions, workout sessions, relaxing at home, etc? Try the Songza app. It has lots of curated music based on themes and also comes with a pretty neat UX experience that suggests musical themes based on the time of day.

Subscribe to Winnipeg Agilist by Email

Kanban At Home

As Jen mentioned in the previous post, kanban has crept into our home. Here is a quick post to tell you how we build our board, how we use it, and the results.

While some families create a permanent board, we've found that temporary boards serve us well. If you stop by some Saturday morning you'll probably find us in the act of putting post-its on the mirror in our front entrance. It is true that occasionally our board is created in the kitchen or even sometimes the hallway, but the front entrance is currently our favourite location. We have three columns across the top - "Ready", "Doing / Work in Progress", and "Done". You can probably simplify the middle column name to "Doing" or "WIP" but our kids have decreed that we should use both terms.

We populate the "Ready" column with everything we'd like to accomplish that weekend. We're careful to make sure the tasks are clear and not too big. For example, instead of "Clean the House", we create post-its for "Clean the Kitchen", "Vacuum the living room", etc. Our board will have a mix of post-its that are specific to one person ("C practice piano", "A practice drums", "M clean room", "Daddy pay master card") and cards with no names that anyone can grab ("Shovel the snow", "Organize the front closet"). More recently we've also started to add post-its for doing fun things together ("LEGO!", "Family Movie").

Once the board is populated the process is quite simple. Everyone selects a post-it, moves it to the "Doing / Work in Progress" column and goes to work. Once they are done that task, they move it to "Done" and select another. By the end of the weekend, the post-its have made a large shift towards "Done" as seen above.

For our family this board works because it is simple, transparent, and requires little to no 'management' (i.e. nagging). Once the board is populated each person has a clear view of their expectations and can make their own decisions about when to do chores and when to play. On most Saturdays our kids (ages 7, 9, 11) do their chores earlier in the day so that they can spend the rest of the day relaxing without worrying that more chores will be added to their list.

A board we created this holiday season is a particularly great example of the peace that a board can bring in our household. We had just returned from a road trip through Nebraska (Car Henge!), South Dakota (Rushmore and Jewel Cave), Wyoming and North Dakota. The level of grumpiness as we unloaded all of our luggage from the van into the house was historic - we were all tired and the mood was tense. As we stood around the pile of luggage now clogging our front entrance we reluctantly decided to create our board. Among the post-its for "Laundry" and "Unpack Luggage" were reward post-its like "Sleep" and "Spend my $10 Claire's gift card". After agreeing to take care of all the chores before starting any of the reward post-its, we moved our post-its to the "Done" column in record time with zero nagging. In parallel, the spirit of our household moved from grumpy to peaceful with the same efficiency.

Well, it's Saturday morning. I'm being beckoned...

Subscribe to Winnipeg Agilist by Email

Living With an Agilist

(Editor's note: The following is a guest post by Jen Rogalsky)

A couple of years ago Steve came home from work and announced, “Podcasts have changed my life.” My natural response was: “What? Podcasts? Not me, not our children, but podcasts?” He persisted with his original assertion. “Yes, podcasts. They’ve changed my life.”

This was my first introduction to the fact that Steve, through podcasts, had begun to learn about something called agile, and his declaration of devotion seemed to leave me with a clear choice: learn a little about this new interest or be left behind by this obviously life changing discovery. We were not immediately friends, agile and I, and yet along with the post-it notes and sharpies that have overtaken my house, some agile practices and principles have slowly become part of my life. I don’t pretend to be an expert in their application in a business context, but as I stumble through trying to explain to someone who asks me “What does your husband do?” I often come out with some kind of statement explaining that agile is applicable in some way to almost everything and everyone. Quite a lofty statement, and obviously somewhat hyperbolic, yet my personal adoption of some agile ideas is a testament to a sliver of truth.

So here are just a couple of examples of how agile practices have seeped through the cracks.

I like to picture myself as quite a broad thinker, capable of pondering and producing on multiple platforms simultaneously, unhindered by the shackles of linear constraints. Okay, so, that may look somewhat unsystematic to the outside viewer. And, okay, that may occasionally result in many simultaneously started, yet unfinished (albeit very creative and useful) projects. As I’ve learned more about agile, however, I’ve become more convinced, although reluctantly, about the value of shorter loops. Just as risky as it may be in a professional setting to invest money and energy in a long arc with feedback and product only at its end, shorter loops have proven their value for me, as well. I churn less often, (although sometimes churn on purpose just to be rebellious, now that I actually understand it for what it is), actively seek frequent feedback from those involved or implicated by my task rather than wait until the end to ‘test’, and force myself to be more systematic at finishing one task before beginning another, fueled by the motivating sense of reward that can provide.

My evolving relationship with kanban has been no less reluctant, and yet equally as relentless in slowly changing my practices. Steve introduced kanban into our household quietly, first making his own boards for house and renovation projects, then producing boards on the kitchen cupboards for when he was in charge of doing chores with the kids. I didn’t object as long as I wasn’t required to participate. “Let’s just do it already, instead of sitting around writing stuff out first!” was my usual response when invited to join the process. Steve’s gentle suggestion that he wasn’t born with the ability to help accomplish our common goals by subconsciously divining the detailed task list in my head wasn’t enough to convince me of kanban’s value. Once again, however, like the persistent drip of water on rock, my resistance has been futile. It began with observing the relative lack of nagging involved when he did chores with the kids. What a wonder to behold when they would eagerly race back to the board to move their sticky from “WIP” to “done.” Or to overhear them debating their preferences in referring to the middle column as “Work in Progress” vs “Doing.” Or to watch their ownership of the whole task process increase as they were given the opportunity to participate in the creation of the list and then freed to choose their own route through to getting all the stickies transferred over to “done.” And now, after a long, slippery slope, most of our Saturday mornings begin with the creation of a family kanban board on the mirror in the front hallway. We are careful to also include the fun and relaxing activities in the “ready” column, and we all share in the sense of satisfaction when, come Monday morning, the board is balanced quite differently toward “done.” kanban’s conquest to take over our house is almost complete, since I recently found a spare bulletin board that seems to be calling to me to be made into a personal kanban board. Oh, how the mighty have fallen.

Finally, Steve’s passion for all things agile has found its way to the very core of our most significant common project, by influencing the ways in which we parent our three girls. I often find myself thinking, “But isn’t this just common sense? Perhaps we are making these decisions because we’re so incredibly intuitive and such remarkable parents…” and yet I know that our thinking has been shaped by what we have learned about an agile approach to treating people in the workplace and applying these ideas to the little people we live with. A couple of deliberate parenting strategies have emerged. We deliberately try to assume our kids’ competence rather than treat them as inherently incompetent and in need of our micro-managing. We try to make expectations clear up front, but then encourage them to find their own route toward completion within the established boundaries. We’ve learned that feedback is most easily heard and adopted when offered immediately and within a conversation in which the kids are participants. And perhaps most significantly, we are trying to do whatever we can to help them develop what Linda Rising calls an “Agile mindset” rather than a “Fixed mindset.” I almost thought I heard angels singing when my daughter recently told me that she wished her friend would realize that “Life isn’t supposed to be easy! Challenges don’t mean you’re supposed to sit down and complain, just work harder and figure out how to get past them.”

All right, then, if agile ideas can eventually help my kid say something like that, even once, then I guess podcasts have changed my life too.

Subscribe to Winnipeg Agilist by Email