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.

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’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.

I remember the first time I heard the term scrum development.  A manager at a previous job told me “We’re doing Scrum now, read this.” Then he handed me bunch of photocopied book pages.

After a comprehensive review of the pages, all I figured out was that Scrum had something to do with fast meetings every morning. And that was my first introduction to Scrum.

At a later job, I found myself in a meeting, brainstorming the best way to make Scrum work internally, and arguing over what Scrum was supposed to look like. Both situations, a minimally explained stack of photocopies, and arguments over the physicality of Scrum, resulted in negativity- people around me decided that “Scrum doesn’t work.”

How Scrum Works

In my situations, trying to make Scrum work took precedence over the team, and whether or not it could really take advantage of Scrum practices. Taking advantage of Scrum practices is what makes a Scrum team succeed. After all, the development term “Scrum” was derived from rugby for a reason.

The name Scrum was chosen to represent specific software development practices because like Scrum team in rugby, one team needs to cover a variety of responsibilities. This team works towards a common goal, continuously, in parallel, and under circumstances that could, and do, change rapidly. In rugby, the Scrum team needs to cover ground together. The clock never stops, teams never switch sides, and the ball can only be thrown backwards or sideways, forcing the team to move together in a line across the field. Similarly to Scrum in development, all team members need to know their teammates status, so they become aware of new gaps in the field position that need to be covered. In this aspect, the team needs to be self-managing, while it pushes the ball forward in sprints. This can’t wait for outside direction.

If your team is new to scrum, or struggling with it, the tendency to blame Scrum practices instead of a team’s unity often highlights deeper problems. If a member of a rugby team isn’t keeping up and leaves a gap in the line, no one would say ‘rugby doesn’t work’. The word ‘team’ gets thrown around business a lot when ‘group’ would be a better description. A team communicates with each other, strategizes, and members know how to truly work together- not just in parallel.

Functioning as a Scrum Team

In the film Invictus, Nelson Mandella tells the captain of the South African national rugby team that he needs them to win the world cup to gain the support of the nation. Players complain that their schedules are already full, and extra work like running rugby clinics for children isn’t worth their time. But after working together on these clinics, the team became much more focused and productive when it came to new responsibilities. As the captain said “We’re more than a rugby team now, we need to get used to it”.

The expectation to function as a team is built into scrum. If a group has seen previous success without having to self manage, or without leaving their keyboards for things like planning meetings, there will naturally be complaints that scrum isn’t working. In some cases teams may need to tweak Scrum in order to fit a specific organization, but before making changes it’s worth looking to see if your team is functioning like a team, or like a group.

Throughout 2010, we surveyed over 1,000 developers, product managers and other software professionals during our Agile Comes to You seminar series, about the pain points they were experiencing on their way to adopting Agile. The results showed several interesting trends and obstacles when adopting Agile, and we provided multiple solutions in fixing such problems.

Just a couple weeks ago, we kicked off our 2011 Agile Comes to You seminars with events in Phoenix and Atlanta, where we re-launched our research efforts aimed at gathering more insights into Agile pain points.  Our next Agile seminars are in the Bay Area and Seattle, on March 16th and 17th.  In each of these sessions, we will address the top Agile pain points we discovered, and their necessary solutions. We encourage the Agile community to join in the dialogue by reading our pain points report or by attending one of our upcoming Agile Comes to You seminars!

As you start to scale Agile, code and user stories have to be merged more often. Sometimes changes may flow from one organization to another. This means that you will need to take code from one team, merge, integrate, and test those changes. Each team needs to be able to work on their own schedule, and if multiple teams want to work on different sized iterations, they can. In addition, they can deliver changes as necessary and on a regular basis, independent of other teams.

The problem? With a traditional SCM system, you have to merge these code changes daily for them to be of any use. You also need to keep visibility into what stories are shared between teams, because delivering changes from user stories that are not completed in a sprint would be disastrous.

Typically, people use a single baseline or “trunk” methodology for this configuration, where changes from each team are delivered to trunk and pulled from trunk as their iterations complete.

Working within an Agile context, your teams will have to deal with these branching and merging issues. But there are other problems that can happen when you do not use this methodology:

1. Delivering 2 weeks worth of changes only causes isolation among teams
2. It’s too hard to pick out each user story as it completes from our codebase
3. Figuring out the dependencies of those user stories is complex
4. Being able to identify what changes came from each branch becomes impossible

This “baseline pollution” is not scale-able. You can get around this by using a development hierarchy, and manage the relationship of dependencies between branches. This could also include process steps such as integration, quality assurance and code reviews. A separate code configuration can be used for each step and user stories could simply be drag and dropped between each team, state or branch instead of a merge.

Doing this will increase code stability. As a completed user story is pushed from one stage to the next, the particular change as well as the system as a whole reaches a higher level of maturity. Many traditional SCM tools do not easily support or surface a development hierarchy. An Agile SCM system supports the creation of a hierarchy, gives visibility into the changes at each stage, and enables straightforward merging between stages.

Agile teams have a focus of interest- to continuously improve product quality.  In pursuit of this end result, teams often develop and agree upon engineering process changes. And when assessing potential process changes, stricter coding standards usually make the cut. Development teams are asked to abide by a certain set of guidelines in the code they generate, refactor, or maintain.  In practice, sometimes these guidelines end up improving product quality as desired, but sometimes these guidelines have no affect on quality at all. Or worse, sometimes these guidelines add only non-beneficial incremental overhead to the development process.

While most software engineers would agree that coding standards make sense in a group programming environment, the success or failure of these standards is a function of which standards are adopted.  While popular coding standards of the day or team members previous work experiences guide this decision making process, another alternative is for customer-reported defects to guide the process.  When a root cause analysis is performed on the customer defects incurred by a software development team over time, a few prominent causes are bound to occur again and again. These causes can usually be avoided through process changes, and in particular, through coding standard changes.

Customer-Reported Defects

Looking internally at our customer-reported defects over time, we certainly discovered some recurring technical themes.  For example, there were many defects that were associated with the programmer selecting recursion over iteration in cases where the problem depth was potentially unbounded.  The result was a sleeping time-bomb for stack overflow.

Another example, there were many performance-related defects involving the selection of an inappropriate container abstraction, given the expected data access patterns and performance requirements of the problem at hand.  (Your mileage may vary, but you get the idea.)  If the same group of people is evolving a code base over time, it is likely that over time, similar mistakes will be.

Agile software development puts the accountability for product quality squarely on the shoulders of the team.  Accordingly, self-managed software teams should be continuously evaluating possible improvements to the team’s behaviors, and coding standards is a great place to start.  If you want to avoid the pitfalls of choosing the wrong standards, take a closer look at your customer-reported defects.