Summer Soujourn in Juneau

Summer Soujourn in Juneau, a photo by cpgmattr on Flickr.

A cloudy day in Austin reminds me of a "sunny" day in Southeastern Alaska nearly five years ago.

@multicastmatt

Timid Incrementalism Will Get You Nowhere

Hi all:

When I came on board at Hyperformix, just over four years ago, I was impressed with many things about the company, most notably its leadership (both technical and managerial).  As part of the Senior Management Team, I had an opportunity to work with an amazing VP of Products and Marketing, Bruce Milne.  I'll never forget the sign he had on his wall--it was a standard sheet of 8 1/2" x 11" paper printed out some time ago as it had seen some weathering.  Upon this paper was the fading ink that had no small impact on my mind and life almost every day since.

TIMID INCREMENTALISM WILL GET YOU NOWHERE

In agile software development, we practice iterative as opposed to incremental development.  There is a big distinction as the latter does not allow for dynamic change while the former anticipates and embraces it.  Perhaps a corresponding statement could be "FOCUSED BOLD ITERATION WILL DELIVER DISPROPORTIONATE VALUE" in agile and lean product development.  I'll admit, it's not as catchy and sounds more like management speak.  Give me a few days to wordsmith it :)

I've googled the original phrase and can't see if it had any origin other than Bruce.  I believe it has implications across both business, creative, and personal life and I always keep it close to the front of my mind and helps me to focus on "thinking big".

I hope this is of value to others!

@multicastmatt

The Ripples of Pebble Across My Life's Pond

Hello all:

On Saturday, March 16th 2013,  I unboxed my Pebble, which represents a "new" era of wearable computing.  For those that don't know, the Pebble was an insanely successful kickstarter project to build an e-paper watch as an extension to your smart phone (iPhone or Adroid).  They acheived 10,000% of their funding plan with $10,000,000 of $100,000 raised. 

Here's their kickstarter page:  http://www.kickstarter.com/projects/597507018/pebble-e-paper-watch-for-iphone-and-android.

I thought I would keep a running total of ways that this "wearable computing" has affected my life.  Note, as I have my phone with me so much, I already feel as though I have wearable computing integrated in my life--perhaps too much.

But first, why did I back the Pebble?  Well, all the cool kids were doing it.  OK, they weren't.  I was pretty early on, but I really liked the idea of this scrappy company using Kickstarter to get their product funded.  It allowed me to play VC (venture capitalist) at a very low entry point.  Note:  playing VC meant that I could have lost all money and gotten nothing in return or gotten a potato in a dozen years.  I don't know how many backers really understood that concept given the online groaning about the missed delivery dates.

From a pure feature and benefit perspective (i.e. logical), I thought it would be a kick ass way to remotely control my iPhone, which is usually in my pocket or on my arm band when I'm running or riding.  There is promised RunKeeper integration which could have additional benefits, unknown to me at the time of writing.  I have made certain allowances to spend any monies necessary to keep my exercise plan on track--this fell (after some heated internal debate) under those auspices.  Additionally, I thought it would be a good way to get status messages that may or may not be important when in meetings with others and I don't want to be so rude as to check my phone, but checking one's watch is perfectly socially acceptable (mostly).

The Pebble replaces the Timex Ironman watch that I've been wearing since 2008, and whose features I use just about every day when it comes to seeing day/date and time and timing my well-defined runs and moutain bike rides.  I use to use my Garmin for the latter, but given the propensity for my running partner and I to run the same routes, I found I didn't need the distance piece as it was essentially the same every time (note, this might be an issue and we should consider changing it up).

So here it is, my ongoing observation log of the ripples in my life from Pebble in reverse chronological order.  The ones in bold are a bit more meaninful:

• [March 18] No one at work has noticed my Pebble at work.  What is wrong with people? :)
• [March 18] I keep looking down at the watch (currently in "TextWatch" face (right now it reads "one six" with the six below the one in modern font) looking for the day and date.  I find it irritating that it's not there, but I'm not willing to switch to any other watch face that includes it as it isn't as cool.
• [March 17] I've figured out a great new feature--I can use the music control to find my iPhone!  I know that there is an app for that, and I do have it, but it takes about two seconds to start playing tunes on my watch--no need to find a computer or iPad, log in, wait for it to find it, and then tell it to play the tune.  I'm amazed that the bluetooth actually reaches across my first floor.  This is a very usable feature!
• [March 17] I keep getting notified on my phone that the Pebble app wants to communicate with the Pebble.  I don't know why--I'm all up-to-date.
• [March 17] Realization--while there aren't too many features available today, I feel like the folks at Pebble have created a great minimum viable product (MVP) with time, date, music control, alarm.  I believe that this can be extended through software in the future akin to the original iPhone.  I'm really glad I backed this project.
• [March 17] Notifications are going to be a bit more of an issue than I had first thought.  You have to go through a manual series of steps to get them to come across correctly. 
• [March 16] Downloading the first update was unsuccessful the first few times, then it wasn't.  It seems to help for the watch to be close to the iPhone.
• [March 16] Getting intimate with Pebble in our first shower together--I CAN CHANGE MUSIC IN THE SHOWER-WOOT! Yes, it's water resistant to 5 ATM.  I wasn't expecting that when I backed it, but it's really nice for it to be there, especially given the exercise implications.
• [March 16] Argh!  There is no stopwatch (chronograph).  Wow, at least for the short term, I'm going to need to use my other watch for runs.

Why Did We Stop Doing Annual Performance Reviews When Adopting Agile?

I delivered this presentation at the Agile Austin (www.agileaustin.org) Leaders' SIG on June 1, 2012.  This covers, at a high level, the reasons why we decided to deprecate the annual performance review when we switched to an agile philosophy/mindset for delivering valuable and usable customer software.  The system we put in place was primarily designed to encourage/codify alignment of the work of all team members with the highest business priorities, while remaining flexible enough to deal with important change.

A "side" benefit was that the amount of waste avoided in the effort that allowed the team to stay razor focused on innovative product development.  I talked with a few other companies in Austin that were considering doing something similar.  One of them had calculated that they spent a fully month of their organization's capacity (i.e. November) doing annual performance appraisals.  Once they stopped doing them, they received over 8% productivity back immediately!

Note that I am a strong proponent of putting in performance plans in place when it makes sense from an improvement basis.  There are good reasons for doing so legally, in order to protect all parties (including the individual contributor).

Like all things it was a bit of a compromise as I was still against the compensation payouts, but our agile culture was a constant reminder to not implement incentives that would take away from teamwork and collaboration.  Once we came into CA Technologies, this system was deprecated for a more traditional annual performance review system (I'll blog about that later), but the team was still laser focused on the top business priorities, without the need for any other extrinsic motivation mechanism.

I would be interested in hearing others' learnings in this area, as I see traditional annual performance reviews as key impediments to adopting an agile culture and enjoying the full impacts of its benefits.

Here's the slideshare link:
http://www.slideshare.net/MattRoberts6/agile-performance-management

Another source of wisdom is Dr. Deming, the quality prophet who taught Japan to dominate the U.S. auto industry.  In this video, he talks about the Five Deadly Diseases of Modern Management.  Number three is: Annual Rating of Performance at 4:58.  It's only a few minutes long but has a very large impact.

-@multicastmatt

Can Rules Create Engagement?

Here's a quick story about one of our practices to encourage engagement through structured self-organization for our agile software development teams.

- @MulticastMatt

Why Structure Is Important in a Self-Organizing Agile Environment

Like many aspects of agile software development, there are different interpretations of some of the practices that are espoused, especially by novices.  In particular, we tend to encourage team members to volunteer for work versus being "signed up" for it by, in days of yore, a manager.  Some times this is taken to an extreme, and team members may not sign up for any work, or sign up for work that is currently not a high priority.  This can be problematic as it leaves holes in work that must be done.  Therefore, some level of structure is required to get the highest priority (and hopefully valuable) work to be done.  This includes the necessary collaborative meetings that, with appropriate engagement, can be phenomenally productive.

An Example:  The Rules of "Engagement"

Last year, I came up with a simple list of rules for our larger team meetings to encourage participants to focus on the goal and to eliminate wasted time (muda).  This was in response to complaints from the team that larger meetings (backlog prioritization, release planning, sprint planning, etc.) were "painful" due to the propensity to get off track and only be interesting to a few participants at a time.  Key symptoms included heads bobbing behind laptops, bent heads staring down at what we hoped were the individuals' smart phones, and the standard response of "huh?" when an opinion was solicited of a team member in either of the two former states. The rules were designed to create a system where the team could feel comfortable holding themselves, each other, and their manager accountable to achieve the stated goal and maximize the value obtained by all participants.  I refer to these as the "Rules of Engagement," pictured below.

Rules of "Engagement" Poster Used in our Larger Planning Meetings

The ultimate rule, dubbed "The Rule of Two Feet", was repurposed from the Open Space Law of Two Feet, which states: "If at any time during our time together you find yourself in any situation where you are neither learning nor contributing, use your two feet, go someplace else."  This would be the ultimate solution to disengagement, but I thought it made sense to have the departing team member discuss why they were leaving with the rest of the team.  In this system, team members are empowered with the flexibility to leave if they feel the content is off-topic, does not apply to them, or any other reason.  However, it encourages potential continuous improvement (kaizen) moments, including the discontinuation of practices that no longer serve the team.

Team Response to the Rules of "Engagement"

These rules have been put to the test on a few occasions and resulted in the deprecation of a release planning ritual that seemed to work and had been a standard for the team.  One team member was fairly frustrated with this process and stood up to leave but gave his feedback first.  We then went on to have an open dialog in front of the rest of the team.  This led to a much richer discussion about what we were trying to accomplish and the best way to do it, which continued beyond the original meeting.  While the goal had not changed, we learned a more effective way to get there by discontinuing the process, thereby eliminating wasted time.  I feel that if the initial team member had just walked out, we would have missed that critical kaizen moment.  

This is certainly a success story, but it worked within a larger framework of trust that we had developed over close to three years of working together.  As with most practices, your mileage may vary.

Our Standard Rules of "Engagement"

We at CA Technologies host a bevy of Agile Austin meetings, and the poster above tends to be an item of interest.  In fact, many visitors have taken pictures of it and brought it back to their teams.  This is great, but it's important that everyone understand the context in which it was developed.  It is critical that the team buy into this for specific reasons, understanding the why.  Like other standards, rules, process, etc., the team needs to be free to change them as they see fit when there are new kaizen moments.  

Here's a transcription in case my writing is hard to decipher:

• Cell phones down / away (unless taking pictures of story point estimation)
• Laptops closed unless
• You're taking notes for the team
• You're presenting
• You're remote
• You desire employment elsewhere :)
• Break for 10 minutes every 80 minutes
• If you're late, you missed it
• Time boxes will be maintained by the MC
• Raise your hand if you think the discussion is off-track or the Rules of "Engagement" are being violated
• Consider remote team members
• One conversation at a time
• Consider the goal of the meeting
• "Rule of 2 feet" is justified, but should be discussed

An Aside - Freedom and Organization

Many organizations have unpaid volunteers (local political campaigns, open source software projects, Agile Austin, etc.) but that does not imply that everyone is free to do whatever they would like.  There is a mission or a purpose that drives the most effective organization.  As the definition of "organization" is: "The structure or arrangement of related or connected items,"  organization implies structure.  Generally, people come in as novices, learn the system and then are entrusted with some span of control beyond themselves once they have attained some level of mastery.  It's naive to believe that volunteering is equivalent to the ability to do whatever one desires in any type of complex organization.  I see the same thing in organizations trying to create software.  

Allowing for self-organization and self-management is essential for software development teams where agility is critical.  Indeed, it creates an environment where team members are fully engaged in creating usable and valuable software.  However, self-direction may lead away from the goal of the organization.  Striking that balance is something that no "best-practice" can ever dictate--indeed it requires experience and a deep understanding of many dynamics.  For those in entrusted with managerial or technical leadership positions, this can be an area of extreme benefit or dismay and thus should be a focused area of learning.