In a previous post we examined an “Agile pain points” survey that highlighted some of the top obstacles organizations are facing when trying to adopt Agile practices.  Now that these obstacles have been identified, you might be asking – as we did – where do we go from here?

The Importance of Agile Tools

We think these findings reinforce the need for ALM tools to support Agile implementation, accelerate adoption and build a foundation to scale Agile.  Developers need integrated, yet flexible and customizable toolsets encompassing Software Configuration Management, Build and Release Management and Agile Lifecycle Management.

Agile Roadmap

In addition to Agile tools, development organizations also need to adopt new approaches to support Agile. Here is a roadmap for organizations as they head down the Agile path:

- Take a fresh approach to capturing requirements. The first thing you should consider is that the focus of requirements in an Agile world shifts from developing a detailed specification, to collecting user stories.  Having a development process and the necessary tools to support gathering, tracking and managing of user stories is crucial when going Agile.

- Invest in test. Even when not practicing explicit test-driven development, the importance of testing – unit test, regression, and system-wide testing – is considerable throughout the Agile development process no matter what method is being used.

- Release early and often. Organizations should look for planning tools that track when user stories are done and ready for customer feedback, source code tools that show where user stories are in the development process, and build and release tools that create releases continuously.

- Build In-house expertise from the outside in. Organizations should work with vendors that have a full suite of training and coaching offerings, in particular seeking those vendors that go beyond generic Agile training and instead examine the organization’s existing processes and goals and customize training for their specific needs.

- Incorporate release aspects in early Agile plans. Building in real-world items like testing and deployment will allow issues to surface early, before they become entrenched in the code base and difficult to address.

- Recognize that scaling Agile reveals dependencies between projects and teams. Having the ability to track both Agile and traditional projects in the same tool interface can prove critical to ensure a smooth scaling out process.

- Don’t forget about requirements when going “all in” with Agile. Lastly, organizations should be sure tools and processes clearly show team members all key aspects of requirements and are flexible and powerful enough to keep pace with the dynamic nature of a fully realized Agile environment.

We’d like to hear what you think – what steps have you and your organization taken to support Agile adoption?  What have are some other steps organizations should consider?

For details on AccuRev’s findings and more on these recommendations, check out the full Agile Adoption Pain Points Survey report, available free for download at http://www.accurev.com/whitepaper/agile-pain-points-survey.

AccuRev hosts educational Agile methodology seminars called “Agile Comes to You,” which reach audiences nationwide and focus on teaching best practices of Agile software development.  The seminars have been quite successful, and regardless of their organization’s level of Agile adoption, I know attendees have learned some great information from these sessions.

AccuRev doesn’t host the Agile methodology seminars alone, and generally presents in conjunction with partners Rally Software, Urbancode (the makers of AnthillPro), and Coverity. The seminars consist of a keynote with extensive Agile experience, educational presentations, and a short tools demonstration. The format has been so successful that we have used it for over a year, and you might even notice similarly-formatted seminars from other organizations as well. (Imitation is the most sincere form of flattery, right?)

The Agile Methodology Workshop

We try to focus on making our seminars as educational and relevant as possible by giving attendees access to the real life Agile experiences that presenters bring to the table.  So in addition to presentations focused on benefits of the Agile methodology and best practices, we came up with the concept of an “Agile Workshop.”

The Agile Workshop  allows each attendee to discuss their most difficult challenge in transitioning to Agile with other attendees in small groups, as well as with our Agile experts.  We do this for two reasons:

1) It gives the attendees a chance to exchange thoughts and solutions regarding their Agile migration.

2) It allows the attendees to interact with the panel of experts on how to solve these difficult challenges.

Once the group has discussed the challenges each individual faced during a transition to Agile, they then agree upon a top challenge that they ask the panel of Agile experts to comment on and offer advice.

For example, at a recent seminar in Toronto, this was the attendees list of top challenges:

We have been seeing this same pattern across most of our seminars, and I believe it gives us good insight into the state of Agile adoption.  It is amazing to see that even across very different organizations, the challenges that arise with Agile adoption are remarkably consistent from seminar to seminar.  It seems that no matter who you are, or what stage of Agile adoption you are in, many are facing the same challenges when moving towards Agile development. There is some comfort in numbers, knowing that you are not alone in facing hurdles.

While I won’t take the time to answer every one of these challenges here today, I plan on commenting on each one of these issues in the coming months, in hopes that sharing my experiences and alternatives help you in solving these difficult problems.  I would also like to invite some of our Agile experts, as well as our attendees, that are internal to AccuRev or our partners to comment or blog on some of these topics to share some of their experiences.

While the “Agile Comes to You” tour is taking a short break for the summer months, be sure to look for us in your city this September or stop by and visit us at Agile 2010 Conference in Orlando.  Have a great summer!

This past year I’ve attended several Agile conferences, presented at many of our own conferences, and traveled to Agile tradeshows sponsored by some influential industry-leading names. What surprises me most is the variance I see on the answer to this question: How do I do Agile with remote teams?

Some of the pure “Agileistas” will may answer this question in a manner that isn’t very possible for some of us in the real world, with “Don’t do it” or, “Reorg your company.”

I don’t’ know what those people expect here- is it possible that you can convince your management organization to tear down its office walls, move entire teams from across the country into one office space, just because you heard it at a conference that it was going to be really hard to do Agile remotely?

I certainly don’t believe that doing Agile with remote teams is a bad practice, nor do I believe that it’s impossible. Challenging? Yes it is. Easy to mess up? You bet. But there are some simple things you can do to avoid some of the pitfalls of remote organizations.

Agile with Remote Teams

Use face to face communication methods:

I just got the iPhone 4. It has face to face video chat. I also use Google Talk, and this also has video chat built in. It works great! With all the communication technologies we have now a days, there is no reason to avoid personal contact with remote teams.

If the remote team is a faceless organization, it will become a perceived impediment for the local team if there are problems. They wont’ be treated like part of the team, but more like an outside entity that drops code in and risks messing up the release.  We can bring these teams closer together to encourage communication, and allow them to adapt and respond to each other as issues arrive. Creating a persona and human link turns those faceless “code drops” into real people, people who you can reach out to. This gives the team the power to self manage your priorities, impediments and conflicts.

Create Agile ambassadors

We can even take face-to-face chat on the internet up a level. Sending ambassadors back and forth from the remote teams to home base and vice versa creates a human link that is deeper than any piece of technology can provide.  The ambassador’s job is to strengthen this link, because if the link is strong, each side will be more inclined to help each other.

Sometimes having a planning session with the remote team doesn’t give them the overall sense of how important the stories you’re working on might be. They may not feel as if it’s important, and that’s because they don’t know all the juicy details that led up to the creation of that story. Having an ambassador at that site gives that team visibility into all of the bits of information that make one user story important. In other words, the ambassador gives the entire back-story to an iteration (IE the gossip) so they can get a sense of how important something is, it’s not just a priority number in the ITS.

Use Tools That Work Globally

With all of the face-time, ambassadors, and communication, it’s essential that teams have a global view of what’s happening during the development cycle. It wouldn’t make much sense to reach out and then not provide a way to extend that communication on the development level.

Imagine a team where having access to a user story or a piece of code wasn’t easy and available to them? This handcuffs the team tremendously.

Any remote team will need to be able to:

• See each others user stories and tasks
• Enter updates to user stories and tasks
• Diff baselines and branches
• Check out code from remote teams
• Contribute to team discussions and wikis
• Run continuous integration globally

Use Multi Stage Continuous Integration

Using multistage continuous integration lets people take a look at what’s been built, and if it functions correctly, give it to the other team. Having multi-stage set up gives you a way to integrate early and often, but only deliver changes that are “done”.

One of the main problems with remote development is integration, and it’s a double edge sword for most SCM tools. If you isolate the remote team too much, they won’t integrate often. And when they do integrate to mainline, they may break functionality. The problem with this is that they will not be able to respond to that change for 6-12 hours if your team is in another country. This basically means downtime for everyone.

But with multistage CI and AccuRev you can keep that team isolated and integrated at the same time.

Is it possible to do offshore Agile?

I’m not sure if it’s a question if it’s possible, I don’t think we have a choice. Offshore development is a reality that isn’t going away, and the simple answer of bringing teams together to practice Agile isn’t always variable.  Doing Agile with remote teams isn’t’ a choice, it’s a reality.

When talking about Agile development, people often ask me, “but why would I want to change to a new methodology when traditional development has made so much money and created so much value for so many people for such a long time? Why mess with success?” That’s a great question!

After hearing that question for the umpteenth time I finally realized something.  It isn’t traditional software development that has provided so much value! It is the software itself. Imagine calling a travel service prior to the advent of software. You call them up and say “I’d like 100 or so options for travelling from Boston to San Jose. I’ll also need a bunch of 3 or 4 star hotels in San Jose and mid-sized rental cars to choose from.  Could I get that in 5 seconds please?”

In today’s world, of course you just go to a site like Orbitz.  It isn’t traditional software that provides that value, it is the software itself.  It almost doesn’t matter what process you use to produce that software, the value is so high. When you are only competing against somebody that doesn’t have software, that’s one thing. When you are competing against other organizations that are also using software, then the exact process you use can make a big difference from a competitive standpoint.

What do we mean by “traditional development?” After having been involved in the process of literally thousands of software development organizations, I can safely say that there isn’t really any such thing as “traditional development” or even “waterfall.”  That is, if you look at any two organizations developing software, there is no standard for what comprises traditional development.

In the end, organizations adopt individual practices that make sense for their circumstances. This same approach can be used when adopting “Agile.” There really isn’t any such thing as “Agile.” It is a combination of values and practices which can be adopted by any organization and does not require wholesale adoption in order to provide value. Yes, there are packaged solutions out there such as Scrum, XP, Kanban and others, and they do provide value.  But so do the individual practices.  So, instead of thinking about “how do I switch to this new thing,” consider Agile as a new set of tools that you can add to your existing process on a case by case basis. Worry about “being Agile” after you’ve gotten some experience under your belt with some of the practices.

SQE’s “Agile Comes to You” seminar tour has added new dates and locations for the month of April!  Due to great turnouts and positive feedback, AccuRev, Rally, AnthillPro and Coverity will continue their cross-country tour with upcoming stops in Colorado Springs and Minneapolis.

The half-day seminars are filled with Agile tools product demos, presentations from keynote speakers, Coverity, Rally, AccuRev and AnthillPro, and a question and answer session with a panel of Agile product experts.   Below is the panel from one of the most recent seminars in Seattle.



Attendees also learn about the new AgileCycle ALM suite of integrated software and services, designed to increase the speed and impact of Agile projects and enable Agile adoption.

Interested in Agile and want to check out AgileCycle? Join us in Colorado Springs on April 6^th or in Minneapolis on April 7^th.

April Tour Updates pic

Register here for Colorado Springs on April 6^th.

Register here for Minneapolis on April 7^th.

I love the concept of self-managing teams.  Everyone figures out what needs to be done, and does their best to make the greater organization successful.  Beautiful.  Reminds me of the Shaker Village, the Russian Artel, or the Israeli Kibbutz.  All of which are (largely) extinct today.

There are three structural problems that, like termites behind the wallpaper in a French Quarter house, cause these “worker’s paradises” to fail.  Our job, as managers of the Innovation Engine, are to sniff ‘em out, expose them, and exterminate them.

Problem #2: PURE – Previously Undiagnosed Recruiting Errors

My old boss used to tell me there were three kinds of programmers.  Those smart enough to do the job, those too stupid to do the job, and those that could do the job but don’t care to.  Well, that’s not exactly the words he used, but this is a family blog.

None of us is the perfect recruiter, and every once in a while people get through the screening process that we’d rather have work for Al Qaida.

The incompetent developer (which we managers code name “moron”) is not always the one who takes the longest to do a story.  If some developers generally take longer than average to complete a story, they may be “slow” (as my grandmother would have put it) or the estimates may be dominated by optimists.  Until you’re measuring the amount of rework created by bugs found in QA (and the field), you really won’t know.

That doesn’t mean you don’t have to take action: managers have been acting on intuition since the Donner party decided to try the Sierra Nevadas in the winter of 1846.  Sometimes it’s better to eat the mule than have the whole group starve.

As engineers we tend to focus on technical proficiency, but there are some things which are hard to judge in an interview.  Like whether a developer has good judgment of when to refactor and when to patch.  Or whether a developer can embrace process changes or will struggle for weeks with the changes.  Or whether a developer has that certain combination of personality traits that make their coworkers doodle pictures of poisons, weapons and torture devices.

Now finding the sociopath may be more difficult than you think, because they’ve cleverly chosen to hide out amongst programmers, most of whom act as though still carrying scars from middle-school.  Like a submerged rock in the river, sometimes they can best be detected by the havoc they leave in their wake.

Developers generally treat managers using the same rules the Mafia use with the DA: no matter how much we loath our co-workers, we’re not going to rat them out.  One-on-one meetings with group members can give some indication of problems.  A few tactful questions at retrospectives may give some clues to underlying issues that aren’t being discussed.

Try inviting the group to try a little pair-programming and see what pairs get put together, and who threatens to quit.

Finally, the toughest people management issues are when good performers drop off.  Often this is a temporary fluctuation which just requires some coaching: do they need some customer visits to increase motivation, maybe a chance to learn some new technology they can apply, or sometimes there is a transient personal problem that just needs a little extra time.

Often, establishing expectations with people of what needs to be improved and then giving them a little time to do so is just the right prescription.  They may need mid-course correction and coaching to improve.  They might just need a supportive shoulder, or a swift kick in the pants, but the combination of communicating the issue, establishing higher expectations, and providing support is a good combination for improving performance.

Unfortunately, persistent decreases in performance are usually like that oil leak under your car every morning: they indicate there’s more going wrong than you thought, they’re probably going to get worse, and if untreated the future isn’t going to be pretty.

The most common mistake I see in my conversations with engineering management is the “conflict avoider.”  We’ve all made excuses about how long we need to wait to see if the situation can improve, how hard it is to find new talent, how much training time and ramp-up it is going to take to get a replacement up and productive.  And don’t forget the ‘ole disempowering “I can’t make a change in the middle of the project!”

These are just excuses. We owe it to both the team and the company to accept our mistakes, make the changes, and get on with building a better future.  That’s what we get paid to do.

by Brad Hart

In just about every situation in the last 8 years where I’ve gone into a prospect to talk about replacing ClearCase, I’ve been asked the question about ClearCase’s Dynamic Views and why AccuRev does not have a similar concept. It’s a fair question coming from those who are familiar with ClearCase and I’m posting this blog to help both give some background information on Dynamic Views and answer some of the common issues raised by former users of ClearCase before they made the switch to AccuRev. I used to work at Rational Software in both Support and in the Field and I spent a number of years as a ClearCase consultant before coming to AccuRev in 2001.

At the time Dynamic views were introduced, there was tremendous pain in the market using a local source copy model, especially in enterprise applications. Disk space was extremely expensive, and it was becoming increasingly infeasible to have large enough disks on each developer’s workstation. Networks were also much slower, and the time required to copy entire sets of source code to each developer’s workstation was unrealistic as applications grew in size and complexity. Dynamic views provided the appearance of each developer having a local copy of the source files, but without the time / disk space overhead associated with having real local copies. They also provided just-in-time access to files across a network connection which was transparent to the end user, similar to the way NFS works. Unlike NFS, which you only can access the latest version of files, the dynamic views allow the developer to reconfigure their view of the files to represent any given configuration past or present. Also, unlike a local copy model, reconfiguring what a developer sees does not require any file copying to reflect the changes. This saves time and money and the savings continue to scale the larger the development group gets.

Does it still hold water?
No. Both workstation and network hardware costs have dramatically dropped in recent years, and the performance has increased exponentially. It is very common and reasonable for developers to have near server-class systems on their desktops. In many cases, it is now a much better time savings to have developers work with local copies of their source files. In fact, Rational’s default usage model for developers is to do their development in a local copy source file model, contradicting the presence of Dynamic views. Dynamic views were a time and cost savings breakthrough when it was introduced, but given the changes in development environments in the current time, it is more often than not seen as a hindrance. There is also a much higher administrative burden associated with Dynamic views. Especially if you are working in a mixed environment (SAMBA, TAS, etc… need to be properly configured and maintained). Also, Dynamic views are notoriously unreliable and unusable over remote connections. Another major objection to Dynamic views from the developer perspective is that most developers don’t want “the rug pulled out from under them.” Your files are constantly changing in your view….how are you supposed to develop/build and test like that? Add in the fact that ClearCase does not have atomic transactions, and developers using Dynamic views will constantly have inconsistent sets of code to work on. Bottom line is that even Rational recommends developers use Snapshot views (like AccuRev workspaces) and only use the Dynamic views for integrations. Since AccuRev truly builds in parallel development, you don’t need an integration view/workspace. All your work can be done directly from one workspace.

Five things I’ve heard from developers on why they think dynamic views are important to an effective development environment:

WYSIWYG: The final test of your code changes before check-in is exactly the same thing as testing the release area code directly. No need to “check it out again in a different place just to make sure I checked in everything right.”

AccuRev allows your private work (keeps) and your check-ins (promote) to all occur from the same place (you don’t have to check out to a different place). AccuRev builds in best-practices like private-branching (workspace streams), atomic transactions, and copy-merge. You don’t get that out of the box with ClearCase. AccuRev’s built-in best practices absolutely improve the entire process. You absolutely must merge against the latest code before you promote your changes (for overlapped files). Plus, developers have total control of their workspace bringing in new changes as they are ready. That way if something is broken, they will know whether it is their code, or the latest code from the mainline. With Dynamic views, you will have to go find out for yourself and it is constantly changing. I have heard a lot of the “rug being pulled out from under me” analogies regarding dynamic views.

Zero-latency perfect synchronization with the release area: no time is ever spent checking out all the files in the entire directory just to see the release area. You are always “seeing” the release area. Your code is the release area.

Running updates in AccuRev is trivial and incremental. Performance far exceeds ClearCase’s snapshot views. You don’t need to check out all the files. Updates just bring in the changes.

Instantaneous creation of a new view into the release area: Suppose you want to do a quick mod and test of the release area code. Just create a new view, make the code mod, and do a build. You are good to go. No time spent doing a full checkout of everything just to modify 1 line of code in 1 file.

With AccuRev, you can simply re-parent one of your workspaces, update, check in your changes…done.

Automatic synchronization with the continuous development of code in the release area. Suppose you have a huge pile of code checked out for 3 weeks, and one week into it somebody checked in a change that broke your implementation. Dynamic views force you to reconcile the merge difference the moment the file is checked in, while it is still fresh in everybody’s mind. No trying to recreate the scenario 2 weeks later because you forgot to do a refresh of your sandbox. Your build will immediately fail, and you can confront the guilty party before they go on to work on other stuff. With dynamic views, the team is always in alignment and working on the code together.

Too much thrashing. This might work for a very small team. This would be mayhem for a large group.

Entire directories can be rearranged without worrying about somebody’s checkout becoming unmanageable. Since everyone instantly adopts all the changes that take place in the release area, all the files in a directory can be moved and changed without you even being aware of it. All of your “checked out sandboxes” instantly are updated to work with the new directory structure. This freedom encourages engineers to create a well structured file hierarchy, even making changes during critical bugfix periods in a product development cycle a non-issue. One does not feel the need to keep around old sandboxes “just in case everything breaks.”

Absolutely no problem for AccuRev. AccuRev has true namespace versioning and handles all elements using element ids. You can work on a file and have someone else rename it and it will cause you no problems at all. When you update, the file will be moved to the correct location and your changes will remain in effect.

This post is not meant to discredit the work done by the ClearCase development team, but rather to point out how Dynamic views have all but become obsolete. The VCR changed home entertainment forever…but you’d have to pull my DVR and DVD players from my cold dead fingers while my VCR is nothing but a fond memory collecting dust in the basement.

What are your thoughts?

-Brad