Monday, January 7, 2013

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.

Wednesday, December 26, 2012

Tips for Facilitating a User Story Mapping Session

In an earlier post I described how to create a user story map. Here are a few additional tips that you might find helpful.

Tip #1. Silent Brainstorming isn't mandatory. 
While using silent brainstorming is great for creating a map, you don't always need to use it. Sometimes you may find yourself in a situation where a full set of requirements has been written or the app is a re-write of an existing and well known application. In those cases I often skip the silent brainstorming and create the map from the existing documentation. Of course, I still do this with the team.

Tip #2. For your first map, reference the email map.
When you are creating your first map you may find that some people have difficulty finding the right level of detail for the second row in the map ("things people do" - the user tasks). In order to reduce the confusion walk them through the first two rows of the email map first. You can simply write the basic map on a few post-its as an example:

Finally, as they are writing their 'things people do', walk around and take a look at what they are writing. Encourage them when they are writing the correct level of detail ("Compose Email") and ask questions when they are getting into too much detail ("Set an email to High Priority").

Tip #3. Tear horizontally, not vertically
There are two ways to tear a post-it note off of the pad. If you tear it off horizontally (left to right or right to left) the post-it note will lie flat when it is stuck onto the wall. If you tear it off vertically (bottom to top) then it will have a curl.

Tip #4. Big Post-its
Quite often it isn't possible to create your map in the team room. If this is true for you then create your map on the large 3M Easel pads so that it can be transferred back to the team room.

Tip #5. Use name brand post-its
Post-its made by 3M seem to stick longer than other brands.

Saturday, December 15, 2012

A Systems Thinking Alternative to Performance Reviews

I tried something new based on the concerns and research around annual performance reviews. I'm not qualified enough to make categorical claims about the typical annual performance review process, but I can say that by trying something different I enjoyed the performance review process more than any other year and I had some great conversations with my co-workers. Here is a quick report of some of the concerns, what I tried, and what I learned.

The concerns:
 
W. Edwards Deming is often quoted when expressing concerns over annual performance reviews. Deming's 85-15 rule implies that 85% of any employee's performance is based on the system they are working in rather than their own individual actions. If this is true, then any significant performance increases or decreases are not under the employee's control but rather those who control the system (i.e. management). This means that if employees are under-performing we should look to the system first and not the individual.

As a parent, coach and change agent, I have noticed one consistent trend with respect to individual improvements. If I try to push improvements on people then they will tend to resist the change. However, if I try to pull improvements from them (ask them what they want to learn/improve) I encounter much less resistance and more actual improvements. How might this influence the annual performance review process?

The experiment:

Note: At Protegra we have a flat structure so we don't receive feedback from managers but rather from the people we've worked with over the last year. As a company we've tried various approaches and are still experimenting to uncover better ways. The experiment I tried this year was based on the concerns above and also conversations with co-workers. In the end I came up with five questions to augment my involvement in our yearly process. After receiving permission from each person, I sat down with them and had a conversation that centered around the following questions:

a) What are you proud of? (Pull)
b) What do you want to learn or improve this year? (Pull)
c) What part of our team's system is preventing you from doing your job better? What should we improve or change? (Systems Thinking)
d) How is the company enabling or inhibiting you from achieving your best? (Systems Thinking)
e) What do you need from me? How can I help? (Pull)

The results:

I had fantastic conversations with several of my fellow employees on what they love about their job, what they are proud of, and the things they are doing to try and make their work environment better. I discovered some common interests and swapped ideas for personal improvement and growth. I learned more about what makes each person 'tick' and how I can support that. In the conversations I had with each person I left feeling inspired, listened to, and encouraged. I think we all felt a greater sense of ownership over our improvement plans for the year.

Just as importantly, I learned more about the value of Deming's 85-15 rule and its impact on performance. We had discussions about our system and the things we could (and did) change. In more than one case it became clear how powerful a simple systems change could be. Our conversations were slanted towards being a performance review of the system instead of a performance review of the individual.

This experiment was a lot of fun and I plan on doing it again. In fact, I have added an item to my backlog to extend this conversation to other people on the team throughout the year.

Some final thoughts:
After reading this some of you may be asking questions like "how does this help us address those individuals that actually have 'performance' problems?", or "how does this help us set salary?". I'm not sure it does in the way you might like. For the former, please don't wait until the annual review to deal with the issue (short feedback loops please!) and make sure to look at the system first. For the latter I'll leave that to other experts to discuss (see the TLCLabs blog below for one example). However, I'd guess that taking this approach nudges a group of people towards having a better system, being a more effective team, and becoming a more effective organization.

System Thinking References
- Demings 85/15 rule
- If Ackoff had given a Ted Talk
- It's not a behavioural problem its the system

Performance Review References
- Why performance reviews don't improve performance
- Why we don't do forced ranking and performance reviews - TLCLabs
- The Elephant in the Room: Appraisals and Compensation - Mary Poppendieck
- Get Rid of the Performance Review! (and some info on Performance Previews)

Subscribe to Winnipeg Agilist by Email

Tuesday, November 27, 2012

Blog Challenge!

Hello readers,

This is a quick post to let you know that a few friends of mine have started a blog challenge. The challenge (led by Dylan Smith) is to blog bi-weekly over the next six months with a winner take all purse. Be sure to check out their blogs as well:

Dylan Smith: http://www.geekswithblogs.net/optikal
Tyler Doerkson: http://blog.tylerdoerksen.com
David Alpert: http://www.spinthemoose.com
Dave White: http://www.agileramblings.com
Aaron Kowall: http://geekswithblogs.net/caffeinatedgeek/Default.aspx 

(P.S. No - this post doesn't count in the challenge)

Celebrate Failure? [Part 2]

Earlier this year I wrote about Agile's perspective on failure. In that blog I indicated that my brother-in-law (a psychologist) sent me some of the latest research on failure. In particular, there were two fascinating studies that helped me understand why failure is indeed a cause for celebration. In the first part of this series I summarized the results of a study looking at the effects of failure and success in the orbital launch industry. In this blog post I'll look at some interesting research that examines the role of attitude when failure occurs.

Your attitude towards failure (and your organization's attitude) does matter.

A group of researchers led by Joel Albert Kahn set out to discover what the effect of failure norms - or attitudes towards failure would have on closing gaps in performance. Is failure enough incentive for an organization to find ways to improve or does their attitude towards that failure matter?

In an exploratory study they surveyed teams within an automotive manufacturer to look for teams that had both strong and weak "failure acceptance norms". A team with weak failure acceptance norms would be characterized by defensive attitudes when failure occurs. A team with strong failure acceptance norms would be characterized by team members that have an acceptance of failure as normal.

Using survey data they identified the teams with the strongest and weakest failure acceptance norms and then observed those teams over a two year period. What they found is that attitude mattered - the teams with the strongest failure acceptance norms were the teams that closed performance gaps the most effectively.

To those familiar with Carol Dweck's book "Mindset: The new Psychology of Success" or who have seen Linda Rising talk about her research, this should come as no surprise. According to this research, people generally find that they have one of two attitudes.

The first group of people believe that each person is either smart, or not smart - they have a fixed mindset. In this group failure is a strong indicator that you are not smart - they become defensive when failure occurs and gravitate towards easier tasks that allow them to be successful. This group has weak failure acceptance norms.

The second group of people believe that if you work hard you can improve and overcome problems - they have an agile mindset. In this group failure isn't an indicator of intelligence but rather a challenge to try again and work a little harder. This group has strong failure acceptance norms.

Interesting - Carol's research on individuals matches that of Kahn's research on organizations and teams.

One further note about Carol's research. She found that it was relatively simple to move people from the first group to the second. Our words can be powerful. When failure occurs, celebrate it as a learning opportunity!

To end this series I have a suggestion: The next time your team fails, promote an agile mindset and buy them a cake to celebrate:

Credit: www.cakewrecks.com
Further Reading:
- Linda's presentation on this topic
- Linda's keynote from Much Ado About Agile
- Carol's website: http://mindsetonline.com/
- A short video of Carol describing the effects of praise on children

Subscribe to Winnipeg Agilist by Email

You can get the full research from your neighbourhood PhD student but here are a few more details on the studies mentioned above:

"Failure construction in organizations: Exploring the effects of failure norms - Kahn, Joel Albert, 1995, University of Michigan. School of Business Administration. 

Two exploratory studies were used in this research to develop an understanding of the effects of failure norms at an automotive manufacturer. Using the survey data, the two teams with the strongest and the three teams with the weakest failure acceptance norms were identified. These five teams were observed for two years and cause maps were collected from 31 members of the teams."

"Early models of organizations as rational systems assumed that a gap between what is expected of a performance and the performance as it actually occurs will stimulate a search for an alternative approach to a problem. An interpretive perspective, in which performance gaps are socially constructed, suggests that such a search is not the inevitable consequence of performance gaps. Instead, people interpret performance gaps defensively by retrospective rationalization and external attribution to avoid acknowledging failure. People will search for alternatives only when performance gaps are interpreted as failures and not when they are interpreted defensively. Whether or not people interpret performance gaps defensively is determined by norms that are communicated and enforced within an organization an that are considered binding within its teams. Thus, the central idea of this dissertation is that search is not an inevitable response to performance gaps as is often presumed. Instead, search is a response to failure only if people are encouraged to accept failure by strong acceptance norms. …it is the acceptance of failure (strong failure acceptance norms) that encourages the interpretation of performance gaps as failure."