AccuRev released for general availability today the first Git integration that seamlessly bridges the world of commercial tools and open source software configuration management.

AccuRev’s Kando, an enterprise security and compliance platform for Git, which was released in beta in January, complements the open source SCM tool with additional functionality, allowing organizations using Git to simultaneously leverage enterprise-level security and requirements traceability.

Kando is the first software development solution that enables Git development shops to add workflow, issue tracking, security, change requirements and other capabilities to the software development process, all while maintaining the flexibility and familiarity of Git environments.

Kando’s ground-breaking enterprise-level security and compliance capabilities allow its users to:

• Comply with enterprise-level regulations, by providing full audit and traceability
• Secure Git with access control capabilities, and support for enterprise authentication via LDAP and Microsoft Active Directory
• Visualize and manage development processes that use Git in AccuRev’s StreamBrowser™ environment
• Support Software Change and Configuration Management (SCCM) through change-based development with AccuRev Change Packages

“Our Kando Beta announcement in January had an overwhelmingly positive response, and it is clear that Git adoption has expanded well beyond the Linux community, into product development and IT,” said Lorne Cooper, AccuRev’s CEO. “Kando can solve many security and requirements traceability problems that enterprise organizations face when adopting Git, and really allows Git an opportunity to scale the development process across enterprise software development teams.”

During the development of Kando, AccuRev established the Kando Technical Advisory Board, comprised of representatives from several enterprise organizations with Git environments. To hear what they are saying, or to learn more about Kando, visit http://www.accurev.com/kando.

We held a “First Look at Kando” webinar on Tuesday to mark the launch of our back-end platform for security and compliance with Git. Unfortunately we weren’t able to answer all of the questions in the allotted time, so here are answers for some of the most commonly asked questions.

Q: Can a developer use Git without an AccuRev workspace?

A: Absolutely. With Kando, the developer does not require an AccuRev workspace. Kando uses a native git repository, so developers can use Git with no modifications – it works seamlessly with AccuRev on the backend. It’s all native Git-to-Git.

Q: Is the Git repository limited to a single AccuRev stream, or can it follow most or all of the AccuRev depot?

A: The Git repository is not limited to a single AccuRev stream, it is completely configurable. When you create a repository, by default, it’s going to ask you to map the master branch in that Git repository to a stream in AccuRev, but you can set up multiple mappings. You could map 100s of branches to streams if you wanted to.

Q: Let’s say I’m an integration manager for a project. Can I create a Git repo using Kando, Git clone it on my system, and let other users clone from me?

A: You can certainly use that model if that’s how you’re most comfortable, where you clone from the bare Git repository associated with AccuRev, and then other people can clone from you. There’s nothing to preclude that from happening because it’s normal Git-to-Git. Another possible solution would be to have all of your developers push and pull from the Kando repository, then you could merge those changes up to the QA or Master branch using AccuRev or Git if you prefer. Kando supports both models.

Q: What about integration with code review tools (like Gerrit).  We actually use Gerrit as the centralized control for our Git repositories

A: If you are connecting Git to anything, whether it be Gerrit, GitHub, an open source library, etc., everything will work. Because Kando is reliant on Git working natively, you can connect to Gerrit or any other tool that integrates with Git. You can push and pull from Gerrit and GitHub as normal. When you push to the remote that is associated with Kando, which is connected with AccuRev, those changes end up in AccuRev in the stream that you’ve mapped to the Git repository’s branches.

Q: How do you handle bugs in Kando itself? Is there support?

A: Kando is an officially supported AccuRev product. If there are defects in Kando, they’ll be handled through our support and services organization the same as they would with AccuRev. Kando is developed using an Agile development methodology, so as we get feedback on defects and enhancement requests, we will turn around fixes and enhancements as quickly as possible.

Still have questions? Ask below, visit www.accurev.com/kando for more information, or check out the Kando video.

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.