In the last post I defined two Agile software development best practices I believe provide value to a wide variety of development teams.   Here I define three more practices that I believe are also important when transitioning to Agile Software Development; collocation, unit testing, and refactoring.

Best Practice for Agile Software Development: Collocation

Collocation is simply having everybody on a cross functional team in close proximity to each other. This compounds the coordination benefit of cross functional teams. This is orthogonal to outsourcing. Whether you are outsourcing or not, collocation only refers to whether a particular cross functional team is sitting near each other.

Best Practice for Agile Software Development: Unit Testing

Unit tests are simply tests that exercise small amounts of isolated functionality. That is, if you have a function that adds two numbers, instead of depending on running a user function that eventually calls the function, exercise the function directly. This often requires the use of mock objects that pretend to be things that the function needs in order to test the function in isolation from other functions that it depends on.

The cost of unit tests is in writing the tests themselves and refactoring code as new functionality is introduced to keep the unit tests testing at the right level. The benefit is that you can easily test changes quickly to find simple problems before doing more thorough and slower testing. It also provides a good safety net for refactoring, gets developers more involved in testing, and usually improves the design of the software.

Best Practice for Agile Software Development: Refactoring

Refactoring is the practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. That makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code. Any change has the potential to reduce the maturity and stability of the product, especially if you don’t have adequate testing in place. That’s why refactoring is usually paired up with unit testing and together these are frequently combined with continuous integration.

It seems like everyone loves continuous integration.  I’ll come out and say it- I love continuous integration! When we talk about the most widely adopted Agile practices, this one comes up the most.  Its positive benefits as a feedback mechanism provide a quantum leap forward in how development organizations think about their code.  I find it very difficult to see any downside in doing continuous integration, seriously what’s not to love?

Modern day continuous integration servers have 3 functions: Detect if a new build is needed, execute build, and notify people of the results. This is a great way of facilitating feedback to developers and allowing them to adapt and resolve problems.

But there’s something lurking in the shadows that nobody is talking about, maybe because people aren’t even aware that it’s a problem. Maybe it’s because we don’t want to ruin our love affair with CI and we’re all in denial.

What happens when those builds are done? What about the rest of “it”?

When I say “it” what I really mean is:

Most development environments include such things as complex application servers, automatic testing, release processes, compliance, audits, databases, 3^rd party libraries, build dependencies, code analysis, unit tests… and another 1,000 other things I don’t have enough space to list here. How can you deal with this? Getting feedback to my dev team is a great targeted way to let people know code is broken, but isn’t this feedback useless if you can’t get the product out the door?

If I take an example build lifecycle of an application which is:

1.)    Build Application

2.)    Test

3.)    Deploy to environments (DB) (APP SERVER) <- by hand

4.)    Test

5.)    Redeploy (DB) (APP SERVER) (PROD) <-by hand

This may seem like easy in this example, but if we took all of these steps in the real world, this could represent hundreds of servers.  And this process will have to be repeated for every version of the product.

The crux of this issue is that if any of these steps are not performed 100% correctly, it translates to real dollar$ lost for the organization. These operations have to perform like clockwork.

Taking Continuous Integration to the Next Level

This is why I believe bringing continuous integration to the next level starts with the concept that the build produced from the CI server is just the beginning. Setting up a simple CI server and producing a build is easy, but managing it through the rest of its life is the real trick.

In a real example of this, we could take

1.)    Build

2.)    Run automated tests

• If test succeeds: Deploy to to environments (DB) (APP SERVER)

• If test fails: Notify dev team

3.)    Manual Testing in QA environment

4.)    Approval process

5.)    Redeploy (DB) (APP SERVER) (PROD)

Using AgileCycle RM

In this scenario I’m taking a version of the results from a CI build, run automated tests on them, monitor the test output and wait for success or failure. If there is success then deploy all components of the application, this includes a database components and a java war component. The build will then sit in QA for manual testing until its marked approved by the QA team, managers and operations team for deployment to production.

The idea here is if we automate these processes and decisions based on build, automated tests and approval process, you can produce code quickly and at a more rapid pace. If you can produce a clockwork-like automation around your build/test/deploy related processes, your team can spend time on what’s most important: Getting code out the door.

Due to the promise of large gains in quality, productivity, and market responsiveness, Agile software development has been making its way into the enterprise in recent years, but there have been plenty of bumps along the way.  Any change to the enterprise has hurdles to overcome, and successfully adopting Agile development requires change within the organization than we have seen in the development process over the past several decades.  For instance, as you transitioned from C++ to Java or .Net, did you find it necessary to make substantial changes to your org chart?  Most changes in the software development process have been either the result of technology changes, such as moving from C++ to Java or pure html to AJAX, or changes in architectural patterns such as the introduction of object-oriented programming and moving from client/server to SOA.

Enterprise Agile Development May Be the Answer

Sustainable and repeatable success with Agile requires the same sort of framework put in place with your traditional development projects across the enterprise.  The end-to-end traceability, progress and status roll-up, portfolio management, and inter-project coordination that you have with your traditional development projects will be just as critical on your Agile projects.  After all, Agile is not the goal, it is only the path to higher quality, greater and more rapidly delivered ROI, and increased customer satisfaction.
Not only will you need a framework that encompasses all of your Agile projects, you will also need a framework which can encompass all of your projects, regardless of methodology. Doing this is likely to require re-tooling, training, and integrating multiple tools across projects.

Agile in the Enterprise Requires Top to Bottom Involvement

Adopting Agile without understanding the principles and without creating a proper ecosystem for its survival, Agile may be destined to fail. I’ve visited far too many companies whose first attempt at adopting Agile failed because the extent of their investment was a single visit from an Agile coach. In these circumstances, few people are usually on board initially, and many skeptics exist because of an insufficient effort invested in preparing for success.
Adopting Agile development requires breaking down mental barriers and building up new skill sets. There is nothing particularly hard about actually implementing any of the specific Agile practices, but many of them are counterintuitive and do take a bit of practice to get used to. Don’t underestimate the amount of effort required; it is at least on the same order of magnitude as taking a team very used to writing in C++ and moving to Java. There’s nothing particularly difficult about such a transition, but there are many subtleties which must be learned and it takes some time to build up the same base of experience.
Committing to the effort required and funding the necessary training, coaching, and retooling requires involvement from the top of the engineering organization all the way to the folks in the trenches.

Your Enterprise is Optimized for Traditional Development

Actually doing Agile development is relatively straightforward, much as going 60 miles an hour is easy to do driving on an uncongested highway. As the original challenge of fast travel was a lack of cars, highways, and driver education, the main challenge with going Agile is creating the proper environment for Agile to take root and expand.

Over the years, your enterprise has done everything it can to provide the proper environment for traditional development to thrive. But what is considered fertile ground for one crop can be a difficult environment for another crop. Consider how all of the following have been tweaked over the years to optimize for traditional development. I’m sure you can think of more.

• Where people are physically located

• The reporting structure (silos)

• Your software development tools

• Homegrown tooling and scripting

• Metrics and reports

• The budgeting process

• Skill sets, training, work habits

• Process documentation

• Fixed bid contracts

Each of these are like the rumble strips on the highway, reinforcing the form and function of traditional development. The form and function of Agile development is very different. Instead of helping, the infrastructure that is currently in place to reinforce and optimize traditional development very often discourages effective Agile adoption.  Consider the simple example of budgeting.  If budgeting is currently based on the cost of features promised for the fiscal year and governance that rewards the delivery of those exact features and punishes variances, that will not only reduce the chances of a successful Agile adoption, it will also significantly reduce the potential benefits of Agile.

Agile in the Enterprise Requires a Hybrid Approach

A full top-to-bottom transformation to Agile development will likely result in significant changes to the organizational reporting structure, physically moving people from one location to another or even rearranging their workspaces (whether it is down the hall or across continents), and changing the interaction between people at all levels, from customers and product management all the way to developers and the folks in operations. For most enterprises, a change of this magnitude can’t (or won’t) happen overnight. For most people, a hybrid environment will be part of their experience for many years. And of course, there may be some projects that you have no intention of moving to Agile.

Partnering With AccuRev to Bring Agile into Your Enterprise

The process of each of our customers is different, ranging from small collocated shops to large distributed organizations with locations across the globe, from Agile eXtreme programming to CMMI level 5 waterfall. We understand a wide range of methodologies and how they interface.

At AccuRev, our core expertise is process improvement. Adopting Agile in the Enterprise is all about process improvement. That’s why we’re excited about our new offering, AgileCycle, which has everything you need to go from where you are to where you want to be. With AgileCycle, you don’t need to worry about doing a big-bang transformation. We’ve got the expertise, coaches, trainers, consultants, and of course the tools that will allow you to transition to Agile at your own pace while smoothly integrating Agile, iterative, and Waterfall methodologies and your existing tools across your enterprise.

Brad Appleton’s series of posts on What Is Agility? bring up the right questions, but they don’t dive into the muck, like a BBQ eater in a white suit.  Muck diving is right up my alley, as the stuff I find interesting is usually at the bottom of the pile.

There are several fundamental problems to be solved, but the most interesting, by which I mean really hard, problem is understanding what is the most important thing to do next.

In The Agility Cycle, Brad quotes a host of luminaries, including himself, in defining what that thing is.   I like Gartner’s the best, and here I’ll have to quote Brad, as Gartner won’t let me read their original:

1. Sense the need for change in the environment (includes the proactive initiation of change)
2. Strategize the available options and develop alternatives
3. Decide which path to take and commit to the approach
4. Communicate internally and externally to everyone who needs to know
5. Act to produce results and follow-through efficiently

1. Sensing the Need for Change in the Environment

Let’s start with “Sense the need for change in the environment”.  Beware of management aphorisms that sound like something you’d hear at a Yoga workshop!

Not only is it hard to tell what the need for change is, it’s as hard to agree on it as it is to get two people to agree to toppings on a pizza.  By the time your company has it’s second employee, you’re in trouble.  When you get your second customer, it’s pretty much over.

Practically speaking, there are four avenues in which we business people “Sense the need for change in the environment”:

1. Strategic Pressure.  “The future is in Cloud Computing on the i-Phone.  Get me there in six months.”  Most engineering organizations are willing to set fire to the old application and do a little resume polishing on the new one.  Nothing like starting from scratch, unless you actually want to make money.

2. Competitive Pressure.  “Your App needs to do foobar, just like that other app does.”  Now that’s going to happen every day after you ship version 0.9.  It’s unlikely that any one request requires real change, but maybe that sound you hear is an out of control semi, and it might be nice to change direction before slamming into the grill of the truck.

3. Customer Pressure.  “I’m not loading any more of your crappy releases until the .2 version, at least.”  Hey, you Windows XP users, you know who you are.  And who I am.

4. Financial Pressure.  Sales drop.  New Account sales drop.  The CFO takes away our CapEx budget.  We have to reduce headcount [or "Free people to pursue other opportunities" as they say in Hollywood], reduce hours, reduce pay.  Doesn’t take a highly developed set of Senses to know things have changed.  But what do we do about it?

It’s relatively easy to deal with Strategic Pressure: unless the pressure is coming from your CEO’s who’s an ex-Marine Karate instructor with a Meth habit: slow down amigo, and study it. Engineering is a discipline where things take time.  The worst thing we can do is change priorities faster than we can get them to market.  Change needs to require a good case.

Market of any size don’t have windows that  close in six months.  More likely people will learn that Prolog wasn’t really all that valuable, or you could like without a MS-Bob plug-in.  SOAs and the ASP business model have been around for ten years.  Before you imagine yourself as the next “i-Fart” author, ask yourself, what percentage of the apps on the i-Phone have made over $100K in revenue?

Competitive Pressure and Customer Pressure are not the same.  Competitive pressure shows up when your organization is losing business to a competitor.  Real Customer Pressure is when you can’t live up to your value proposition without making changes.  These two are the realm of Product Management.

The difference between a great product manager and all the rest is whether they can determine which customer or sales requests require change, versus the ones that go to triage and get prioritized with all the others.  Signals that you might have to really change what you’re doing are when you get demands for 10x performance improvements, or to support workflows that just don’t fit.  Patches (“now 30% faster!”) just aren’t going to make those requirements go away.  Now you’re going to have to think about how to address a new market environment.

Finally, Financial Pressure is the easiest to sense, and the least likely to activate change.  Financial Pressure tends to make organizations to freeze up.  Whether the reason was lack of product competitiveness, global recession, or a controller with a cocaine problem, the result is the same competitive and customer pressure, fewer resources to deal with it, and (unless you’ve been investing in those employee meditation session) lower morale.

Two mistakes managers typically make: trying to use the same development process, and freezing CapEx.

Improving the development process is your way out of this mess, not something you can’t afford to do.  That’s like the teenager who knows he’s going the wrong way, so he drives faster.  And, if you have the cash (or if the government is giving it out like candy on Halloween), Capital Expenditure is the cheapest way to get onto a better process.

Lorne Cooper

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

Yesterday I was a panelist for a Webinar on agile tools, focusing on software configuration management (SCM), build and software process automation (SPA), the latter term referring to the set of defined, repeatable and measurable automated development workflows that engineers use to transform requirements into shippable software products. Contrary to what I’ve read about the disdain that some agile devotees have for tools, most of the attendees were hungry to know what features their SCM tool should have in order to support agile software development and SPA. Here are some of the highlights, and of course, my take on why I think AccuRev is the best tool for agile software process automation.

There are five key feature areas that an SCM tool needs to support in order to be ready for agile:

* Support for flexible process models

* Continuous integration support

* Support for issue-based development

* Efficient branch and code management

* Private version controlled developer workspaces

Let’s take a look at each of these in turn.

* Support for flexible process models. Agile is often one of several processes being employed within a software development organization. Unless your SCM tool is flexible and process-neutral, you will have a hard time implementing agile (say, for product development) and more traditional processes like waterfall (for example, for product maintenance work) in the same SCM tool. AccuRev streams are a natural way to model any process, and thus are a good fit when agile needs to coexist with other development processes. As for software process automation (SPA), AccuRev streams again are a great fit, since they enable users to model any arbitrary stages of code transformation that a development team sees fit to define as part of their process. By adding triggers and workflow to a stream hierarchy, teams can implement SPA directly in AccuRrev.

* Continuous integration support. Continuous integration is one of the core process elements associated with agile development. By building and testing frequently and acting on the results of tests, teams can uncover defects or test gaps earlier in their development cycle, saving time and money compared to such discoveries late in the cycle. But continuous integration goes beyond just testing the nightly build. With multi-stage continuous integration in AccuRev, code is automatically promoted up the stream hierarchy into more stable configurations as it passes tests. At each stage, continuous integration takes over to build and test, typically with a wider scope of testing as the code nears the release stage. Legacy SCM tools make this type of automated integration factory somewhere between difficult and impossible due to the complexity involved in setting up the hierarchy and in automatically moving and merging code as it flows up the hierarchy.

* Support for issue-based development. Apparently there is a lot of contention about the need for filing issues and defects in agile development. This has puzzled me greatly. While I’m in favor of developers identifying and fixing issues as they are discovered, you lose valuable process information when a defect or enhancement ticket is not filed and later associated with a code change. Without an issue that describes what the problem was, someone looking at the code changes for audit purposes or for group code reviews is at a disadvantage. Why was this code change made? Is it related to other changes? How long did it take? Was it done to fix a bug or to add a feature. In AccuRev, issues either in the integrated AccuWork issue tracking system, or in a 3rd party issue tracking system, can easily be associated with code changes via the AccuRev Change Package mechanism. This establishes basic traceability between issues and the code changes that developers make in order to satsify the requirements of those issues. Issue-based development is well-defined, repeatable and measurable – all hallmarks of good software process automation.

* Efficient branch and code management. Any time you’re working on more than one project, you need to isolate that project’s code from other projects. With agile and multistage continuous integration, even a single project requires multiple code lines in order to separate in-progress code from unit tested code from system tested code that is ready for release. If an SCM tool makes branching, merging and labeling difficult, teams tend to practice branch avoidance, which I sometimes like to call “fear of branching.” This is a classic example of letting a tool dictate what processes you can implement. In AccuRev, streams replace branches as the mechanism for isolating codelines. Since streams are represented inside of AccuRev as data separate from the actual file versions, creating streams is fast – really fast, like, a second or two – and managing a system with hundreds of streams spanning multiple projects and processes is easy.  For continuous integration, AccuRev snapshots and time-based streams are also fast and easy to create and manage, and give users a straight-forward way to “label” an interim or milestone codeline without having to place markers in thousands of source files.

* Private version controlled developer workspaces. Software developers are the heartbeat of any engineering organization. Executives at any development shop will tell you that hiring talented engineers and keeping them well-tooled and productive is the single largest challenge that they face. For agile, this is even more of a challenge, since coding cycles tend to be shorter, and thus anything that gets in the way of individual or team productivity tends to have a greater negative impact on the project. Private version controlled workspaces like the AccuRev workspace model improve productivity, since they enable developers to work in isolation (while they are ‘heads down’ coding). Private workspaces in AccuRev also give developers full SCM capabilites in their workspaces without the need to share in-progress code prematurely. By using the ‘keep’ operation, developers make safe copies of their work in the AccuRev repository, and later can ‘promote’ the code to an integration stream to combine their work with that of their teammates. Individuals are more productive in this way, and if continuous integration builds are frequently testing the integration stream, so are teams.

In a nutshell, agile requires tools, and these tools need to support different modes of operation than with other processes. SCM can help or hurt you in setting up and executing an agile process, so these guidelines are a way to help you get your SCM tool ready for agile - easy of course if your tool is already AccuRev!

If you’re interested, you can view the webinar recording.

Is Your Software Development Environment Agile-Ready?
Free On-Demand Webinar

For those tracking the movement of luminaries such as Martin Fowler and Kent Beck or looking for scalability advice from the architects at companies like Orbitz, Ebay, and Linked-In… QCon ’07 in downtown San Francisco is the place to be!

The conference is packed with senior architects, software engineers, and open-source contributors galore — over 400 were rumored to be in attendance. With speaker topics ranging from enterprise scalability to Agile practices, the audience was nothing short of being at the top of their game. Huddled together at the entrance to the conference rooms were a number of vendors showing off new warez including AccuRev. Here’s a shot of Damon Poole & Cliff Utstein (top-right), Dave Thomas (left), and John Wall (bottom-right). The AccuRev booth had a constant flow of folks amazed at how the stream-based architecture brings a refreshing approach to managing software configurations and supporting agile practices. We also had some cameo appearances from existing customers like Authorize.Net and Orbitz.com.

Agile development methodologies is a major theme of the conference. For someone looking for advice on agile, just standing in the middle of the exhibit hall is all it takes — everyone is talking about best practices, success stories, and failed attempts.

We had a constant stream of people intrigued by our stream-based architecture and inherent support for agile practices. Here’s a list of common discussion points:

private workspaces: commit-early, commit-often

stream inheritance: merge-early, merge-often and sharing iterations early and automatically with parallel development efforts

issue tracking integration: assign, deliver and track development activity to stories/issues/features

continuous integration: integrations with cruise control, finalbuilder, electric-cloud, and others

refactoring: IDE integrations with eclipse, Intelli-J, Visual Studio support application-wide refactoring with version control

staged workflows: organize distributed teams and isolate integration areas from testing areas for explicit and repeatable access to known configurations.

snapshots: guaranteed reproducibility of labeled configurations for builds known to be ‘good’

reparenting: retarget active development to known good configurations for testing or stable development

If you didn’t have a chance to attend this years QCon, be sure to put next years event on your calendar!

/happy conferencing/ – dave