It’s here! AccuRev today announced Kando, the seamless integration of Git with the AccuRev server. Everyone at AccuRev is incredibly excited about it.

As many people know (and as we discussed here last week), Git is increasing in popularity among developers working in small groups or collaborating on open source projects. It’s also fast, flexible, and full of developer-friendly features. But when it comes to using Git in an enterprise, the size and complexity of these environments can make it difficult to secure and manage the software development process.

What makes Kando different from other Git integrations?

Take a look at the diagram below. With Kando, Git developers push and pull from real Git repositories. Kando takes all changes pushed to these repositories and replicates them on the AccuRev server. Furthermore, any changes made in AccuRev streams that are mapped to Git repositories are replicated in their respective repositories. This means Git users can just do a pull to get those changes, which allows Git users to continue using Git as usual without interacting with AccuRev, if they choose not to.

 How does Kando benefit Git development environments? 

Kando enables the flexibility of Git and the security of AccuRev by providing:

• Support for enterprise authentication via LDAP and Microsoft Active Directory
• Fully integrated issue tracking system and Software Change and Configuration Management (SCCM) through change-based development with AccuRev Change Packages
• User and group-based access control security measures
• Visualization of development processes using Git through the AccuRev StreamBrowser
• Seamless integration of Git into an AccuRev environment

Take a look at how it works:

To read more about Kando, watch the demo video, and learn about beta availability, check out the Kando page here!

I’m very excited about our 5.2 release! We’ve completed the move to PostgreSQL on the back end, fully internationalized our products, and added a slew of new features, like per-element security so that you can lock down certain files or directories to specific groups or users.

In addition to moving to PostgreSQL, we’ve taken advantage of its capabilities to increase performance in a few key areas such as update, especially when using cross-links, populate, and more. And as a first step towards fully embracing 64bit servers, we now support 64bit CPUs on Linux servers. You can look forward to additional performance boosts as we exploit the capabilities of PostgreSQL in the future.

Haven’t upgraded in a while? Check out what else is new! To get a full flavor of all of the new functionality we’ve added recently, check out recent webinar which highlights what’s new.

If you haven’t tried our plug-ins in a while, we’ve put out new releases of our Eclipse and Visual Studio plug-ins for all versions of AccuRev. Eclipse and Visual Studio plug-ins will work with older releases, so no need to wait for 5.2 to start benefiting from the new features in the plug-ins.

We’ve fully integrated the Web UI into the plug-ins so you can now use all of the following functionality: version browser, annotate, stream browser, and all of AccuWork. Also, in 5.2 you can now access the Web UI with a single click from most screens. For instance, if you want to send somebody a URL of a file or diff, you can just click the “copy to clipboard” button in the toolbar and then compose an e-mail to somebody and paste in the URL. When they click the URL, they will go right to that file or diff. And the Web UI now allows you to print any table that it supports.

While we are in the process of making the new functionality in the Web UI available in all of our UIs, this is a great first step to quickly link to the new functionality.

A Few More Details on What’s Available Via the Web UI
If you haven’t used the Web UI or are using an older version, you may not have heard that there is an entirely new version browser in the Web UI and for AccuWork users- AccuWork on the Web has been completely revamped. For instance, it is easy to search by keyword and you can do drag and drop query editing.

5.3 and Beyond… Here We Come!
The database and internationalization are two very important infrastructure changes which will accelerate both our engineering velocity as well as our market penetration. With our upcoming 5.3 release we will be re-introducing our quarterly pace of releases as we had with our 4.8 and 4.9 releases. With the switch to PostgreSQL and an internationalized code base complete, you will see the release of new functionality faster than ever before. In preparation for 5.3 and beyond, we’ve just launched a new product survey as one of the many ways we collect product priorities. Make sure to look for it and fill it out. It is one of the best ways to have a significant impact on our product roadmap. If you haven’t gotten an e-mail yet, you may not be in our survey database. Just ask your AccuRev administrator for a link.

I mentioned on this blog last week that AccuRev had big news coming that would mark the next phase in the evolution of SCM – the first big leap since AccuRev introduced the stream-based approach. Well, the big news has arrived with this week’s launch of AccuRev SCM Version 5.2. AccuRev Version 5.2 arms developers with one of the few SCM solutions on the market today that offers streams and enhanced enterprise performance, reporting, security, and scalability through the postgreSQL relational database we’ve embedded into our system.

With this release, AccuRev has also introduced AccuWorkflow 2.0, a collaborative process-centric governance tool that enables automation and compliance with an issue-based lifecycle workflow directly within AccuRev. AccuWorkflow is especially valuable for developers of software solutions for highly regulated industries such as financial services with its stringent requirements for SOX compliance.

AccuRev 5.2 is available immediately.  Check out the press release here  for more details, or see us demo 5.2 at Agile 2011.   You can also check out a brief podcast we put together that examines the major issues and challenges today’s enterprise developers face and how we’ve attempted to help solve those challenges with AccuRev 5.2.  Click here to listen in.

For more info, check out What’s New in 5.2.

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.

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

Rationally Wrapped

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

Developers Revolt

Locked out of ClearCase again?

AccuRev will never lock developers out.

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

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

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

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

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

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

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

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

To paraphrase Harry Truman, if you’re looking for love in the software tools business, buy a dog.  If you’re looking for areas to improve, ask your customers.

For some time now I’ve noticed that those customers of ours developing both software and hardware find benefits in being primarily Agile in their software teams, but primarily Waterfall in their hardware teams.  It’s hard to fit “parsing a Sonet Frame Header” into a story, and it’s expensive to do a feature add iteration on the Mars Rover.  Especially when it’s already on Mars.

Interestingly, a large number of our customers’ software development groups have a mix of Agile and Non-Agile projects.  Sometimes there are tactical issues keeping them from being successful in Scrum at the current time (the group is too junior, they don’t have enough trained Scrum Product Owners to keep up, etc.), but some groups have especially difficult challenges making Scrum adoption difficult.

Where Scrum is Easiest to Adopt

I have come to the conclusion that Scrum works best when there is a linear relationship between team effort and customer benefit.  For projects that are highly non-linear, a process that invests more in up-front planning and architecture and then uses Scrum later in the process, works well and is easier to adopt.

Let’s look at a classic Scrum-benefit project.  You have an application in production use with a set of customers.  Customer feedback has resulted in a list of feature adds, each of which is in the one- to six-weeks of development effort range.

In this situation, plus a little training and tool support, the team will leverage Agile techniques like time-boxing, continual customer feedback, integrated QA and development, etc. and rapidly start to deliver real customer value.  Pretty soon, the customer will start asking, “Why don’t all your development teams use this new fangled process?”

There’s a nice linear relationship between the amount of work done during each iteration and the amount of feedback the customer gets.

Here are two curves, demonstrating the concept:

The customer feedback in the linear case is used to guide the product as it is developed, which overcomes the errors found in a traditional requirements documentation exercise.  This is the great win in the Scrum process: too many requirements of development turn out to add negligible customer value in the final delivery.

In the non-linear project, by the time the customer has gotten to week 10, they’re disengaged and putting pressure on the team to work on something else.

Agile engineering practices, like test driven design, unit tests, continuous integration, etc,.  add value whether  or not you end up at Scrum: better engineering practices are always useful. Is the development cadence produced by regular iterations more valuable than the executable, milestones in a good project plan?  In a linear problem, yes, there’s a lot of evidence that it is.  In a non-linear process, some teams see the benefits all the way along the process, and others benefits later in the project, after some of the basics of the architecture have been mapped out.

Non-linear Returns

Unfortunately, not all situations are linear.  There are several factors that produce non-linear returns.  Amongst them are such typical software challenges as:

-          Tent-pole like problems. This refers to the situation where there is a tent held up by a lot of tent poles.  Taking out a few tent poles doesn’t decrease the height of the tent. But when you take them all out, the tent lies on the ground.  They typically require you to develop a clear architecture and strategy, up front, and invest in working to fill out the architecture.  Examples of this kind of problem include supporting a new language (e.g. Japanese, not C#), greatly improving performance or porting to a new platform.

-          Implementing something of technical risk. If you don’t know *how* to do something, the Agile process of “doing Spikes” does not necessarily converge on a solution in a fixed amount of time.  Be advised that in this case, in Waterfall as in Scrum, you may end up going down multiple blind alleys, so the outcome better be worth the uncertain cost.

-          Developments with high business risk relative to development effort. Software controlling the Mars Rover is an example, but so is software embedded in a cardiac pacemaker, software that runs your e-Commerce site, or software that can make real-time stock market trading systems.

Success in non-linear projects often leverages the best practices of Agile in ways familiar to project leaders of Waterfall processes.  Two week iterations might not make a lot of sense when a customer‘s input isn’t of much use, but continuous integration, focus on upfront test, and meaningful, executable, milestones every week or two that contain customer value sure do.

Finally, a note about Pollution, or “technical debt.”  Each time we implement something of customer value, we either increase or decrease the technical debt load in the application.  Usually, when we focus exclusively on the customer story, we increase technical debt (“pollute”), and when we invest in decreasing technical debt, we deliver less customer benefit in the short term, in the interest of having better customer return in the future.  This is not a case of non-linear returns, but rather a symptom of a weak Scrum implementation.  Avoiding the build-up of technical debt is fundamental to a good implementation, and is one of the challenges of Agile management.

Most companies that build mission-critical software find they have both types of problems.  Their requirements on us as a tool and process partner are difficult but straightforward: support both processes with the same tool stack, and integrate development to enable code sharing.

Agile may be the single biggest advance in software development practice since The Mythical Man-Month, but it’s not The Magic Bullet.  Smart companies are learning how to utilize the best procedures for the problem at hand.

Amazing fact: The lookout crews for the RMS Titanic were without binoculars. Due to a last minute change in personnel, the team member who was in charge of spyglasses, binoculars and other optical equipment was not on board the ship, and all of this equipment was unfortunately locked away, crew members unaware of the location.

We all know the rest of the story; by the time that the lookout crew saw the iceberg, the opportunity to change course already passed.  There was not enough time for the crew to respond to the problem and correct it. They had no visibility (literally).

Agile is about adaptation. It’s not about sticking to the plan; it’s about exposing and responding to change in your development cycle. But how can you respond to problems if you don’t know what they are?

Our last blog post was about “inspecting and adapting”, and I don’t want to get these 2 success factors confused. The real point that I’m trying to get across is that visibility in an Agile environment allows your teams the ability to inspect and adapt to impediments.

Why is Visibility in an Agile Environment Important?

Information in an Agile environment is viewed more often, and scrum teams  need to see this information on a daily basis in order to change course if necessary. Visibility in an Agile environment allows teams to use information in their stand-ups, sprint reviews, demos and retrospectives.

Visibility also needs to happen on a large scale, and everyone needs to be involved. Just think, if we gave only one pair of binoculars to the entire look-out team on the Titanic, it would have been much less effective than if each team was equipped with the proper visibility gear. Everyone needs to be aware of the problem in order to change courses.

But here’s the real trick. Centralize this information, make it visible to everyone and all your tools.  If you do this, you can integrate with all of your processes. This guarantees the information in the tools is correct. For example, if you have an integration in your SCM tool to your project management tool, you can see what changes correlate to what iteration, guaranteed. You can also integrate your build, test and deploy tools to provide tractability on all levels of the stack. Centralization also provides a single place where everyone can see what’s happening. Scattering the information against multiple tools that aren’t “Agile aware” will only confuse the process.

So having a global visibility can help re-route a ship that’s traveling on a disastrous course. It can also help your development teams change course when they need to.

Wouldn’t it be beneficial to get your whole team some binoculars?

Integrate early and often, it’s a software configuration management mantra that we’ve been repeating for years. Integrate early and often is continuous integration. Every source control tool promotes this concept; you can read about it in the SVN book to the ClearCase manual. It’s been preached as a SCM standard for almost as long as we can remember.  In the case of Continuous Perfection we gave up our “integrate early and often” principles, so how can we solve this problem?

Flexible Agile Tools to the Rescue

We can preach “integrate early and often” all we want. But if our tools don’t help us achieve that goal, it can be an exercise in futility. The problem with traditional SCM systems is even though they tell us to “integrate” the only thing they seem to do well is “isolate.”  Think about the branches in your environment; they are static representations of a point in time in your development cycle.  How do you know when it’s time to merge changes from the other branches? How do your developers know when it’s time to pull in changes to their local workspaces?

Automatic inheritance is a way to keep your developers connected with the rest of the organization. It gives them the ability to automatically pull in changes as needed.  It also connects entire development teams. (See “Understanding Stream Inheritance”)

The second problem is that when the build is broken, there is no easy way to recover. Asking an entire development organization to roll back the codebase to an older version could take a day. Having an SCM tool that allows you to move the milestone in which your branch is based off of is a powerful way to get around this.

Tying into this is your build management solution. Free continuous integration servers are great at building and spitting out the results. But with every build that’s produced, there are a set of actions that need to take place. Being able to dynamically roll out code based on test and build results allows your QA teams to keep working even when code has been integrated poorly.

Create a Culture of Integration

This is the most important aspect, creating an “integration” culture in your development team. Often merging code is an overlooked and under rewarded task. Developers must deal with the merges, but often don’t get credit for doing so. Sometimes a difficult code integration takes a few hours, and developers may feel that this is eating into their valuable time.

Incorporating continuous code integration into your daily lives can help this. This might mean that you have Tasks that are assigned to your User Stories that deal with code integration. Or this might mean doing a code / review / integration session with your team. Engaging our team mates and making sure that the work that’s being done for these code integrations is rewarded and recognized goes a long way in relieving the frustration of a bad code merge and ultimately saving you from Continuous Perfection.