Search This Blog

Saturday, February 16, 2013

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

Tuesday, February 12, 2013

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.