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.

GUEST BLOG: How Agile is Like a Guitar and Tech Info Fits Into Agile Software Development

A colleague and friend of mine, Janice Hamrick is an outstanding Technical Information Engineer (aka Tech Writer) and a totally entertaining mystery writer.  She attended last year's Keep Agile Austin Conference and wrote up a great piece on it.  I'm honored to have her as my first guest blog!  @MulticastMatt

When I told a friend I was attending an Agile Austin conference, she asked me if it was a new exercise program. Naturally, I said it was. Who am I to argue with someone who is willing to believe that I’m exercising? But for those of you who know better, the Agile Austin 2012 Conference was a day-long symposium centered on Agile software development.

Three years ago, I joined Hyperformix as the technical writer for two development teams. A week later, Matt Roberts (soon to be president of Agile Austin) joined as manager and led the teams through a transition from an unsatisfactory blend of waterfall and pseudo-Agile to an extraordinarily successful Agile development organization. Hyperformix was acquired by CA Technologies a year later, and CA is going through its own transition to Agile. As I watch the beginning of this much larger scale Agile transformation, I’m also watching Technical Information trying to find its rightful place in the mix. Technical writers often find themselves left out of the Agile process (particularly when they are not fully integrated into their development teams).

At Agile Austin 2012, the keynote speech by David Hussman set the tone for the day. He said, “Agile is as interesting to agility as a guitar is to music. Both are tools.” He then added, “If you strum a saxophone, it’s not the saxophone’s fault.”

Knowing how to play the Agile instrument is a matter of experimentation, education, and adaptation. It can be a bumpy process, but the most important thing is remembering that the people on your team – including the writers – are like members of a band. Everyone needs to be invited to the rehearsals, and everyone needs to play the same song and keep the same beat.  Holding planning meetings and estimating stories and tasks without including writers is like holding a secret band practice without the guitarist.

As with most conferences, I found the discussions that took place between sessions at Agile Austin 2012 to be as informative and interesting as the sessions themselves. I spoke with one writer who said he didn’t really see the value in retrospectives (the meeting after each sprint in which an Agile team discusses what worked, what didn’t work, and how to improve things).  I was surprised because these meetings not only improve processes but they help build trust among team members. But he then mentioned that his team’s version of a retrospective was an electronic survey sent out at the end of each sprint.  That team is strumming a saxophone, and then wondering why it doesn’t sound like a guitar.  I’ve also spoken with writers who can’t participate in standups because they can’t hear properly over the phone or who are assigned documentation tasks that they can’t possibly complete long after the sprint planning (to which they weren’t invited) had taken place. It’s no wonder that many writers feel frustrated by what they believe is “Agile” when in fact it’s not really Agile at all.

One of the many benefits of living in a town with an organization like Agile Austin is having such a terrific resource to assist you when Agile isn’t working for your or when you think that there must be a better way. Chances are, someone else out there has been in your position and has a suggestion or two that could help make your team and your life easier, better, and more agile.  If Agile isn’t working for you as a writer, then it’s not working for your development teams either (whether they know it or not). It might be time for some guitar lessons.

 About the Guest Blogger

Janice Hamrick joined CA Technologies in 2010 as the Senior Technical Information Engineer for the Capacity Management suite of products (formerly Hyperformix).  Before joining Hyperformix, she spent years writing documentation for backup and recovery products for a rival company whose three initials shall remain unnamed. It is a myth that she has worked as a technical writer in the software industry since dinosaurs roamed the earth, but she does remember when “agile” was something you had to be to avoid the saber-toothed tigers.

Outside of work, Janice is the author of the award-winning Jocelyn Shore mystery series (DEATH ON TOUR and DEATH MAKES THE CUT, Minotaur Books).  She has completed the third novel in the series which will be published in 2013 and is currently working on a new and much darker mystery series.  Learn more at www.janicehamrick.com. 

Problems Maintaining Product Development Innovation in an Agile/Lean World

Hi all:


I'll be presenting the following discussion at the Agile Austin Leaders SIG on Friday, March 1st, 2013 at CA Technologies in Austin, TX.  I'm really looking forward to feedback!

@multicastmatt

Sign up:

http://www.eventbrite.com/event/5381488176 

Abstract:

One of the benefits that many product development teams are able to realize when they switch to an iterative or limited WIP process for developing software is (finally!) a ranking of work items on which the team can focus.  Over time, this allows a good deal predictability for the stakeholders of the project, especially when work items have corresponding “done” criteria that are adhered to.  Some organizations are so enamored with the results of this shift that they begin to assemble all members of team into these types of structures, including team members that were previously dedicated to research or advanced product development efforts.  While this is not necessarily a bad decision for these organizations, some face issues with maintaining a level of innovation in the product efforts as there may be a perception that there is neither time nor the people to work on important innovation efforts.  Further, some of these team members may be doing work that is neither challenging to them as individuals nor is bringing the appropriate value to the company.

In this discussion, Matt will help shine a light on this issue that can be especially challenging for a product development company that seeks to maximize the velocity of a product team working against the near-term roadmap but may lose sight of competitive challenges that may change the very nature of the playing field.  He will describe the challenges faced by teams he has worked with both in the past and currently and share what he has learned.  A healthy discussion is expected to follow!

Bio:

Matt Roberts is an agile pragmatist continuing his lifelong learning journey, currently serving multiple teams as Senior Director of Software Engineering and Agile Coach at CA Technologies. His experience is wide-ranging as he has developed software and led efforts to create systems for product development teams to deliver innovative solutions in companies ranging from early-stage startup to publicly-traded companies in both consulting and full-time roles. He has had the privilege of serving the Austin software development community as Agile Austin President over the past two and half years and as Secretary for the IEEE Computer Society over the past eighteen months.
Matt holds certifications as a Certified Scrum Practitioner (CSP), Certified Scrum Master (CSM), and Certified Scrum Product Owner (CSPO).  If you’d like to learn more about him, please visit http://linkedin.com/in/cpgmattr or see his latest thoughts at multicastmatt.blogspot.com.