I was browsing reddit.com the other day and ran into this post:

Yup. It’s true. The tried and true development approach of Waterfall that we’ve been using for years was an example of what NOT to do for software development.

From the Wikipedia article: The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3] though Royce did not use the term “waterfall” in this article. Royce presented this model as an example of a flawed, non-working model (Royce 1970). This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice.

That’s what’s amazing about waterfall, and the agile transformations that seem to be taking the industry by storm. Maybe we all know deep down there is a better way to develop software.

I hope someday we don’t look back on Agile the same way we look back on Waterfall. I don’t think it will happen for the simple reason that Agile doesn’t have one methodology tied to it. Agile can mean a simple set of practices to help with software development, but it’s more like a mission statement as opposed to a plan.

I hope I don’t end up with a seized engine on the side of the road, but if I do, I’ll know I should have had that oil change. I hope I don’t end up on the Worst Dressed List, but if I do, at least I’ll know I should have given away those old shirts.  I feel sorry for those on the “Worst Agile Implementation” list who don’t even know they’re there.

In the past few months I’ve had the privilege of talking to approximately fifty organizations about their Agile implementation.  Most of them are doing well, and many of them have great insights about how they customized Agile to fit their process requirements.  But some of them really Say the Darndest Things.

“We do Scrum, it’s just the rest of the company doesn’t.”

“So first we break the requirements specification into pieces and call each of the pieces a story.  Then we do our iterations and pass them off to the release team.  We’d sure like to get Product Management, QA, and the customer involved, but they don’t want to.”

There are a lot of places an Agile approach can add value, and I’d hate to adopt a “waterfall approach to going Agile”, but you’re really not doing Scrum.  The biggest chunks of value, the incremental use of customer feedback, and going from “completed state” to “completed state” in each iteration are lost if you can’t get more support.

“We’re Agile until the development is done.”

More than once I’ve been speaking with an earnest development leader who’s describing the Scrum process.  They’ll launch in, with obvious pride, and tell me how they’ve gone to two week iterations, do standup meetings, and work from a backlog.  “Terrific!  And how do you do QA?”

Oh, yes, of course they do QA, silly!  In fact, they demo the completed development to the QA team every sprint review and send it off to get tested.  Sometimes, unfortunately, QA actually finds some bugs that need fixing.  So that’s why they put the sprint on hold for a while to fix the bugs and loop them back into QA “’cause we don’t want to wait an entire sprint before they can restart the testing.”

The other side of this one is the guys that take the old “Release Tail” loophole for all it’s worth.  “Yes, Lorne, we’ve been agile for three years now.  We do Scrum, unit testing, standups, and play in the World Series of ‘Planning Poker’.  We do that for about six weeks, or until the release.  Then we have a three month release testing tail, which follows a ‘modified Scrum process’ … the project leader estimates the amount of work on each bug QA finds, and assigns it to a developer.  Sure, sometimes we have to work on new functionality during the “release testing tail” … you can’t expect the customer to stop needing improvements for three months!”

Folks, I don’t think I’m sharing any great trade secret when I tell you the QA process needs to be completed before the story is considered “done.”  I don’t want to be Klaus Fuchs of Scrum, but here’s the secret: you’re going to have to invest more in testing up front.

“We do continuous integration every night.”

I blame the education system: how’s an engineer supposed to know what “Continuous” means when we have “social promotion!”  Now some people understand the idea of continuous integration, and made a conscious effort to make it more “Discrete”.  Some companies I talked to had broken builds that lasted for a week.  You’d rather have a child repeating “Mummy” every 30^th of a second before you’d like to get an email every five minutes saying the “Build Failed.”  I get it.  And if the email was going to your boss too, well, you don’t have to be Dogbert to know that’s a bad idea.

Builds are going to fail.  Get used to it.  The problem is not that the build failed, but that you couldn’t fix it.  Good practices are to have the team drop what they’re doing when the build fails and hop on fixing it.  If they can’t fix it, it needs to get escalated *pronto*.  Better is to have the team do local builds and unit testing before they check in.  Best Practices are to divide up the build process by team and stage of development, so your team only pollutes itself, not the rest of the development org.

“We don’t need training since we can use the internet.”

Uh huh. So I guess the schools will be shutting down any day now.  Not that the Internet might not turn out to be a useful aid someday, but the software development process is a hands-on activity.  And similar to other hands on activities, like dancing or carpentry, you can’t learn to do it by reading a book.  You’re going to need to get some experience with the process before you understand how to run a sprint review or a stand up, how to estimate stories, and how to work with your QA partner.

Now if you’re a hobbyist and working for free, your time is cheap, and there’s no reason not to use trial and error as a learning method.  But if you’re getting paid, and your work is important, you really don’t want to waste four sprints figuring out what someone can help you get right in sprint two.

I’m hoping my surgeon, pilot, and barber got a few lessons before it was my turn.

Finally…

No one has to pass a test to call themselves “Agile,” nor should they. Agilistas don’t have a monopoly on the right way to develop software.  But when people believe they’ve made it to Agile without using critical Agile concepts like time boxing development or getting to “done”, they’re missing the real value.

Are you frequently called on to perform the daunting task of ‘the merge’? Does tension mount and do groans grow louder when it’s time for a merge?  Are only a select few are willing to stand up and do the work?

Maybe these stages describe your merge process:

1. Denial: It’s never going to work (in a timely manner).
2. Anger: Why do I have to do the merge?
3. Bargaining: I’ll work on maintenance and support if I don’t have to do the merge.
4. Depression: How many compiler errors? Why won’t the jsp work with firefox?
5. Acceptance: Not really, it’s compiling and (mostly) passing tests.

Before we try to get you through the 5 stages of merge, let’s a take a look at divergence, the cause of a complicated merge.

Converging Divergence

There are lots of reasons for divergence, and as many for merge product lines back together.

Maybe you’re delivering functionality to specific customers, creating customization and personalization of websites, internationalizing your product, even moving from Windows to Linux platforms. So what happens? These areas diverge, developers refactor code, and the product lines look very, very different over time. Sure, you try to propagate changes across the product lines, but each implementation is slightly different. Eventually you realize this is a maintenance nightmare, and some shared areas should be brought back in line (if not the whole product line moving to a single source).

Now comes the hard part. A select few of your developers have to start piecing the code back together. Determining what changes are acceptable, reviewing the functionality, and hopefully getting the appropriate test coverage to verify that the desired changes have been brought back into a single (or at least cleaner) product line. Here’s where tools really shine (or falter).

Now, I consider myself pretty experienced in the merge department. I’ve worked on a number of merges of different sizes, dealt with multiple languages (English/Italian), and even migrated to different platforms (Moving from Windows to Macintosh).  Sometimes, I found, tools were a complete hindrance- I remember back in the day, using PVCS or CVS was every man for himself. You just got it working, never mind worrying about who made what code decision, and hopefully extensive tests identified the problems. More modern tools, AccuRev in particular, give you another dimension with merge that I find to be an essential.

The Merge Master

AccuRev version tracking, and the changes it tracks (content, name, removal) really help in hunting down the straightforward changes that can result in truly subtle changes in product behavior. Simply knowing that files have been removed in one product, and merging those changes over with a click of a button can eliminate behavior that is hard to determine, especially when the developer doing the merge had a reasonable belief that the files may exist.

Even better, large or midsize merges, can be easily reviewed, grouped into areas of the code and dealt with in a manageable manner. I performed a merge that merged internationalization changes into a product at AccuRev. There were over 7000 files that were altered, added or removed that needed to be managed.

Simply grouping the files by directory structure quickly identified which were doc, help, client, java, etc. Then these areas could be dealt with by developers in the specific areas. Further, because AccuRev performs simple merges quickly, I was able to perform the initial merges in these areas without having a strong need to understand them, and leave the complex changes to those who specialized in particular areas. This further reduced the amount of effort (and pain) that other team members experienced.

In this 7000+ file example, only about 400 files actually required more specialized investigation. And of the 400, only about 50 had truly complex changes where both sides of the merge made what looked like contrary decisions. Here is another place where AccuRev shines. By looking at the changes made at different points in each of the product lines, and working with change packages that described what the developers where trying to accomplish, I was able to make intelligent decisions about how the code should integrate, instead of just picking ‘he who changed it last’.

The two product lines in this case had diverged for about 9 months, and had about 10 developers making changes in each product line. Even with the amount of changes that occurred over this time period, it only took a single developer about 2 weeks time to bring the two product lines together. It took only a couple of days to complete the initial code process, walking through the changes and picking (via the AccuRev GUI) which of the changes to take, and editing inline where it was obvious.

During the first week, we were able to finish digging around developer changes via the AccuRev version browser in order to help resolve initial compilation failures. This work brought the product to the point where it was compiling on multiple platforms (which is usually even a problem with nightly builds). After another week of going through the validation and user tests, the merge was stable enough to be considered the baseline for the next release. Of course development had already occurred during the two weeks that the merge process took, but with the version tracking AccuRev performs with merges, it became almost trivial to bring in the new changes- within 1 day they were validated and ready to be the new baseline.

Sounds like acceptance to me.

There’s little question that most organizations are considering a move to Agile practices, but what’s holding back adoption?  Earlier this month, we released the results of research conducted over the past year as part of our “Agile Comes to You” seminar series. We surveyed approximately 1,000 developers, testers, product managers and other business professionals across the US and Europe, and findings shed new light new light on the obstacles software development organizations are facing as they move forward with Agile initiatives.

What obstacles hold back Agile Adoption?

The top obstacles identified by the survey included: capturing requirements (16%), lack of in-house experience (14%), and lack of automated tests (13%).  Other Agile pain points were challenges associated with teams spread across multiple projects (10%) and support for Agile with distributed teams (8%).  There are ALM tools available today designed specifically to help developers overcome these obstacles.  Development organizations can also implement a number of best practices processes to smooth the transition to Agile and accelerate adoption.  Following the survey results analysis, we’ll provide more details on the tools and approaches in a subsequent blog post.

The study also showed that pain points varied based on the extent of the organization’s Agile adoption: organizations in early and mature stages of Agile adoption both saw capturing requirements as a source of pain, while those organizations with some Agile processes implemented identified the lack of automated tests as their top issue.

In addition to spotlighting the obstacles to Agile adoption, AccuRev provided updated insights into interest in Agile.  Approximately 70% of those surveyed are currently implementing Agile practices – of this group, 23% are scaling, 37% are piloting, and 8% are already fully Agile enabled.

The full report of the Agile Adoption Pain Points Survey is available free for download at http://www.accurev.com/whitepaper/agile-pain-points-survey.

Here’s what others are saying about the survey:

Application Development Trends

Dr. Dobb’s Journal

We’ll have more insights to share based on what we’ve learned here, including next steps recommendations for organizations faced with these obstacles as well as the toolsets needed to implement and scale Agile.

Who? Damon Poole, AccuRev Founder and CTO, Agile expert and popular speaker.

What? Presenting “True Agility Requires Us to Re-examine Our Beliefs” for Nashua Scrum Club.

Where?  45 High Street, Nashua, NH 03060

When? Thursday, September 9, 2010

Why should you attend? Damon says “Too many projects that “go Agile” are actually far from true Agility. They end up reverting to old habits or just change the labels on the activities that they are doing without changing what they actually do on a day to day basis. As a result, many so-called “Agile” projects get few if any of the benefits of Agile and some are even worse off than before! Why does this happen?”

This session will give you an opportunity to uncover and re-examine your mental model of software development by taking a look at the top ten Agile blind spots. This will allow you to discover the blind spots you or your organization may have so that you can work towards removing them and start experiencing the full benefits that true Agility offers.

Visit Nashua Scrum Club to register!

 The ability to retain font size changes in Diff displays between sessions, and the ability to specify column widths within an Issues table.

 The ability to Diff the results of two queries, and the ability to compare the results of an Issue Diff against the results of a query.

 Better handling of redundant login attempts when the network is slow.

 The ability to print AccuWork charts, and the ability to export to xml or to print all tables.

 A new URL option to display the history of a specified transaction.

 An upgraded on-line Help system.

 The ability to Promote from the File Diff tab.

 The ability to Send to Issue (specifying basis) from the Version Browser context menu.

 The ability to perform Diff from multiple file selections in the Changes tab.

 The ability to Diff against other streams (not just the backing stream) from the Stream Hierarchy pane.

 Many Stream Browser enhancements.

 Smarter context menu behavior, and better default behavior for the the Query Editor “is in” and “is not in” conditions.

 The ability to optionally include the display of incomplete issues in the Show Active Issues view.

 Greater availability of toolbars and more toolbar options throughout the Web Interface.

AccuRev Web Interface 2010.3 is available on the main AccuRev download page: http://www.accurev.com/download.htm.

Here is one more AccuRev vs. ClearCase video to share.  And this one is a crowd favorite.

AccuRev vs. ClearCase in ClearCase Multisite Unsynced

Sure, we all know geographically distributed development teams face lots of challenges.  But ClearCase doesn’t provide a simple solution to this problem.  In fact, with ClearCase Multisite Unsynced, teams have trouble syncing up and don’t allow developers to work the the same branches at the same time.

With AccuReplica from AccuRev, all remote teams can work together and on the same code, like one co-located development organization.

Due to positive feedback from our first blog promoting AccuRev vs. ClearCase parody videos (see the post Issues with ClearCase?), and seeing as ClearCase has not addressed the needs of modern software developers in years, it seems only fitting to share a few more.

Rationally Wrapped

While ClearCase users deal with complicated wrappers and scripts during upgrades, AccuRev is easy to use right out of the box, and doesn’t need any wrappers or scripts.

Developers Revolt

Locked out of ClearCase again?

AccuRev will never lock developers out.

Do these issues resonate with you and your development team?  Read more about how AccuRev auto-synchronizes with ClearCase, providing developers the ability to get up and running with AccuRev at no risk!

User Story Based Engineering

In other blog posts I’ve talked about using Multi-stage Continuous Integration to scale Continuous Integration for use in multi-team environments and using streams or branches to model your workflow directly in your SCM tool. While both of these approaches work well and provide a lot of value, they can also present a new challenge: how to associate enhancement requests and defects, which can be lumped together using the term “work items,” with the changes that implement them?

If you are doing mainline development, life is pretty simple. On check-in enter the enhancement request ID or defect ID in the comments. Once that association is made, it is fairly straightforward to figure out which enhancements and defects have been checked in. On the other hand, the more people you have checking in to the same branch, the less likely it is to be stable, even if you are doing Continuous Integration. So, how can we maximize the benefits of using streams to represent process and integration stages and still have the ability to match work items to the work done to implement them?

Representing Process and Integration Stages with Change Packages

(Let me first point out that while I’m using the generic term “work item” here, in an Agile team one would most likely use the term “User Story.” Both apply equally well in this context, but I’ll stick with work item for now.)

There is an SCM concept that maps to a work item which can be tracked from place to place, and that is a “change package.” It is called a change package because it represents something which, once defined, can be applied to multiple places and tracked regardless of how many different places it has been propagated.

Change packages can be promoted individually or in groups from stream to stream. That way, as work is promoted from stream to stream you have a record of the content of each stream from a high level perspective instead of a files perspective. A list of files is not very meaningful or useful. On the other hand, change packages allow you to ask questions like “which user stories are in the stream that represents all user stories that are ‘done’,” without having to resort to mainline development.

One of the questions I hear a lot from Agile teams is “how can we have a stable build to test stories as they are completed?” Often, the only time the build is stable is towards the end of the iteration. That then squeezes the QA folks or sometimes even has them testing the previous iteration’s stories in the current iteration. Hmm. That sounds a bit like our old friend Waterfall.

Usually, when the question is asked, the team is creating and automating unit tests and doing continuous integration. That’s not the issue. (If you are not doing those things, stop everything and implement these three practices immediately!) But let’s assume for the moment that you are doing these three practices.

The problem is getting a build which consists of only stories that are considered “complete,” but still need a bit more work done on them, such as exploratory testing, load testing, usability testing, demo for customer feedback, etc. You might say, “but you can’t do that until the end of the iteration.” Ok, but then you are back to the problem of a compressed QA cycle and having development either sit on their hands or move on to the next iteration, neither of which represent Agile thinking.

There’s a simple solution to this problem, which you may have “thrown out with the bath water.” Branches! Or, in AccuRev parlance, streams (though I’ll stick with branches for simplicity). Each process stage gets its own branch. That doesn’t mean that you can’t write code and tests at the same time, only that code can’t advance to the next branch until it meets the criteria of that branch, such as “coding is done” and “all tests are written and passing.” I know, you cringe at the thought of branching and merging, but that’s probably because you are thinking of branches that contain long-lived changes. We’re not going to do that here.

The idea presented here is to advance changes through the set of branches as quickly as is practical. As changes get propagated to each branch, CI is done against that branch.  If it succeeds, it gets promoted to the next branch. If it does not succeed, then that developer (possibly with help from her teammates) fixes the branch. This is similar to how stopping the line works in a modern lean manufacturing facility.

In AccuRev, this process is greatly simplified. You can create a set of streams instead of branches, and streams can model your exact process. Promoting work from stream to stream is a simple drag and drop operation.

In the diagram above, there are streams for each of the stages from “wip” to “done.” Since each stage is a stream, you can run continuous integration at each stage. You can also do builds, for instance from the “tested” and “done” streams to do things like exploratory testing. By definition, a build from the “done” stream only contains changes which are built; integrated together; have unit and other tests written, automated and passing; and whatever other criteria you have for “done.”