A tribute to a great team bulit over 5 years

October 16, 2014

I debated removing this page when I left CA Technologies in April, but thought that I would leave it as a tribute to an incredibly special team that we created together.  Unfortunately, as the saying approximately goes, "every positive cultural change is one manager change away from failure," and the overall direction was no longer compatible with my personal values and it was time to leave.  Perhaps one day I'll write about that experience.  However, I'm really excited about the new team we're building at Socialware, which I've been long-overdue to write about!  -m@

July 19, 2013

Welcome!

You've probably arrived on this page as someone forwarded you over a position for our team at CA Technologies here in Austin.  Yes, we're hiring in a relatively big way, but we do things a little different here.  I thought it would be good that you know a little bit about us before you consider joining.

Keeping CA Technologies Weird

It's important to know our heritage: our team is composed of the former NetQoS and Hyperformix development teams.  We are part of CA Technologies, and we don't pine for the "good old days", but we are "keeping CA Technologies weird" in the following ways:

Party Bus w/Karaoke for Offsite Toobing Day

• We are entrepreneurial and motivated by delivering direct value to our customers by eliminating waste (as identified by the team members) and eschew process that doesn't make sense.
• We are a 95%+ co-located team.
• We have fun, but not in a pinball machine/video game kinda way.  Don't get me wrong, we have that stuff, but the most fun (for us) is solving really challenging problems with a reach nearly unparalleled by other companies in the local market. Winning is also really fun.
• People should be and are unique.  We don't have a dress code, and people have flexible work styles. We do emphasize being in the same place at the same time for a good amount of the day, but understand why that's important.
• We have a sense of humor and treat people as responsible adults.  Experience has shown that the benefits of this far outweigh the risks in this approach.
• We ask A LOT of questions around why things should be done, especially when someone else is telling us to do them.  We've kinda got a reputation....but that reputation is superseded by our ability to deliver valuable software to our customers and make money.  Funny how that works out.
• We all figure that a culture of fear has pretty much been played out by now.  Individual and team empowerment is engaging--we like that.
• Our management team "walks the talk" of acting as servant-leaders.  We are here to help things "go righter"

Service Day at KIPP Austin

Why you might want to work on this team

In addition to being OK with the above, you:

• Love solving very tough problems and truly love to learn.
• Focus on quick delivery to get rapid feedback into what our products should be for our customers
• Are inspired by how technologies can affect people's lives for the better
• Can deal with constant experiments in how our work is done 
• Work really well with others in tight teams yet still have independent minds
• Are OK with doing any job on the team, but realize that it makes sense to focus on your strengths
• Have a passion for building products that deliver real value to customers
• Are open to the possibility that all this "agile stuff" just might not be management bullshit.  You've looked at the Agile Manifesto and the Principles, and that sounds really good to you.  You have hopes that someone, somewhere really pays attention to this stuff.
• Want a real work/life balance.  This is again, not bullshit.  I have not asked the teams that I serve to work a night or a weekend for four years running.  We practice sustainable pace (and fully know why we do).
• Want to develop your "career capital"--we carve out one week a year for everyone to train and build it into our schedules.  Yes, there's budget too.  No, it doesn't get cancelled, but you'll need to have some level of independent motivation.
• Want a certain paycheck and sweet benefits.  CA Technologies is a big company, we enjoy more than five weeks of vacation a year.  Yes, you heard that right, and that's before holidays.

I know the above sounds a bit too hard to believe, but you can ask any team member.

At a recent "Science Faire" where the team takes two days
every four weeks to work on their innovative projects.

Why you might not want to work on the team

There's nothing wrong with these things at all, but please don't apply if the following resonate with you, as you won't be a good cultural fit for the team:

• You just want to do your "own" work, and it doesn't make any difference where or when you do it
• You want someone to clearly tell you what to do and how to do it
• You are a <fill in the blank> technologist (e.g. Java, C++, C#, RoR, Scala, Fortran, LOGO, Perl, etc.)  and really aren't interested in anything else
• You believe that agile, at it's core, just another management fad, as is Lean and all the others.  Just let me code and don't worry about process.
• Automation is of no interest to you
• You are upset with the world for some reason, and believe work is a great place to express it
• You have to be the smartest person in the room

Seeing our software running on mobile for the first time!

~ @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.