Agile Governance: Oil and Water?

December 2, 2008

When I first sat down to write about agile governance, my mixed metaphor and oxymoron meter started redlining. As I researched to see how prominent this topic has been, I encountered phrases like “tail wagging dog” and “are you kidding me?” It seems that the Agile advocates and the governance advocates don’t see eye to eye, if they even talk to each other at all. While several authors have addressed this topic (notably Dr. Peter Merrick in a recent article in Information Age), most of the coverage is theoretical. My goal in this post is to outline some practical approaches to ensure that the requirements of large-project governance can be met by engineering teams that employ Agile software development methodologies.

Let’s start with some working definitions. I define governance as accountability and risk management of IT projects and resources as perceived by non-engineering personnel. Agile can be defined as the set of engineering methodologies that rely on incremental development cycles, flexible long-term planning, and rigid short term-planning. Though many will comment on these definitions, they will serve for our purposes here.

Looking first at governance, it should not surprise anyone that the CFO or CEO of a Fortune 500 company might be interested in exactly how their $100M annual IT budget is being spent and how this spending benefits the company. That’s their job as representatives of the business interests of the organization. Similarly, the business stakeholders at an independent software vendor, such as account representatives and product managers, need visibility into the activities in engineering in order to communicate to customers, investors and other external stakeholders. Put another way, governance of engineering assets is a requirement for business - without it, the engineering or IT organization is operating in an opaque fashion without accountability.

On the agile side, it should also not be a surprise that after decades of being blamed for late projects, over budget software releases, and failure to meet customer requirements, engineering organizations are fast embracing agile as a way to manage software development projects. Starting with the axiom that requirements are rarely fully specified, agile provides a scheduling and requirements management framework that enables teams to work successfully on under-specified requirements today, and adjust their plans as requirements change tomorrow, next week, or next month. Put another way, agile solves the requirements management problem that every business has - without this solution, the engineering or IT organization may be transparent (”See, here’s our project plan”), but is likely not satisfying business requirements.

At this point, I am reminded of the old joke: Do you want to make God laugh? Just tell Him your plans. Businesses need to plan their activities to ensure that resources are accounted for and are working to further business goals. Engineering teams need to work on requirements that don’t change, so that the work is focused and efficient. The question then becomes, how to reconcile the governance requirements that business stakeholders have with the just-in-time requirements management approach of agile? There are three practical things that organizations can do to ensure that agile benefits not only engineering, but the business as a whole:

1. Agree on high-level requirements. This is more than just ’software or salsa’. It means that someone in the organization (a product manager at an ISV, for example) must take ownership for extracting and documenting requirements at the highest level. The great myth around agile is that there is no documentation - not true. There is no extraneous documentation. Everyone needs to agree that the organization needs to build an X that meets these A,B,C customer requirements. Agile purists who resist the creation of this document should be taken to task, as should product managers and other business stakeholders who want to meddle in engineering implementation details.

2. Plan for change at the business level. Given high-level requirements, the temptation for business stakeholders is to say “I’m done with my part”. That’s not agile, nor is it realistic. If your engineering organization is working with 30 day sprints, it’s the job of the business representatives to actively evaluate not only the requirements in the backlog, but also the output of each sprint, so that the next 30 day sprint is planned in accordance with any new information about the business requirements of the project.

3. Make governance a part of the agile process. This is the hardest part for engineering organizations to swallow. But the engineering or IT budget isn’t a gift from Santa - it is a hard number that your VP of Engineering or CIO owns and is accountable for. So it makes sense to add a step in the process at sprint review time (the post-evaluation that occurs at the end of each sprint) to formally document the project progress in a form that is useful for the rest of the business. Included in this report should be at a minimum what features were completed, what the cost of these features are, what the rollout plan is for these features, and what percent of the known requirements have been satisfied to date. In this way, the internals of the agile method are only minimally exposed to business stakeholders, who may not know nor care what a sprint is, but the results as they affect the business as a whole are transparent.

I’m sure that readers could come up with a few more practices, or critique my brief set. That’s great - what is needed on this topic is cooperation and frank discussion, so that businesses can move forward with more efficient engineering organizations, and with improved ways of communicating engineering activities to a broader business audience. Ultimately, both agile and governance are about making sure the business is working on activities that add value to customers. So it is in the interest of both agile practitioners in engineering, and business stakeholders across the organization to work together to blend agile and governance in a practical way that maintains the efficiencies of agile, and also advances and meets the overall needs of the business.

Interested in more on this topic? Attend a free live webinar with guest speaker, Jeffrey Hammond, senior analyst, Forrester Research on Thursday, December 4 at 1:00 PM EST:  The Business Case for Pragmatic ALM: Agility with Governance

This Webinar is now available as a recording here: Pragmatic ALM

3 Comments | Agile | Tagged: , , , , , , , , , , | Permalink
Posted by Matthew D. Laudato

Dr. Strangecode, or How I Learned to Stop Worrying and Love Old Code

September 17, 2008

by Chris Boran

Several years ago I happened to be browsing in my favourite local bookstore and one book in particular caught my eye: Martin Fowler’s Refactoring: Improving the Design of Existing Code

This is the book that changed my whole career. Up until that point, I had lived in a constant state of fear of change. I viewed old code as a house of cards - if I wasn’t very careful, it was all going to come down around me. Whenever my boss asked me for advice about what to do in a given area of the code, my answers were almost always similar to:

The risk of doing anything but the smallest possible change is huge - so either we do something that is an ugly hack that we will regret later, or we need to take the whole thing apart and re-implement the whole subsystem from the ground up.

And predictably, my boss’s answer was always something like:

Okay, we will live with the hack for now, but in the next release we will make time to do it right.

Of course every release we were forced to make many similar decisions. When the next release would come, the newly conceived product features would get priority over fixing code that was already working passably. In practice we might get lucky and be able to spend lots of time rewriting a single small subsystem, but introduce ugly hacks that would put 4 other systems on the map for future re-implementation.

The end result is affectionately referred to as a Big Ball of Mud. Yup, it is every bit as pleasant as it sounds. Life is just so miserable when you come to work every day knowing you are going to have to pack another layer of mud on the ball. You gripe about it. Your teammates gripe about it. Your boss gripes about it. Somehow you never seem to make a whole lot of forward progress.

As I read the book, I was at first skeptical. I thought that bad old code needed to be thrown away and not revitalized! But I wanted to see if it would work, and so I set out to try it. I was very careful to follow the techniques exactly as they are laid out in the book. I made sure not to use the word refactor when I really meant rewrite. I was careful to refactor the code every time I saw something I wanted to change and not just note it for later. I made sure that my refactorings were small. I took my time with it.

Obviously working this way required that I also be doing very good unit testing, but I had already bought into Test Driven Development. I was already writing unit tests for code before fixing bugs in an attempt to prevent regressions. Running these tests after each refactoring was not a big challenge for me.

Bit by bit I discovered the truth. By applying the refactoring techniques, I could take pieces that I thought needed to completely rewriten and make them better while I was fixing bugs in that area. I could kill two birds with one stone.

Then I discovered Eclipse. The built-in refactoring browser captivated me. Suddenly there was a good, fool proof way to do many of the common refactorings, and automation to keep them introducing new errors. My commitment to refactoring was completed and the defect rates in the code that I was responsible for maintaining declined dramatically. I was a convert. Since that time refactoring has been a cornerstone technique in my arsenal. I no longer lived in fear and loathing of old code!

One refactoring that I have still found to be painful, despite Eclipse’s facilities, is renaming files/classes. In most software configuration management (SCM) tools, renaming files can have unfortunate unintended side effects because the identity of a file is its path. This leads to a great many developers to name a class once, and then never change its name - even if that name does not make sense and the design of the code and the classes primary purpose and responsibilities change.

Luckily for me, I am a long time Accurev user. In Accurev, files are not identified by their pathnames, but rather by a unique id. This makes it possible to quickly and easily rename files with no negative side effect. However this process was inconvenient - I would have to drop out of Eclipse, rename the file with Accurev’s tools, and then refresh my workspace. Not ideal, but it worked. That is why I was so pleased when the Accurev-Eclipse Plugin was released - it integrated the Eclipse Refactoring browser’s rename actions with Accurev’s capabilities to make the whole experience seemless. Accurev has helped me to maintain well thought out, easy to understand designs despite constant evolution to those designs.

6 Comments | AccuRev, Agile, Best Practices, Customer Guest Blogs, Tips and Tricks | Tagged: , , , , , , , | Permalink
Posted by cboran

Agile 2008 - Agile Skeptic?

August 13, 2008

By Josh Sherwood, AccuRev engineer

I had the opportunity to co-present a talk on Continuous Integration at the Agile 2008 conference this past week. While there I took the opportunity to attend a variety of sessions. Workshops discussing Business Value, Experience reports describing transitions from Waterfall to Agile, Aspects of Leadership in and Agile Environment and many others. And okay, I’ll admit that I have been a skeptic of a variety of the Agile Processes. Our CTO, Damon Poole, has been an Agile advocate for some time now. He and I have had ongoing discussions about the value of Agile practices. We would talk about the iterative model, going back and forth about the value and how to describe it to different groups. We’d eventually come to an understanding, but there were still many elements that I have been skeptical of and found difficult to see their value.

In addition to the elements of Agile practices that Damon and I would discuss, I started taking a look at other Agile topics. I looked at things like estimation, use of 3×5 cards and even pair programming. I didn’t see the value in the sticky note processes, I mean using a paper process to discuss a digital product? I didn’t see the value in pair programming, especially for consulting companies where your development hours translate directly into billable hours.

But then I came to the conference. I listened to people like Richard Sheridan talk about his experience with Pair Programming, why and how it worked for him. I listened to experience reports from companies like Healthwise, and heard about the difficulties they overcame to improve prior processes and move into Agile. And I spoke with Scrum trainers, who were encouraging their customers and helping them overcome the hurdles of understanding, while remaining flexible about sharing Agile ideas.

What was great about things like the Pair Programming was the team participation. Not only was Richard there talking about their factory model, team members were in the audience, talking about what they take away from the model. They talked about some of the things an individual developer would run into. You know those times, where you are working on a particular problem and just can’t quite figure out how to break the bottleneck. You wander around, get some coffee, or browse the web checking the Olympics. With their pair model, now that bottleneck has two developers working on it. No they’re both not checking their email, they are floating ideas back and forth, bringing to bare the problem and coming to some resolution. With a close proximity to other pairs they are also propogating these ideas farther out amongst the group. Yes there is training and not everybody can manage to work in pairs, but by using this model and actively rotating the pairs they ensure there are no knowledge silos. If someone is out one day there is more than one person who can tackle the problem at hand.

It has been a community of ideas this week. Some people use Scrum but don’t perform retrospectives. Some people model agile practices, but don’t follow a specific practice. Some people are taking the team based processes and developing large scale models for larger development tasks.

As I sit here building out the story for some of our future ideas, I’m encouraged that we can adopt more of the Agile practices than we have in the past, work through some of the confusion those ingrained in waterfall have with new processes, and further the practices that have allowed us to deliver innovation at a faster rate than we could with older models.

1 Comment | Agile, Events | Tagged: , , , , , | Permalink
Posted by jsherwood

What Can Developers Learn from their Surgeon?

July 30, 2008

I recently read a story that the World Health Organization (W.H.O.) issued a new safety checklist for surgical teams. Checklists sound great and frankly it was kind of surprising they weren’t already in practice. Here at our company we go through a number of checklists, and I can only assume you do as well. There are testing checklists to determine what test coverage exists, process checklists when products are about to ship, and integration points themselves could be considered a checklist of activities that need to occur for success.

What I found particularly interesting were the topics covered in the checklist. There are fundamental items like marking the location of the surgery, but I found the following to be the most topical:

*    Confirm that all team members have introduced themselves both by name and by their role on the surgical team.

*   The surgeon, anesthesia professional, and nurse should verbally confirm the patient’s identity, surgical site, and procedure to be performed.

*    Anticipated critical events to be reviewed by the surgeon are any critical or unexpected steps, estimated operative duration, and anticipated blood loss.

Keep it High-Level

Blood loss aside, what I find interesting about these items is how high level they are. You have team members participating as a team, identifying the areas of focus and activities. Staff executing risk analysis. Providing estimates. This is great.

SCRUM

We’ve been using Scrum. This means we have a 15 minute meeting once a day to go over our activities. We talk about what we did yesterday, what we are doing now, how long it should take and any risks to success. Sound familiar?

SCRUM HURDLES to HURDLE

Although Agile has been going well here for a while, there may be a number of initial hurdles to watch out for if you make this kind of change. Having to coordinate a day and time for all team members, then trying to keep the meeting to 15 minutes can be a challenge. It’s far too easy for development staff to lapse into traditional practices. When we first went to Scrum some of us would begin to discuss specific issues during the meeting (a Scrum no-no), and people would obviously start tuning out. This then translates into not knowing the more high-level team goals and activities.

Our first attempt to fix this, having everyone send a daily status email, at first just went to the team lead. The team lead knew what was going on, but it still didn’t solve the larger goal of having people be aware of their role and its impact on the team. We then tried to fix this, by group consensus, by everyone emailing the group with their daily status. This had the advantage of getting the format of the data consistent amongst the team, and getting information to everybody in the team. But it doesn’t get people to read the email. I now have a filter that automatically drops these into a directory that makes them easier to find, open, and read, or scan depending on my level of caffeine.

NOT LOSING SIGHT OF THE GOAL

So what I see as part of the goal, as well as what the W.H.O. was trying to achieve could be lost. Without the physical meeting everyone remains caught up in their own particular goals.

These personal goals are necessary, but they are not always conducive to team productivity.

Here we use Continuous Integration. We’ve been progressively converting more of our attended tests to unattended, increasing our product coverage and productivity. At the same time, staff members have been changing the test infrastructure to allow us to test varying configurations. Both are great goals, but in the beginning they ended up in conflict. One engineer was making more configuration settings required while another staffer was trying to make more of the configuration settings dynamic for portablity. The newly unattended tests were hanging or exiting early because configuration items unexpectedly became required.

Without a common goal, or at the least an understanding of everyones goals we run into conflict.

What else can be done?

When developers are used to being siloed, and their work feels isolated, they are more likely to tune out as to what is being done around them. But integration has to happen. And it has to work. Integration should no longer be thought of as somebody else’s problem, or as something that happens after the fact. Yes I was one of the people who didn’t like yet another meeting. I was one of the people who sometimes drifted into the mundane details of my work that I thought others would want to know, eating up meeting time. Now I champion the 15 minute meeting and keep people quick and to the point. And if everyone can start feeling like integration is the goal, then people will start thinking about how their work impacts others. Sharing that information in a timely manner will smooth out the bumps, and ultimately get us more focused on the larger goals. This isn’t “brain surgery”…or is it??

No Comments » | Agile, Best Practices | Tagged: , , , , | Permalink
Posted by jsherwood

Why Traceability Matters

July 16, 2008

In a recent blog post on CodeSqueeze (http://www.codesqueeze.com/the-blame-game-how-necessary-is-traceability/) the subject of traceability and its utility in software project management was discussed. This post is a response to the author’s points on traceability. While I agree with the author on some points (especially that traceability can be used proactively), I believe that traceability has much greater utility in the development process and in the management of software projects.

Traceability, both at the code and issue levels, provides you with fundamental process metrics. By removing these metrics, you lose objective insight into the state of the project. Using such metrics for a blame game may indeed be a sign of poor project management, but not having the metrics at your disposal is a sign that you are not controlling the process, and that puts your project at risk. I can’t imagine other engineering disciplines such as chemical engineering even having this conversation - you measure (almost) everything that can be measured, and then determine which metrics are most useful in improving the process. The best engineers on your team will welcome objective measurements into their code - like having the fastest time at the racetrack, doing well by a set a metrics that are not easily manipulated is something to be proud of, and something for more junior engineers to aspire to.

As for feature traceability, some of the comments on the blog point in the right direction - for example, that in regulated industries, such traceability is a requirement. ‘We all trust each other’ doesn’t fly well with the FDA or DOD. But even beyond the regulated industries, traceability and related metrics answer questions that are too basic to leave unanswered:

- what requirement did this code satisfy?

- what ancillary issues (bugs, related requirements) is this code associated with?

- how long did it take compared to the initial estimate?

- how often since the fix was marked as ‘complete’ did the code change?

I could (and just might) write another blog post on why these metrics are interesting and essential to software process management, but for now I leave it to commenters to elaborate.

To the specific points that the author makes, lets look at them in turn. The author’s orginal points and counterpoints are in italics.

  • Provides visibility of per person velocity - Visibility can occur during daily stand ups and weekly powerdowns.Sure it can, but that implies among other things that you are doing such standups. What if you are using an alternate process to coordinate the efforts of large, widely distributed teams? At some level, independent of your specific process, you need to be able to look into your SCM system and answer questions of who is doing what and why. Also, (and this touches on the second issue of accountability) not all developers communicate in the same way, so even if you are doing standups, as a manager you need objective facts to correlate with the verbal and written communications of your team.
  • Creates a sense of accountability - Why the hell do you have people on your team that you don’t trust?  Trust doesn’t happen all at once. The basic principle of managing people, whether they are shipping clerks or software engineers is ‘trust but verify’. Once a person has established a track record of reliable communications that are consistent with the objective (and hopefully, automated) metrics, you might reduce the frequency of how often you check them against the metrics. But periodic checking is essential - if a previously reliable engineer has for some reason fallen off the tracks, they may be reluctant to admit it, or they may not even be aware of it. A properly constructed metric that is trending in the wrong direction will give you clue that there is an issue to be addressed with this engineer.
  • Allows for possible learning opportunities - Either the bug is a bug (and no real lesson is to be learned), or senior developers did not properly guide less experienced devs through a design problem. All bugs teach you something. The latter case that the author mentions is certainly one lesson, but it implies that senior developers don’t write buggy code or are somehow immune to design problems (or design-to-implementation translation problems) of their own. This seems unlikely. Most of the best engineers that I’ve worked with will admit to some whopper bugs - many written well after they had earned the title of ’senior engineer’ or ‘chief cook and bottlewasher’, or whatever. What a bug tells you is that you have code that needs attention, independent of whether it dropped out of a build process or was discovered by the janitor. The overhead for recording a bug, commenting on it and connecting it to the source code change that resolves it is minimal in a well-designed and well-tooled development process, so for a small amount of effort you get the benefit of a window into your code, its failings, and your process. Seems like a low price to pay for such potentially valuable information.

I’ll admit that traceability and metrics are on my mind often (see for example, my prior post on the AccuRev-Rally integration and how it assists in agile requirements traceability). Maybe it’s because my favorite toys as a kid were ruler, compass and slide rule and I just like measuring things for the heck of it. Or maybe it’s because I’ve seen too many engineering projects fail - projects that if the manager (myself included) had a bit less hubris and a few more objective facts at their disposal, could have been squarely in the success column.

 

2 Comments | Agile, Best Practices | Tagged: , , , , , , | Permalink
Posted by Matthew D. Laudato

« Previous Entries