Continuous Development Team Product Innovation in an Agile/Lean World

Hi all:

I presented one of my favorite topics at last weekend's Product Camp Austin 11 here in Austin, TX.  While the crowd turnout was fairly small, it was still a great session packed with tons of interactivity.  I have presented this content to the Agile Austin community a number of times, so I've been able to synthesize all the feedback from a variety of groups (Development, Product Management, Project Management) into the following slide deck.  The best way to convey the information is face-to-face, so I'd be happy to share my insights, challenges, and what we've learned if you have the time and inclination.

I also found this great article by Jeff Atwood titled "Today is Goof Off at Work Day" about the broader topic of open time for developers to innovate.

Enjoy!

~@MulticastMatt

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 Sustaining Engineering Be Agile and Engaging for Team Members?

Hi all:

I recently talked with a manager whose team's role is changing from main line product development to Sustaining Engineering (also known as Maintenance). He first wanted to understand how to adapt the agile process for his team, but as we talked, it became apparent that the bigger issue was keeping his team happy and engaged, as they were a bit nervous about what the change meant for them and their careers.

I was interested in exploring this area with him, and thought it would be worthwhile to discuss the concerns he had for his team.  I must be transparent and state that I have never served as a manager for a dedicated sustaining engineering team, so many of my thoughts in this area come without direct experience.  Perhaps it would be best to explain why this is the case.

Why Have I Never Had a Sustaining Team? 

It's not that I've never had the opportunity to have one, I simply rejected the notion and made it part of the responsibilities of the product development team.  I firmly believe that the notion of "sustaining engineering" may be indicative of a failure mode*.  Separating the responsibility for how code runs in production can lead to another "throw it over the wall" type of mentality that we as an industry are just starting to make headway on between development and QA.  More critically, it can totally disconnect crucial feedback to the product development team causing years and years of waste that could otherwise be invested in creating customer value.  

Here are some of the arguments I've heard in support of a Sustaining Team:

• "If we could free our development team from all those damn critical situations that come up in production, we could finally get some valuable features out the door and make some money."
• "We can get cheap resources overseas to handle fixing the defects and focus our expensive resources on the things that customers really want.  It just makes good business sense."
• "Development is constantly interrupted by fixing low-priority nits and we keep missing our release dates or drop planned functionality.  This has to end!"
• "Our releases are too long for customers to wait.  A sustaining engineering team will prevent our generally late releases from being even more so."
• "Are you kidding me?  We can't have our developers actually talking to customers, those guys are a bunch of mutants that can barely communicate with each other!"  (OK, I haven't heard this explicitly, but it's certainly implied.)

Each one of these points constitutes a failure mode that I won't go into here, but may be good fodder for another blog post.  As agile is "the art of the possible," I didn't see this as an opportunity to challenge the notion of the sustaining team, but I thought I'd help with ideas to make the team as effective and engaged as possible.

*Note:  one possibility of a non-failure mode could be a distinction between a team that is primarily interrupt-driven, and one that is focused on long-term goals.  This point was brought up by my colleague and may be useful to folks in some situations.  However, it is critical that the whole is being maximized for the benefit of the customer, company, and the individual software engineers.

Can Sustaining Engineering be Agile?

Sure--why not?  If you look at the Agile Manifesto there's nothing in there that that precludes the values and principals that are universal to software engineering and the humans who are engaged in its practice.  Process improvement frameworks geared towards software engineering such as Scrum and Kanban, and the modern engineering practices that support them (e.g. XP, TDD, etc.) are certainly as valid for sustaining a product where the work tends to focus on fix packs, platform certifications, and minor feature improvement.

Some might argue the semantics of "agile" vs. "lean" and say that Sustaining Engineering isn't agile and should be run through a Kanban process.  I would tend to agree that there can be benefits of running sustaining requests (essentially tickets) through a Kanban system, if for no other reason than the fact that near constant reprioritizations happen when dealing with a mature mission-critical product that is loaded with technical debt.  There tends to be a real need to release extremely quickly to production as well and the changes are smaller than large marquee features/epics associated with new product development.

One of the nicest things about Kanban, however, is it tends to visualize the entire value chain, at least when implemented to obtain the greatest customer value in the smallest amount of time.  Seeking to "maximize the whole" may lead to some very beneficial activities, which get to the manager's concern about having an engaged team.

"Re-Imagining" Sustaining Engineering through Engagement

Back to our conversation with the newly minted Sustaining Engineering Manager...He was nervous that his team may not be as engaged in their new work assignments and they would no longer be writing new valuable features and functionality.  As someone whose success is more than partially defined by the innovative products that the teams he serves delivers, I can definitely understand his concern.  It would be mine if I was in his place as well, and I came up with a few ideas.  It's important to keep in mind the context of these ideas--this is a team of product developers who are changing roles into sustaining engineers.  I'm not sure that they would apply to every Sustaining Engineering team.  My basic premise here would be to put yourself "out of a job" by eliminating sustaining requests through the constant improvement of the codebase.  What should be left is platform certifications (browser compatibility, operating system,  JVM version, .NET version, etc.) that are always changing and can be handled by the same team now that they have the capacity to do new feature development.

Note:  This is not a comprehensive list of "best practices" for Sustaining or Support--there are a ton of those.  These are just a few ideas about how to help a team of software engineers be fully engaged while they are part of a sustaining group.

• Create a target of business-specific technical debt reduction.  Identify common root-case problems in the codebase, often a source of Technical Debt to remediate common-occurrence problems.  In general, never have the same type of defect show up more than twice (fix it "right" the first or at worst the second time).  It is possible to eliminate enough of this debt where having a sustaining team just won't make sense.
• Fix the leak first before mopping the floor.  Reducing technical debt by a sustaining team will be useless if there is a product development team continuously creating it and making it worse with each new release.   A sustaining team can be engaged in evaluating new code that is delivered and acting as an advocate to increase code quality, or at least prevent new code from creating the next wave of customer critical situations.  
• Develop and employ modern engineering practices to analyze the code base and ensure that regressions are not "developed" along with fixes.  Many legacy code bases have weak automated testing, automated unit tests, and coverage mechanisms.  Configuration / builds tend to rely on "magic" of people who are long gone, or at least not accessible.
• Act as an alpha tester of new releases from the product development team.  No one knows better what kind of problems are out in the field and how the best features may flop when put into production more than sustaining teams.  Embed yourselves in sprint reviews (demos) and quite possibly act as the owner of final user story acceptance.  How's that for engagement?
• Funnel innovation - because a sustaining team operates so close to the customer, they are many times the closest ones to know what the customer pain points actually are.  Sustaining members can act as powerful contributors to a product advisory board/committee and have the weight of real customer feedback when they speak.
• Delight customers by being able to predictably deliver fixes.  One powerful technique to do this involves measuring average cycle time for defect fixes though a process such as Kanban.  Scrum iterations can also be used effectively here as well.  Most customers don't need their fixes "right now," but have been burned so many times by missed expectations.  If a schedule can be made transparent to customers and that schedule is constantly made good, customers will start properly assigning severity to issues.
• Rotate with the active product development team.  This gets really close to my initial idea of just having one team that does both new product development and sustaining work.  Think of this as a hybrid model where there is a constant trade of learning between new product developers and developers that couldn't be closer to customers.

Additional Reading

Thanks to John Heintz (@jheintz) for some additional great reading around Sustaining Engineering, some of which may contradict or amplify the ideas I've presented:

• Everything I can find about software maintenance /DZone
• David Anderson's "From Worst to Best in 9 Months", which was used as part of the basis of his work developing Kanban.

What do you think?  Do you agree/disagree with these points?  What's worked for you as a Sustaining Engineer to have mastery, autonomy, and purpose in your work as a team member?

Image via Creative Commons, Jose Franco's (jose_franco_) Flickr photostream. (source)

Guest Blog: Are Doc Sprints Really Agile?

Welcome once again to my friend and colleague, Janice Hamrick, with her latest perspective on helping whole development teams attain agility through effective technical writing.  Unfortunately, technical writers, who are crucial members of the product development team, are often siloed for the sake of "efficiency."  I've been serving my teams for years by insisting that stories are not complete until there is adequate documentation, and it has driven dramatic positive changes from the perspective of people, product, process, and tools.   If you like this post, please check out her other two posts (How Agile is Like a Guitar and Tech Info Fits Into Agile Software Development and 3 Ways to Make Documentation as Agile as Development).
~@MulticastMatt

Some development teams choose to separate documentation from the rest of the development work.  In fact, the Society for Technical Communication (STC) recently held a seminar entitled, “Doc Sprints: The Ultimate in Collaborative Doc Development,” which included the following description:

“Many technical writers find themselves in agile environments, where time is at a premium and it can be difficult to pry the developers and other subject matter experts away from their day-to-day deadlines.”

The problem with this practice is that it violates almost every principle of Agile and causes problems for all members of a team.

What is a “doc sprint” as opposed to a sprint?

A doc sprint is just that – a sprint containing only documentation tasks. Often, the only member of the sprinting team is the writer, with nonexistent or at best nominal support from the rest of the team. Dev and Doc are like milk and cookies - they should always go together.  If you are having separate doc sprints that lag behind development sprints, YOUR TEAM IS NOT AGILE.  Documentation is as important to software development as coding and QA - no story is done unless it’s fully coded, tested, and documented. 

Why should it be difficult to pry developers away from their deadlines?

If your team is truly Agile, EVERY team member is responsible for every user story. This means that developers are as responsible for providing content and reviews as they are for coding.  If a writer is blocked and a doc task can’t be completed, then the story can’t be closed.  This provides the means and the motivation for excellent communication and cooperation among all members of the team, and ensures the documentation gets the attention it needs from all concerned.  If a team conducts separate doc sprints, dev and QA have already moved on to something else by the time the writer starts and will have to switch context to provide information. Moreover, dev and QA very likely have not budgeted time into their own sprints to work with the writer – after all, their stories apparently can close without documentation. This leaves the writer in the uncomfortable position of “prying” developers away from their “real work” or resorting to begging (or threats). Plus, the likelihood of missing information altogether (because it’s no longer current) or of being shortchanged during review cycles increases astronomically. The doc quality suffers, team relationships suffer, and ultimately product quality suffers.

Why are writers different from any other team member?

The short answer is that they shouldn’t be! However, in many organizations, tech writers report to a different business unit than development teams, a situation that can leave writers feeling like outsiders because they are treated like outsiders. I know writers who are left off mailing lists, who aren’t included in team-building training, and who are sometimes the last to know about feature changes.  

For real Agile success, writers must be real team members. It might not be possible or even desirable to change the management hierarchy of your organization, but it is possible for teams to ensure that writers are first-class team members.  The first steps include making sure everyone on the team understands this (management support is essential), eliminating doc sprints, ensuring doc tasks are part of the team user stories, and planning for the time needed to provide content, write, and review the doc. 

Is there ever a good reason to have a doc sprint?

Probably not.  There might be a reason occasionally to have a doc-only user story (for example, if your team decides the product needs a new user guide), but even in that case the team is responsible for content and reviews.  No one team member, whether writer or not, ever works in a vacuum. All stories require commitment by the team, and as such should be incorporated into team sprints.

Your thoughts?

Does your team hold separate doc sprints or are your documentation tasks integrated into the development sprints? How does that work for your team and the quality of your product? 

About the Author

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-winningJocelyn Shore mystery series (DEATH ON TOUR, DEATH MAKES THE CUT, and DEATH RIDES AGAIN, Minotaur Books), and is currently working on a new novel.  She lives in Austin, Texas.