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.

‘Tis the season to make unsupportable predictions for the future.  Despite my prior record (and I remain surprised that we don’t yet have personal jet packs) I’d still like to share a long-range weather forecast for the software industry.

You’ve been warned.  From here on, you’re on your own.

Prediction 1: Everyone Will Claim They Are Agile

And 50% of them will be wrong, just based on the Nokia test.  And of the rest, half won’t get any value from it.

There are a lot, and here I really need to underline a lot, of bad development practices out there.  For every organization that is killing it with Agile, there are five (my agilesta friends say ten) organizations that are limping along, delivering buggy code to their customers, late, and missing committed functionality.  And often all three.

This “Going Agile Without Knowing How” problem is probably an inevitable result of the success the early-adopter teams had with Agile methods.  For instance, when I watch The Olympics, figure skaters make skating look effortless.  When I do it, I look like a drunken hippo and hurt my butt.  It’s hard to stop and remember that these athletes, in addition to good genetics, spent years at the rink with their coaches learning, trying, failing, and improving, before they got in front of the TV cameras.

Agile has crossed the chasm, and the great majority of organizations have too few people, with too little coaching, and hardly any tooling.  Sure, your boss doesn’t realize how useless your stand-up meetings are, or that your code isn’t fully tested at the end of a sprint, but she’ll eventually see that your customers are not happy.

Prediction 2: Development for Mobile Devices Will Still be Small

Yes, Mobile is really big, and moving fast.  It’s just that the great majority of the work to support useful mobile apps remains in the back office.  When we’re finished inventing new ways to swipe our coffee-stained fingers across our screens, the value of the great majority of our apps is back in the glass house, running Java and C++ on big ‘ole honking (virtualized) servers.

The development problem in the era of proliferating small platforms, remains the problem of dealing with large, complex, data and it’s interactions.

Sleep well, Larry Ellison.

Prediction 3: The Gap Between Pros And Amateurs Will Grow

Every new software technology “spike” rewards the early adopters with higher productivity, which can level the playing field for the “newbie” or occasional software developer.  But as application complexity grows, as the platforms become more complex and development environments become richer, the professional advantage becomes more significant.

There isn’t much of a disadvantage in time-to-market for the young developer, maybe working on his laptop with open source tools and no identifiable process. The difference between them and a team of experienced professionals, working with industrial strength tools and procedures, and building apps that run businesses on virtualized hardware in a web connected world, is in “value created.”

Created Value is a concept that we’ve all been learning during the past ten years of Agile evangelism.  Created Value is measured at the customer side, and primarily by the classic metrics of software: how does the software help me get my job done better and faster?

There was a time when the lowest cost labour source for a software project was the key criteria.  Over the past two years, software projects have been revisiting their decisions as they’ve seen the crippling effects of buggy, unmaintainable, badly architected products.  We’ve seen the evidence with a hiring boom in the US for developers and QA alike.

In short, in 2012, we’ll see a renewed focus on quality of development, over quantity.  And a better appreciation for the talent, tools, and techniques, that create it.

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.

A funny thing has happened over the last couple of years…. we started calling waterfall software development… er… “waterfall”. By this I mean, we never had a name for the process… waterfall was just called “software development”. There was no distinction or name for what we were doing- there was only one way. This is a draw of agile, it’s something different.. and it’s the only new development methodology to actually get attention in the last 10 years.

So, what’s the deal?

#1) Agile is an umbrella term for several methodologies.
Agile encompasses a lot of different things; it can mean different things to different people. This might be why people have such a hard time understanding it. So comparing “waterfall” to Agile isn’t entirely accurate, or possible, since it’s like comparing one NBA team to all of MLB. Agile encompasses several methodologies (such as XP, Scrum, Kanban), which are all iterative in nature… that brings us to…

#2) Agile is iterative.
Yes, agile is an umbrella term, but all of the methods in agile share common core values: The fundamentals are to incorporate iterative development and to have continuous feedback so that you can always improve. This means you continuously plan, continuously test, and continuously integrate so you can adapt when needed.

#3) Agile is adaptive, not predictive.
Do you remember what “waterfall” was like back in the day? We spent months gathering business requirements, writing specs, and designing, and then spent the next 10 months coding. Since we spent the first few months trying to predict what the next 10 months would entail, we could never accurately estimate how much work a task was supposed to be, and heaven forbid the requirement changed half way through! Agile is an attempt to shorten that cycle so we don’t have to waste 10 months before find out something was wrong.

#4) You can pick and choose what methods you want to implement.
It’s funny. I ask people all the time, “How agile are you?” They typically say “Well, we’re somewhat agile, but not fully agile.” People tend to measure some sort of agile “zen” in their head, and that doesn’t exist! If you’re practicing some agile methodologies, you’ve won half the battle.
You’ve won half the battle if you are practicing:
·         Continuous Integration
·         Agile Workflows
·         Test Driven Development
·         Short Iterations
·         User Stories
There’s no out of the box way to do this, but if these methods work for you… then you’re there.

#5) The genius Of Agile is in the name.
Since the word “Agile” can’t be traced back to a specific methodology like “waterfall” we probably won’t ever think of it as “development”. In addition since it’s not a prescribed method of doing things (ex: Watefall.. requirements->design->implementation->verification->maintenance) it just can’t fail… whatever methods we use can always be improved and adapted to best suit our needs.

Me speaking at Agileee 2011!

I wanted to take a minute to thank Agileee for having me this year. It really was a great conference- great speakers, great crowd, great city. I learned a lot and met some interesting folks, and must say that Kiev, you changed my opinion of vodka .

For any of you who missed it or would like a reminder, the video of my presentation, “Scrum and Kanban, Like Chocolate and Peanut Butter” is available here, as are the slides.

If you get the opportunity to attend the next Agileee, I highly recommend it! Thanks again for having me, Agileee.

AccuRev is going to Agile 2011! Stop by the AccuRev booth to say hello, enter to win our great give-away, or see the new AccuRev version 5.2 demoed.

Session hopping? Make sure you attend Damon Poole’s session, Scrum and Kanban, Like Chocolate and Peanut Butter on Wednesday, August 10th, at 3:30 PM in Imperial Ballroom A. You may wonder how Kanban can help with your real-world process problems. Damon will discuss Kanban from a Scrum perspective, show how the Lean practice of “One Piece Flow” is the key to both, and look at how to mix and match Scrum and Kanban to fine tune a process that fits your circumstances.  

OK, you’ve decided to transition to Agile development. You’ve done the training, retained an Agile coach, even switched to a new SCM system and acquired your first Agile project management tools. Now what?

Are you worried that you’ve retained some non-Agile baggage and may not be using your Agile tools to their best advantage? No need to worry – here are ten tried-and-true best practices for Agile tool users:

1. Evaluate the Agility of your tool stack

It only makes sense that to use Best Practices for Agile tools, you have to have Agile tools. A good first step is to see if your tool stack fits in with the Agile process. What is an Agile tool ? Simple – it’s any tool that can support one or more Agile practices and fits into the basic Agile framework. That’s it! For instance, a tool which allows you to maintain a ranking of all of the issues that you care about is one that supports the Agile practice of maintaining a backlog. Agile tools need a high ratio of value to effort in order to fit into the short iterations of an Agile project.

For each of the tools in your stack consider the following questions:

• How long ago did we implement this tool?
• Do we have the most recent version of this tool?
• Does the vendor of this tool use Agile development to produce this tool?
• What are the specific Agile practices that this tool supports?
• What are the specific features supporting those Agile practices?
• Are there other tools are better suited to those Agile practices?
• Are there Agile tools which remove or reduce the need for this tool?

2. Measure value-produced instead of progress-against plan

Rethink how you measure progress with your projects. Toss the idea that progress is measured in milestones right out the window and instead think about value produced. Instead of having unfinished work at the end of an iteration, it’s much better to complete work on a regular basis, get some value going, and have a couple of items which are not done at the end of the iteration that get deferred to the next one.

3. Maintain a master list of all work items

All work needs to be represented in the backlog for it to be really useful. Ideally, all work performed should be in the form of user stories and defects and managed through the backlog so all user stories and defects are available in your Agile Project Management system. The benefit is that nothing falls through the cracks and all work can be managed, tracked, and measured with the same process.

4. Use change packages to link user stories and defects to source file changes

A change package is what you call a complete patch of all changes required to implement a particular change. It’s a rollup of all of the changes that have been applied to resolve an issue including a complete audit trail of who made the changes, when they made the changes, and why they made the changes. Each change package is tied to an issue in the Issue Tracking System (ITS).

5. Fail fast: break up monolithic builds and test suites

I think the best way to be successful is to be able to fail fast. In other words, build the pieces of the software which have changed first, and run the tests which are most likely to detect systemic failures first. This way, with multiple teams working on their own builds, you can get rid of the clunkers quickly and concentrate on those ideas that show the most promise.

6. Use branches to smooth out end-of-iteration activities

Branching enables you to start the next iteration without disturbing the previous one. If QA finds any problems, development can fix them on the previous iteration branch. At some point that branch will be declared “done.” Those changes are then merged into the current iteration. The advantage here is that development did not have to stop, and you still have a stable baseline.

7. Use multiple tracks of development to work toward short iterations

One way to make an easier transition to Agile tools is to dump development tasks into one of two buckets: those that easily break down into small user stories, and those that don’t. The main track is work that can be completed within the iteration, including all testing. The secondary track is for all other tasks. Once a secondary task has been completed, it gets merged into the primary track at the start of the next iteration.

8. Use permissive file access policies to support collective code ownership

There should be as few barriers as possible to making file changes when using Agile tools, so use optimistic file locking – or no file locking at all – and set all file permissions to writeable to support collective code ownership.

9. Base iteration reviews on SCM baselines

Make sure that work shown during an iteration review has been integrated into the mainline and passes all unit tests and other end-of-iteration criteria according to the principles of Continuous Integration by requiring the team to prove its demo work is a single set of binaries built from the same baseline. That baseline must be from the mainline and built on an official build machine.

10. Mirror your Agile workflow with branches or streams

Mirror your Agile workflow with branches or streams so you can get many of the same benefits that tracking state gives you in your SCM change management system.

So there you have it — these ten Best Practices will increase your chances of becoming an Agile rockstar and increase the quality of software you create with your Agile software process.

There are a handful of SCM best practices that can optimize continuous integration.  This post will look at:

• Establishing a staging and isolation hierarchy
• Automating builds at all stages in the hierarchy

Establishing a staging and isolation hierarchy for optimizing Continuous Integration

Proponents of continuous integration commonly suggest branching as little as possible and having developers work directly from the mainline as much as possible. However, this approach has several difficulties:

• It puts the stability of the mainline at risk
• It presupposes that traditional legacy branches are the only available isolation mechanism
• It decreases the flexibility and agility required for fast iterative development

With modern SCM systems, a better approach is to implement a staging and isolation hierarchy for the development process. A staging and isolation hierarchy uses objects in the SCM system to represent the dependencies between development groups and process steps. For example, you may wish to model the following teams and activities:

• Release engineering
• Quality assurance
• Product engineering
• Component engineering

Each team or activity is assigned the equivalent of a private workspace (variously called “streams” or “branches” depending on the SCM system). Each team then receives the same benefits of private workspaces that individual developers receive.  With a staging hierarchy, changes move from less stable configurations to more stable as they are tested and deemed “good” for the next level. This allows the code to be stabilized as it gets ready for release without developer downtime. It also allows additional separation for each team if needed, so that the team’s changes can be integrated and tested before the components are integrated together.

In this figure, there are four development teams as well as an area for accepting third-party code drops.  The teams are located in different geographical areas. The hierarchy represents the normal flow of changes through development from stage to stage. In the example of the above figure, changes provided by the GUI product engineering team in India flow from individual developer workspaces (not shown for brevity) to the GUI stage, where they can be continuously integrated and tested. Mature changes then flow to the UI_int stage and on to the QA and Release (Rel) stages, again being subject to continuous integration and testing at each stage. The web development team in Austin picks up well-tested changes from the UI_int stage and uses them as the basis of their development work; when the web changes are mature they can be pushed up the hierarchy and subject to broader testing in the UI_int, QA and Rel stages.

Using a development hierarchy provides more opportunities for check-pointing. Every change introduced into the system is a potential source of failure, and thus a potential checkpoint. If a change proves to be unstable, you can return both the source stage and the destination stage back to a previous checkpoint. By contrast, mainline development only offers you a single opportunity for check-pointing, specifically, the state of the main codeline itself. Unless your development process includes “freezing” the mainline for a long enough period to build, test and otherwise validate, the chances of isolating and check-pointing at an appropriately fine level of code granularity are slim, making any available checkpoints stale and of limited utility.

Automating builds at all stages in the hierarchy

In order to give developers prompt feedback about the changes submitted, the code must be built frequently, ideally several times per day. A continuous integration server such as CruiseControl, CruiseControl.NET or Draco.NET can be employed to automate this process. The continuous integration server periodically polls the SCM system for changes, populates the changes to the build server, initiates the build process, and reports the results of the build and unit tests.  It is important to note here that the continuous integration server utilizes the existing build scripts and build environment to execute the build. For example, if make is used to compile and link components written in C, then the continuous integration server will call the makefile to initiate the build process.  Because the continuous integration system uses the existing build, it is important for development groups to devote time and effort to:

• Making the build as fast as possible,
• Building automated unit tests and
• Including unit tests as part of the build process.

Spending time on these items, even if it involves some rework of the build system to make it more compatible with a continuous integration environment, will improve not only the build process but the overall quality of the software release.

When utilizing continuous integration, it is crucial to communicate the results of the builds to the entire development team. Continuous integration system planners should consider a scalable communications method such as e-mail notification or an internal website to display build results.

Continuous integration servers such as CruiseControl come with built-in web reporting that can be easily customized, so that build results can be displayed on LCD panels in common areas at geographically dispersed locations. In this way, team members can easily see and respond to the build results and reduce the “fix latency” often encountered with nightly or weekly integration build approaches.

Goals of Continuous Integration

If a primary goal of continuous integration is to improve software quality and reduce downstream build and test failures, then perhaps the single most important SCM best practice is to enable automated local developer builds. To this end, developers should be provided with access to a local build environment that mirrors the production build environment, including:

• Database schema
• Configuration files
• Environment variables
• Shared libraries and files
• Known compiler/linker/runtime environments

This minimizes the “it compiled fine on my machine” syndrome that plagues many development efforts. Once the build environment is available, every effort should be made to automate the local build, so that each developer can build easily and quickly without having to perform a series of manual steps.

Ideally, the developers should have access to a private build area that uses the same tools and configurations as the production builds. As part of configuring a local build, developers should be trained to take several steps to ensure that local changes will have minimal negative effects once shared with other developers and teams. These steps are as follows:

• Updating their private workspace to obtain the latest shared configuration code
• Merging conflicting changes from the shared configuration to their private workspace

By ensuring that developers have known, good build environments, and that they have the latest code with all conflicts resolved, there is high probability that the local build will succeed. If the local build is successful, a continuous integration build that includes the developer’s changes should also succeed.

Shifting to Continuous Integration and Frequently Updating Code

Traditionally, developers tend to put off sharing their changes, sometimes for days, because they don’t want to affect other people too early, or don’t want to get blamed for breaking the build. Unfortunately, this strategy tends to backfire and typically leads to more problems in debugging larger sets of changes after a build breaks. Independent of whether continuous integration is being employed, encouraging developers to build, test, and share their code in small “chunks” is a simple and effective way to improve team collaboration and reduce costly broken builds.

The importance of frequently updating the code in the SCM system is amplified when organizations move towards a continuous integration model. Continuous integration represents a paradigm shift for software development, emphasizing communication between developers about what changes have been made. By breaking down tasks into small chunks that take several hours to complete, developers can “commit” or “promote” their changes frequently and receive immediate feedback about the quality of the changes through the continuous integration build and unit test results. As teams get accustomed to this new approach, developers also gain a sense of progress by seeing not only their own changes build successfully, but also seeing the changes that other developers have made available.

There’s no denying that this has certainly been the Agile decade for the software development industry.  It’s evident all around us in this tenth year since the Agile Manifesto was created. Most companies and development organizations today have implemented some form or aspect of Agile methodology into their software development processes. Whether you’re aiming for pure Agile or a mixed/hybrid approach, proven best practices in all phases of the software development lifecycle are crucial to success.

This is especially true in the case of continuous integration, one of the foundational aspects of the Agile methodology. The concept of continuous integration, as defined by Martin Fowler, is “a fully automated and reproducible build, including testing, that runs many times a day.  This allows each developer to integrate daily, thus reducing integration problems.”

With this approach, developers can work more closely in parallel while identify problems and debugging on the fly, accelerating the development process and improving the quality of the finished product.  The benefits of continuous integration are tremendous, but can quickly be eradicated if software configuration management (SCM) best practices are not carefully followed.

There are a handful of SCM best practices that can optimize continuous integration.   Let’s start with a quick look at the first two:

• Using an SCM system to store and version all source code
• Utilizing private developer workspaces

Best Practice: Using an SCM System to Store and Version all Source Code

Parallel development and distributed software teams can make tracking changes a daunting task, especially with the frequent changes that occur when using continuous integration methods.

For this reason, it is important to employ a software configuration management (SCM) system to strictly version changes to the code base. In addition to versioning source code, everything needed to build the system should be placed under version control, including the following:

• Third-party libraries
• Properties files
• Database schema
• Test scripts
• Install scripts

All developers should have at least read-only access to all files needed for the build and should obtain all such files directly from the SCM system. This approach ensures that developers are working with the latest build environment, and is preferable to the common but error-prone practice of placing such files on a shared file server.

To effectively implement continuous integration, all development groups should work from the same central source code repository so that the latest changes from other developers are easily and immediately available.

Best Practice: Utilizing Private Developer Workspaces

In order to fully realize the benefits of continuous integration, software development organizations need to ensure that developers can remain productive regardless of the overall state and stability of the project source code. To achieve this, private workspaces that give developers full SCM capability should be used. Private workspaces enable developers to

• work in isolation
• revert to known “good” states when needed
• checkpoint their changes
• share only mature, well-tested code with other team members

The benefits of isolation are bidirectional—it protects developers from incoming changes, and protects the shared code configuration from incomplete or incorrect changes from any one developer. By creating private workspaces, developers receive all the benefits of SCM for their personal use, including the ability to revert to a previous state, viewing and tracking of changes between software configurations, and setting aside changes to begin work on a different task.

Once a new known good state is reached (for example, when a developer completes engineering and testing work on a feature), developers should checkpoint their work, typically by “checking in” or “keeping” the local changes in the SCM system. The checkpoint ensures that the developer’s work is safe on the SCM server and that the checkpoint can be revisited at any time. However, since the changes have not been shared, other developers and teams are not affected.

When a developer breaks isolation and decides to share a code change, he or she is essentially making an assertion that the change has reached a higher level of maturity. This, coupled with the use of local developer builds, helps to ensure that only mature, well-tested code is passed on to the rest of the development team, a primary benefit of continuous integration.