Part I – Ode to Joy

Since the launch of the seminal “Joy” work which hopefully doesn’t need mention here, we’ve seen everything from The Joy of Cooking to The Joy of Not Working (my personal favorite!), and so further to that deeply mined vein of authoritative works we bring you the necessarily over burdened… Joy of Code Review!

Joy, you say? Let me count the ways…

• I implement a task, using what I consider to be best practice patterns and guidelines; I slave over this, my creation, and when it’s done, I stand back and admire, much in the tone of an old master, this latest image of my greatness.
• Then I remember I need to get it reviewed…
• So, I timidly invite my Architect and 3 of his best friends to the war room to review my new baby
• After many rescheduling pauses, we finally gather…
• I hold my breath, turn on the projector, and bare my soul to the collective seniors in attendance
• 30 minutes later, having endured a ritual mind flaying, and the predictable but nevertheless enjoyable tortured examination of my parentage, education, upbringing and such fun rhetorical musings as “why do they let people like you graduate?” I slink out
• Follow up is, if anything, more painful as I’m reminded moment-by-moment of just how badly I’ve lived up to the expectations laid out for me by the senior team members

Anyway, so code reviews suck, amirite? But we all know we need to do them. Of course, we all know we need to do them for completely different reasons from each other…

• Kids right out of grad school know they need to do code reviews because although their code is, like, totally perfect, it’ll be good to show the old dudes their skillz, and for the old dudes to check out some rad new stuff that they might have missed along the way.
• Senior guys know they need to do code review because otherwise all kinds of terrible cruft will get promoted into the head branch and somebody (are you looking at me??) will have to fix it…
• Managers know they need to do code reviews because they read all about them in a book with a cool cover, and it’s all Agile and stuff, and let’s face it they’re being measured on code review coverage, so come hell or high water you’re going to do code reviews!
• And of course, regular professional developers know that code reviews, however painful, genuinely lead to better code, regardless of the pain involved in getting there.

What we have here, folks, is a social organization, complete with the crazy uncle, the embarrassing grandma and the pimply teenagers. And social organizations, as we’ve all come to know and love, are at their best when the forum in which they’re fostered exists for a reason that encourages the unstated, but nevertheless in-your-face activity of which those in the respective societal groups are desperately in need:

• Facebook? Getting a date. And then getting another one while simultaneously trying desperately to avoid the previous partner. Rinse/repeat. Seriously, I have no idea how kids manage today. At least when I was young and awkward we could hide behind the silence and foot shuffling of real face-to-face meetings. Now with a keyboard and the internet in the way, there’s nowhere to hide!!!! I’m off topic again… ahem…
• Linked-In? Getting a job.
• Myspace? Getting a clue.

You get the idea.

So code review as a social engagement… really? Parts 2 and 3 of this series of posts will examine how such interactions, fostered by social networking tools, are the best way to ensure code review gets done and returns value both to the participants and to the companies in which they work.

I have always loved “I’m gonna write me a new minivan”  from Scott Adams.  To me, it never gets old.  Originally published in 1998, the theme that applied then still does today: driving 100% of defects or bugs out of the code-base is a laudable goal, but is it really the right one?   I would have to argue no.  There’s no silver bullet out there that will find all software defects and solve issues automagically, and until there is, software development will continue to struggle with prioritization.  Unfortunately, we live in a world of finite resources and constantly evolving demands, but we can always dream about being Wally for a little while.

I remember that idyllic summer day when I saw my very agile dog Maggie jumping through the sprinkler. I laughed until I cried. And then I thought:  This reminds me of what I do for a living.

Jumping into the Agile fray: a technical writer's perspective

I’m a technical writer and technical writing in an Agile environment is somewhat like chasing those water drops.

You can run after those features, but early in the game there’s not really anything to hold onto.

So, how does one document a feature that will probably change from one iteration (or day) to another without chasing one’s tail?

Workflow can be your rock in that ever-changing environment. While the feature is likely far from finalized, someone’s gotta have an idea of how people are going to interact with it.

The developers can get you started, but the workflow people (at least in my experience) are the product managers.

So, while my agile dog chases water drops, this technical writer chases product managers—and if I still don’t have enough of a big picture outline for the feature or a collection of features, then the Chief Technical Officer is in my sights.

For major features “in flux”, the best way to get “good enough” content to meet your iterative deadlines is to channel the Australian shepherd within and herd the developer, product managers and testers into a room with a whiteboard and a marker.

In half an hour, you’ll get something workable. And maybe a chance to put your two-cents’ worth into the design.

What if there’s no workflow available?

If it’s a sunny day, go find a sprinkler to jump through. These days, that’s a chilly prospect indeed.

In part one of Going Agile,I talked about how we introduced Agile to our development team. This next post will look at the events that led to our first iteration planning meeting.

During the weeks that led up to Iteration 1, there was much work that went on as a team, and much that each team member did individually. As the Product Owner, my biggest task was to create a backlog. Sure, I knew what the main new features were going to be, but I still needed to capture this, and add other oft-requested features. I scoured every correspondence I had with customers, sales, support, development, and so on to gather this information.

After everything was said and done, I had a pretty massive backlog… a pretty massive, unprioritized backlog. At this point, I really didn’t know any good techniques for backlog prioritization (that would change after attending the CPO training with Mountain Goat Software). This training was not going to happen for a few months, but something needed to be done… so I did what any good Product Manager does…I used the ‘wet finger in the air’ technique. Now, my ‘estimations’ were based on a number of concrete data points and some not-so-concrete assumptions and anecdotal evidence, so they weren’t totally of the ‘wild-assed guess’ ilk. After a few more days I had my backlog read for the team.

While the backlog creation was going on, a number of team meetings were occurring. Two of the more important meetings involved creating rules for the team and preparing our definition of “Done” . I highly recommend spending some time up front on both of these activities.

Creating the team rules was a great exercise, because it was the first time the team sat down as a collective and decided what the rules would be. Many of the rules were not groundbreaking…things such as everyone’s opinion is equal, treat everyone with respect, don’t be late for meetings, and when and where daily Scrums were going to happen.

The best result from this meeting centered on the team’s communication methods. Everyone was already using email, so that was covered. Instant messaging was rolled out to the team, and everyone was to use it. Of course face-to-face discussions were encouraged the most, but there needed to be some way to let people know you didn’t want to be disturbed (unless something was urgent). Everyone created a Do Not Disturb sign, and when it was posted, it was to be respected. Sometimes people just need to focus on the task at hand, rather than constantly being disrupted. We came out of that meeting with a clear set of easy-to-understand team rules, and we posted these rules in our team conference room for all to see. Note… rules can and will change over time.

Next was coming up with our definition of Done. The team sat down for a couple of hours to determine what should/should not be included. Looking back, we thought we were cavaliers and were blazing new trails with the definition we came up with…in reality, we put together a definition that was pretty much in line with the ‘industry norm’. One thing that we did not include initially was code reviews…that is, for a story to be considered done, the code had to be reviewed by at least one other developer (who was not associated with that piece of code). During our Iteration 1 retrospective, we modified our definition of Done, and code reviews became part of it. In fact, this definition of Done may go through many, ahem, iterations before becoming finalized.

Finally, we needed to get our ‘room’ set up and have all the necessary supplies on hand. Our team decided to use a wall board with color-coded cards for the tasks. Green cards were for development tasks, red cards were bugs, blue cards were for testing tasks, and yellow cards were for documentation tasks. Now we just needed a board to pin these tasks to. We didn’t want to spend a small fortune on a big pin-board, so we got creative and used carpet under padding. (You can get a huge piece of this at any DIY store for next to nothing and it works like a charm.) We fastened it to the wall, put on some masking tape borders and labels, and we had ourselves a Scrum board.

So with our prioritized backlog, team rules, definition of Done, and Scrum room all set, we were now armed and dangerous, and ready for our first iteration planning meeting…TO BE CONTINUED.

The first instalment in my ‘Going Agile’ series will reflect on the earliest days that led up to our development team becoming an Agile development team. Before I get into this too deep, I should first set the stage a little. This organization is a medium sized ($500M in revenue) software company, with no other teams using Agile techniques. We were going to be the first. The product was well established, having been on the market for about 5 years, and traditional development methods were fairly effective from a delivery and quality perspective. The team comprised of about 12 members, which included all developers, testers, documentation, the Scrum Master, and myself as the Product Owner.

The first meeting ever held with the whole team was intended to introduce Agile (Scrum) to them and get their buy in…we did not want to ram it down their throats and say we are doing this. At the time we were doing this, the concept of an Agile Coach was pretty much non-existent, so we were on our own. Our Scrum Master had been on some training, and thought for this meeting it would be good to try an exercise with the team to illustrate how Agile could work. So without any preamble or mention of Agile, everyone in the room was instructed to pick a partner, and then the goal of the exercise was explained. The goal was to navigate your team member around the room as many times as possible in 1 minute. Seemed pretty easy, until we told them about the twist…the team member that was walking around the room was to be blind folded. To add to the fun, our Scrum Master played the role of a roadblock, stepping in front of the blind folded people as they tried to circle the room, requiring new instructions to be shouted out to navigate around him. Once the clock started the chaos broke out, as 6 different people were simultaneously shouting out instructions trying to navigate their team member around the room, and around the roadblock. By the end of the 60 seconds we tallied total trips around the room, and came up with a number in the 30’s.

The 2^nd part of the exercise was quite a bit simpler, and merely had all team members walk around the room (no blind folds), and make their own decisions to navigate around the room and the ‘roadblock’. I’m sure you can imagine how much calmer the room was, and by the end of the 60 seconds we again tallied our results. This time we were well over 120.

So what was the purpose of this exercise, and how did it relate to Agile? Basically it illustrated the power of a self-managing team, and how the productivity of such a team can be magnitudes better when team members are given the ability to make decisions on their own, in real-time. After the exercise, we then introduced the idea of the team adopting Agile, what it is, how it could work, etc. In my opinion, doing this exercise first (and doing it without ever mentioning the term Agile) did more than a week’s worth of powerpoint sessions on why Agile is the way to go. The team was very receptive to the idea (at least most members, more on that in another blog), which set the stage for a series of follow on meetings to further flesh out what was really involved, and what needed to be done to prepare for our first Iteration. The next instalment in this series will delve into that preparation.

Agile technical writing is a popular topic in the blogosphere (see Edwin Dawson’s recent three-part blog series). The user communication team at Klocwork is becoming more agile in fits and starts. In the last release, we joined our development team in using Xplanner, and found that it both reduced that horrible did-we-miss-something feeling and increased the visibility of our status.

In this release, we’ve resisted the urge to create a matching help story for every dev story. Instead, we create stories that allow us to focus on the highest-priority types of information: what’s new in this release, how the system works, how to get started, and how to use the tools day-to-day.

Our biggest struggle with Agile right now is how to stay on top of feature development while working on our own help-specific stories (like the current crazy-making idea of moving our help to a Wiki). Here are a few things we’ve learned along the agile way:

• “Just barely good enough” can mean documenting a feature only in the “What’s New” guide in an early iteration. This forces us to understand the “why” of a feature. It’s easier to ignore the “why” when you’re writing step-by-step procedures. Later, we’ll add information on getting started, a detailed how-to, and any necessary reference information.

• Workflow is king. If we don’t know how users will incorporate a tool into their environment and use it day-to-day, there’s no point writing a lot of words about which button to click when. So we push for details on workflow. And once a few customers provide feedback on a proposed workflow, the how-to starts to write itself.

We’re hoping these ideas will help us forge enough of a path through the agile doc frenzy to retain our sanity through the release.

After attending Agile 2009 in Chicago, and speaking with so many people about their experiences with Agile, I thought it might be an interesting opportunity for me to do the same. So with that as my inspiration, I’ll be putting together a blog series that will cover a number of topics ranging from introducing Agile to your team, through to the release, with a number of other interesting subjects in between.

The series is in no way an attempt to tell you how to do things, but rather is intended to share experiences that I have had…perhaps you will read them and say to yourself, “I’m glad we’re not the only ones who went through that!”

The series kicks off next week discussing our team’s early days with Agile. This will introduce you to some of the key players in the team, how Agile was introduced internally, the training we went through, and so on. Other topics I have planned for this series include the 1^st Sprint preparation and planning, Retrospectives, team communication, developer issues/concerns, and finally the product Release.

Hopefully these blogs will strike a familiar note with you or give you something new to think about. In the meantime, if you have a particular topic you would like to see discussed, feel free to email me at todd.landry@klocwork.com, or find me on Twitter at http://twitter.com/todd_landry.

Main topic of today is using Agile in an FDA regulated medical device context. Sounds like an impossibility I know, but the folks from Agiletek and Abbott presented a very interesting case study on how they did it. They started off by presenting “the way it used to work”, highlighting an older product development cycle from the 1990s that had very strictly defined dev phases, including a 10-12 week integration cycle – yikes! When they decided to implement Agile on a more recent project they broke up their 3-5 year dev cycle in 6 week iterations. Here were the biggest barriers they found to achieving this:

• Documentation – they tackled this topic upfront. There is a perception that the FDA wants truckloads of docs from medical device manufacturers. The reality is, according to the presenters, that’s not the case… the FDA wants “enough” documentation to demonstrate your process (“least burdensome” in FDA-speak). The biggest area is of course documenting requirements which they did through a Capability Matrix.
• Requirements – this required a big culture shift. They talked about past projects with 14 month requirements definition phases… which still didn’t capture everything! Now, they realize it’s a myth that all the req’ts can be defined upfront, and as the gentleman from Abbott stated: “Your requirements are final when the product is retired from market.”
• Software verification and validation (V&V) – they emphasized a risk-based approach. Run code inspections and reviews on the most critical areas of code. Keep your requirements focused and high-level so testers are testing the important stuff.

Anyway, here are the results they found by modernizing their development with Agile: higher visibility, lower costs (estimated schedule and team size reduction of 20-30%), higher quality product (availability of working software allows for continuous V&V), and overall the project had a steady pace to it rather than mad integration scrambles or backend V&V chaos.

The one big aspect of Agile they weren’t able to implement is the customer feedback component. This is mainly due to the limitations med device companies have around “pre-marketing” their product.

All in all, a very interesting case study. Be interested to hear where anyone else has seen this done in a highly regulated environment.  Signing off from Agile 2009… be sure to follow us on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich

Busy day 3 with a number of sessions.  We attended: Strategies for Replacing Systems in Agile Projects, How to Evolve a Product Backlog, Agile Metrics and Four Core Concepts for Fast User Feedback.

In the discussion for Replacing Systems I certainly got surprised by one of the strategies.  The first release of the replaced system should be inferior to the existing system.  At first I thought Niklas was crazy but this started to make sense when he describes that there are infinite ways to compensate users and make it balance out.

The next session I went to was the “Evolution of Product Backlog” given by Ronica Roth.  This session took us through a couple of real cases (which is always nice) of how they evolved the backlog. Good session but I felt I needed more details.

Probably the best session I’ve attended so far was “Agile Metrics” by Dan Rawsthorne.  The key messages given were that you don’t just measure something just because you can.  Instead you measure things that tell you something about your team, product or progress.  We learned how to measure production during sprints, after sprints and then got into the hardcore stuff of release metrics.  I think I’ll leave the release metrics for another day ;)

Todd also attended “Four Core Concepts for Fast User Feedback”.  Overall Todd thought it was the best session he had attended so far as well. The presenter was engaging, and definitely knew what he was talking about. In the session he went over the 4 key principles required to run a good interview, those 4 being Context (talk to users while they work), Partnership (let the user lead, after all, they know more than you), Interpretation (figure out the meaning of what is happening), and Focus (know why you are there).

Watch for our Day 4 summary tomorrow and be sure to follow us throughout the day on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich

Agile Product Management and a lively talk about modern software development by Alistair Cockburn were the themes of the day. The day started off with a hotel breakfast buffet at 6:30. One thing I rarely miss when I travel is a good breakfast to start the day.

My speaking opportunity was, um, unique. Basically a bunch of stages set up around all the food. Oh, and also starting at 7:45 AM. I was able to rush through my presentation and still answer a few questions.

Next was the keynote speaker, Alistair Cockburn. He arrived in dramatic fashion with a bag pipe player leading him onto to the stage, then quickly started reciting a famous passage from Shakespeare’s Julius Ceasar, changing key words from the original play to a more “Agile” flavour. Quite entertaining really. He then proceeded to talk about the main pillars of Agile, interjecting personal experiences and anecdotes. Everyone seemed quite engaged with his talk and gave him a great ovation when he was finished.

We attended the Product Manager/Product Owner Dilemma session presented by Rich Mironov. Very entertaining presenter who identified the key differences between Product Owners and Product Managers. Key takeaways for me were 1) that the overlap between the Agile community and Product Management was very small; 2) Agile development is a big part of business agility; and 3) the Product Owner role adds 40-60% more work than the traditional PM role. Overall a good presentation that concluded with a spirited Q&A discussion.

Watch for our Day 3 summary tomorrow. Be sure to follow us throughout the day on Twitter:

Brendan Harrison
Todd Landry
Alen Zukich