On CollabNet

Guy Martin Empowers DOD's Agile Development in the Cloud

2010-03-20T09:07:42-07:00

At CollabNet, we appreciate that the world understands our contributions to the advancement of practical methods of software development in the cloud. For instance, last month, I traveled to Davos where I met with industry leaders who share our vision and want to improve the world with technology. There, CollabNet was recognized by the World Economic Forum as a Technology Pioneer for leading an industry in transforming the state of software development across entire industries. As a dramatic example of this transformation, I’ve blogged before about CollabNet’s work with the US government to change the way the DoD procures and builds software (www.forge.mil). By inserting collaborative & agile techniques, the DOD could literally save hundreds of millions of dollars and years of schedule off of their current method of procurement for any number of Programs.

As part of forge.mil CollabNet recently received equally gratifying recognition by the outside world - our federal practitioner, Guy Martin, (http://blogs.open.collab.net/oncollabnet/guy-martin/), has been awarded a Federal Computer Week Federal 100 award. Guy will be recognized in Washington DC on March 22nd at the 21^st Annual Federal Awards Dinner for his groundbreaking work with the federal IT community. At this event, Guy and 99 other individuals will be cited as “those whose vision, passion, risk-taking and pioneering spirit have impacted and transformed federal IT. Professionals from government, industry and academia will be honored for their efforts in affecting change, progress and efficiency in determining how the federal government acquires, develops and manages IT.”

Guy’s work with DISA (Rob Vietmeyer, Guy’s DISA counterpart was also honored) and the federal government is a great example of why CollabNet is winning these industry pioneer awards. They have been able to extend the principles of global collaboration and agile development in the cloud that CollabNet has led in the commercial sector into the defense community by working closely with the DISA team on Forge.mil. We applaud Guy for making these inroads that in part are leading to a number of federal initiatives and mandates for open source and agile software development. For instance, Forge.mil was one of the precursors that helped inform Congress when they worked on the technology language in the National Defense Authorization Act for Fiscal Year 2010, also known as HR2647. Specifically section 804 of this bill directs the Secretary of Defense to devise a more 'Agile and Collaborative' technology acquisition methodology, asking the DOD to design a new process that essentially describes agile development in the cloud :

• early and continual involvement of the user;

• multiple, rapidly executed increments or releases of capability;

• early, successive prototyping to support an evolutionary approach; and

• a modular, open-systems approach.

This is, of course, right in line with the CollabNet based Forge.mil set of capabilities. If you want to know more about forge.mil, and how to get involved, please let us know.

Go Green, Go Remote - But How?

2010-03-18T15:04:44-07:00

No matter what your opinion is on global warming, it's clear that we need to get off our dependencies on fossil fuels. Everyone needs to put forth effort to go green, including companies and how they manage the employee work processes.

Over the years I have commuted long hours and I have worked remotely. Working remotely has obvious green benefits by saving on gas and emissions, providing more hours in the day that are not devoted to cursing out other drivers, and lends to a better personal balance of home and career. Yet, in talking to folks in various online communities and in person, I come across some resistance to working and running a business remotely.

Some resistance is based on fears of doing things slightly differently. I stress slightly here because the changes in one's work day isn't that different than from the office, except for some distinct benefits. And habits are hard to break when it comes to certain routines. The most common resistance to avoiding working remotely though is simple lack of knowledge of how the remote model works.

The software development industry has provided a great model for working remotely, yet many, many people are still in their cubes, pounding away at the keyboard when they could be kicking back in an easy chair with their laptop. Instead, from their desk, they pass emails, instant messages, use the phone, and only on occasion, do they leave the uncomfortable desk. Why? All the work is being done in a somewhat distributed fashion anyway, and certain tools can make it all the easier.

I'm currently working two days in the office and the other three I remotely from home. This gives me just the right amount of face-to-face with key people I work with, and the rest of the time I am happy to be off the road and have the extra time in my day. For my job, it's a comfortable balance.

The key to successfully working remotely is collaboration. The software development industry helps us in heaps here. For a long while now, teams have been distributed throughout the country and globally. Companies like CollabNet make working remotely with distributed teams easier by providing a platform (TeamForge) with all the tools necessary. We can have discussions, share wikis and documents, and track each others progress on projects or tasks.

Of course, some face-time is necessary, discussions sometimes are better in person, and it's good for team morale to have a face to attach to an email address.

And in my experience, meetings, especially large ones, are more productive and clip along at a better pace when people are remote. In person, I've noticed some time is spent on arranging chairs, getting a projector to work, chit-chat to catch up with people, etc. before the meeting even starts.

But when folks call into a meeting remotely, or use something like WebEx or Go Meeting, people tend to be ready and get right to the point. There is less time wasted, and gabbing is saved for during technical glitches, which do happen no matter whether you are remote or live, or when in person meetings come along.

The key to working remotely successfully is collaboration, having the right tools for employees to connect with each other and share data, and to track progress, and to understand that remote working does NOT hamper progress or work quality. Less office and cube space is needed for employees, less time is wasted on travel and commuting, and people's attitudes tend to be better when they have enough home time. By only meeting in person once or twice a week, it becomes a treat to get out of the house and out into the world.

We have the technology to work remotely and collaboratively, and distributed software teams have provided an excellent model for those of us who are not crunching code daily but do work on a computer the majority of the time. Of course, there are jobs that just have to be in person and don't fit this model. But so, so many jobs are ideal for working remotely, and I hope to see more businesses taking advantage of going green for the planet and all living on it.

I am grateful for my online job, and the fact that I work for a company who provides an ideal platform for distributed teams, including non-developers like myself, to collaborate with the rest of the company. Because CollabNet was founded on creating tools just for collaboration, the mind set was already there to work with employees in a distributed fashion. But your company does not have to develop a software development environment in order for you to work remotely.

I'm curious, if you don't work remotely, but work on a computer most of the day, what prohibits you from working remotely?

AnkhSVN and Visual Studio Interactions

2010-03-16T04:54:00-07:00

This blog describes differences between Microsoft Visual Studio (VS) and Subversion (SVN)

project structures and usage of AnkhSVN ( A Subversion plug-in to VS) with Visual Studio.

It further explains branch/merge scenarios with some examples.

At first, let's distinguish between a Visual Studio (VS) project and a Subversion (SVN ) project.

A SVN project is a folder. A VS project is a group of files that produces a single binary target

(dll, exe, lib). A VS studio project is analogous, but not identical to a makefile.

A VS solution on the other hand is merely a grouping of related VS projects, it has no concept

of a build target. VS creates a solution for every project, but you can also create solutions

ad-hoc, and add projects to them. Frequently, a VS project belongs to two or more VS solutions.

Further, developers frequently create VS solutions locally on their machines as part of the

development and debugging process, but these solutions are "throw aways" which don’t

get checked in.

A SVN project has sub-folders for 'trunk', 'branches', and 'tags'..

For instance, if we have the following working folder structure;

C:\MyProjects\TutorialSvn\MyLibrary

MyLibrary.sln

MyLibrary.csproj

MyApplicationClass.cs

In SVN, the folder structure would look like this;

/TutorialSvn/MyLibrary/
    trunk/
        MyLibrary.sln
        MyLibrary.csproj
        MyApplicationClass.cs

If we branch the solution from within VS, call the branch 'development', and commit it,

this is what SVN looks like:

/TutorialSvn/MyLibrary/
    trunk/
        MyLibrary.sln
        MyLibrary.csproj
        MyApplicationClass.cs
    branches/development/
        MyLibrary.sln
        MyLibrary.csproj
        MyApplicationClass.cs

Switching between 'trunk' and 'development' causes SVN to replace the contents of the

working folder (i.e. MyLibrary) with the appropriate branch. The working folder does not

mirror the SVN repository's structure. Instead, the working folder's contents get wiped out and

replaced with the contents of either trunk/ or branches/development/, depending on which branch

you 'switch to'.

Now suppose we have a test harness (console executable) that exercises MyLibrary.dll.

We may want a new solution to host both VS projects, and a working folder structure that looks

like this;

C:\MyProjects\TutorialSvn\
    TutorialSvn.sln
    MyLibraryTestHarness\
        MyLibraryTestHarness.sln
        MyLibraryTestHarness.csproj
        HarnessProgram.cs
    MyLibrary\
        MyLibrary.sln
        MyLibrary.csproj
        MyApplicationClass.cs

In the above example, MyLibrary.csproj is included in two different solutions;

MyLibrary.sln and TutorialSvn.sln.

Likewise MyLibraryTestHarness is included in two different solutions.

I may want to branch MyLibrary.csproj without branching the test harness. Since SVN "switch"

occurs in-place, the project references in TutorialSvn.sln will remain correct regardless of

whether MyLibrary has been switched to 'trunk' or to 'development'. Same thing goes for any

references from the test harness project to the library project.

Merging is a whole different discussion which requires you to wrap your head around the

concepts "merge from" and "merge to", the rules of which can be quite counter-intuitive at first.

But once the rules 'click', they make sense.

Steps to create merge scenarios:

1. create a new project

2. branch it

3. edit the branched copy

4. merge the branch back into the trunk

5. edit the trunk

6. edit the branch

7. bring the branch up-to-date with changes in the trunk by merging the trunk back into the branch

8. merge the now up-to-date branch back into the trunk

Government 2.0 From the Inside Out...

2010-03-15T16:22:28-07:00

There is a LOT of effort being spent by the United States government to increase transparency to the taxpayers. In general, there are some great efforts (such as data.gov and usa.gov), and I think we should continue pushing the edge of the envelope in citizen participation with government. However, I believe we have a MUCH bigger problem to solve to get us to 'Government 2.0' - encouraging/cajoling government agencies into collaborating amongst themselves first. Impossible you say? Maybe so, but without effort focused on this goal, no amount of external transparency will have lasting success. Is there a magic formula or tool to accomplish this?

Short answer: No. More detailed answer: No, but proper application of tools such as wikis, discussion forums, centralized document management, application lifecycle methodology, and social media features can provide a way forward. However, the key critical aspect at the end of the day is community (yes, why should this be a surprise, coming from the community management consultant? :)). Without an approach that factors in how the internal cultures and communities operate within the government, any hope of meaningful citizen participation is pretty much non-existent.

The recently announced Open Government Directive is the 'stick' being used to drive intra-agency collaborative efforts (as well as external transparency). However, most of the time, applying only the stick results in a 'checkbox' approach to any task - doing the bare minimum. Lena Trudeau hits the nail on the head in her recent blog post at Federal Computer Week when she writes:

"Collaboration is a path to achieving results. Rather than focusing on simply achieving compliance with the Open Government Directive by checking the box on collaboration, agencies have a great opportunity to identify a real problem and use collaboration to solve it."

Given that humans are not naturally altruistic, my oft-stated commentary on WIIFM also applies here - do agencies who agree to share data/technology and cooperate get bigger budgets, bonuses, or some other form of prestige by doing the right thing by the new Open Government Directive? It would be great if they did these things because it was better for the average citizen, but that's unlikely to happen. Identifying a tangible problem to solve, as well as what's in it for the respective agencies, can help provide the 'carrot' to help mitigate the sometimes detrimental effects of the 'stick'.

Without fostering 'communication' (read: community) among the various agencies, any chance of producing coherent and reasonable transparency to the taxpayers on the outside of the system is doomed to failure. I've often wondered if we are close to a tipping point in terms of government employees who grew up in a more 'collaborative' time, with the internet, open source, social media, and the ease of working with each other. Will the rigidity sometimes foisted upon (or required of) new 'govies' quash their innate desire to collaborate effectively?

One way to address this is to change the way problems are thought of and how people are incentivized to solve them. We need more people like Vivek Kundra (USA CIO) and General Jeffrey Sorenson (US Army CIO) (both fellow Fed 100 award winners for 2010) to sponsor projects like Apps for Democracy and Apps for Army, which, through small changes, start to tear chinks out of the traditional way that 'app development' and collaboration are thought of, both inside and outside of the government. They also start to encourage a level of cross-collaboration that fundamentally changes the way people within government talk to each other.

Focusing on cultural changes is something Andrea DeMaio commented on in a recent blog post on the Gartner Blog Network about how technology has become too much of the focus in Government 2.0:

"...it has always been easier to say 'let’s buy a new tool' than to reflect about deeper process and cultural changes. Finally, on a topic that is new to most people, with boundaries that are quite unclear, it is easier and somewhat more comfortable to be able to point to a new tool or a new functionality, something distinct from what one has been doing so far, as a way to tick a box in a compliance exercise."

Can we all see a theme here on the 'compliance exercise' bit? I agree with all of his points (even grudgingly realizing that there needs to be some strategic direction change not coming from the technologists). Honestly, I think we need to look to successful open source projects and their use of community, meritocracy, and cultural models that are largely tool agnostic (though some would argue that distributed vs. centralized version control is a holy war!) Successful open source and/or Agile development communities exhibit characteristics that generally encourage and reward internal collaboration and involvement of all stakeholders in the process (outside users are represented by requests for enhancements and community leaders)

All of this causes me to wonder - given the rise of the 'social media/collaborative' generation, how long do you think it will be before this 'new breed' starts to influence the way government interacts with itself? More importantly, will the government culture remain long after the current generation of govvies is gone, and will that get in the way of the new generation, or flat out discourage them from entering public service in the first place? If we hope to achieve even half of what we are being promised in a 'Gov2.0 Nirvana', we are going to have to solve the 'internal government 2.0' puzzle first. I'm very curious as to what you, the readers, think is necessary to spur the move to 'Government 2.0' within federal agencies. Please feel free to leave me your thoughts here...

The Benefits of Eating Your Own Pet Food

2010-03-12T13:13:42-08:00

Many of us have come across companies trying to sell a product that they themselves don't use, because unfortunately this is not uncommon.

It's unsettling when companies don't think enough of their own products to actually use them. I understand not all companies can use their own products within the business because of the nature of some products. But, by and large, many, if not most, can be integrated into the business. And should be when they can.

That was one of the things I really liked about CollabNet. We actually do use our own platform and tools, and in a variety of ways. Yes, we eat our own pet food, and that has many benefits:

You discover the strengths and weaknesses of your product
You are better able to help customers understand the product and why they should use it
As your needs grow, you build those solutions into the product, giving you much better empathetic understanding with the customers
Everyone benefits from the companies product, because everyone makes requests to improve its quality

The CollabNet platform has evolved greatly over the years, and we have used all iterations of it along the way. The CollabNet site resides on the platform, as do all of OCN projects, and all of our internal projects.

For instance, our group of community managers use a CollabNet TeamForge (CTF) project called community-management. Having this project allows us to share documents, use a wiki to share links and miscellaneous stuff, and have discussion areas we can use to help and advise one another, brainstorm, and discuss various topics of interest. Monitoring enables us to receive changes and discussions via email.

I set up a similar project for CollabNet bloggers. With 16 of us, and growing, it's just a pain to email, attach documents, track changes to those docs, etc. through the mail program. This CTF project allows us to do that and more. If we want to set up trackers and project folders, we have that available to us as well.

In addition our web production team, marketing, sales, etc. all also use our platform similarly. And, of course, so does our engineering team. They use it for their development of CollabNet platform and tools.

Recently, with the acquisition of Danube, we'll incorporate more Agile processes and scrum into our work flow. CTF was always Agile-ready, but now we'll be using it more and learning scrum for our own business tasks. It's exciting to have the product evolve in a way that is not only useful to our customers, but to us as well.

Eating your own pet food, or rather using your own products, adds empathic understanding to customer needs, but also adds a great amount of sincerity and enthusiasm, assuming you have a good product. When a company uses it's own product or platform, that product is bound to improve because there is more invested in the quality of that product.

Platform Integration versus “Marketecture”

2010-03-04T13:22:00-08:00

The reaction to CollabNet's acquisition of Danube in the press last week was extremely favorable. The market and our customers understand our vision and the rationale for this exciting merger. It’s great to see. Last week, an Agile industry press expert asked me, “How does [CollabNet’s] merger of ALM and Agile leaders compare to the recent marketecture announcement of Company X, Y, and Z”? These were his words, not mine. (For obvious reasons, I have removed the references to the other companies this expert mentioned to me.)

In my mind, this raised an age old question that has lived on forever in the tools and applications industry-- Is it better to deploy an integrated platform suite or a combination of loose tool integrations that may be optimized for specific use cases? Clearly, there are pros and cons to both positions. But from my experience, the architecture that consistently wins in the industry is a “just broad enough platform with an open set of APIs to allow the integration of best-of-breed point tools used by the multiple stakeholders to collaborate in that platform”. For modern examples, look no further than FaceBook and Salesforce.com.

So what was my response to the analyst’s question?

In summary, CollabNet’s acquisition of Danube brings together, from a single vendor, (1) World-class Agile Scrum management and expertise proven to scale from the workgroup to the enterprise, and (2) a rich application lifecycle management solution built on a cloud-based collaborative architecture already used to power some of the largest and most respected developer communities in private industry and government. This synergy is impossible for any loose combination of tools and architectures supplied via companies partnering with each other. The CollabNet/Danube offering has three clear advantages over loosely integrated entrants in the market:

1.       Strength of ALM Tool Integration –TeamForge is by far the industry’s most integrated end-to-end ALM platform for enabling collaboration. The platform encompasses all of the stakeholders of the software lifecycle from “requirements through release” for a variety of processes and technology implementation choices. It is architected as a uniquely integrated platform enabling security, process modeling and tool interaction, which is just not possible with a loosely connected set of multi-vendor tools. In addition, this includes not just ALM software development capabilities, but also a rich collaboration platform and community architecture that uniquely allows companies to define their ALM methods(s) and subsequently scale them from the workgroup to the enterprise. And of course, TeamForge is a 100% cloud enabled architecture containing a rich set of APIs to connect to a user’s favorite point tools anywhere on the planet. It is for this combination of reasons that our customers claim 10-50% design productivity at 1/5 the cost of the implementation of these multi-vendor-supplied collections of tools.

2.       Single Vendor Solution for Agile Management and Agile ALM –CollabNet alone provides the security and commitment as a single vendor for Agile project and program management as well as distributed ALM in the Cloud. CollabNet intends to offer the ScrumWorks tools in both a stand alone mode, as well as an increasingly integrated extension to TeamForge. We are already showing early integrations to the market. If you’d like to see it, please let me know.

3.       Thought Leadership – For the past 10 years, CollabNet and Danube have both established thought leadership in the practical application the entire range of software methods – from collaborative SCM to distributed ALM to Scrum. As examples:

CollabNet founded and continues to drive Subversion, the largest and most successful open source version control system used in the enterprise (by 15-20x over the next largest open source versioning tool). We also pioneered the cloud based software collaboration methods that were critical in forming the largest internal and external developer communities in the world.

Danube has the largest number of on-staff Certified Scrum Trainers in the World. Via ScrumCORE, Danube has trained more Scrum Masters than any other organization and they continue to be highly visible and prolific in publishing materials on Scrum best practices.

The above is a strong position for me to take. But our clients proven results are impressive, and they back my statements up. It is uniquely this marriage of Scrum management and CollabNet’s globally distributed Agile ALM development platform that enables reductions in release cycles by as much as 75%, as demonstrated by this public article published by DST. Development gains resulting from the use of a unified development platform are almost impossible to achieve using the alternative method -- a loose combination of easily available tools and architectures of home grown, open source, and vendor-supplied point tools. Resulting incompatible databases and data formats, inconsistent processes and tool configurations, and overall support costs render the move to a unified environment to gain this organizational efficiency very difficult, at best. Development teams and CIOs increasingly understand this differentiation, which is helping to drive CollabNet’s acceleration into the market.

It’s an exciting time for software development.

Drilling down into your site's usage

2010-02-24T18:05:35-08:00

How can you understand how your CollabNet site is really being used? This simple question has many implications but few answers.

Generic web monitoring tools can do their generic best, but they don't know anything about the structure of your CollabNet site and the CollabNet product: projects, components, and actions are all key to how you use the site, but opaque to generic tools. They're not integrated.

On the other hand, tools based on inserting code snippets into your pages really demand that you already understand what's important. Too often, they can appear to confirm your theories--but only because you didn't know enough to ask the right questions. They're not exploratory.

We have a tool suite on our community site, called "CollabNet Apache Stats," or CollabaStats, that makes some attempt to be better integrated than web monitoring tools, while still preserving the exploratory power to shake you out of unexamined assumptions. CollabaStats is a log-analysis tool focused on the Apache HTTPD logs, but with extra understanding of how the CollabNet site software works.

The project website contains a wiki that guides you through setting up the data capture and insertion into a database. (Currently, CollabaStats requires a MySQL database.) Be sure to look over the Requirements information: such a database can be quite demanding, depending on your site's traffic levels and the amount of history you try to analyze.

To see the actual files of the project, you'll need to log in to the site.

The Source Code repository for the project is structured as an Eclipse BIRT workspace, to help you design reports to explore your site behavior. There are a dozen or so report templates there that you can use and modify, and pre-digested examples of their reports, so you can see some of the possibilities:

Active Projects based on page views: template and report
Active Projects based on Subversion use: template and report
Most-used CollabNet components: template and report

This is a community project: you can participate. There are discussion fora where you can ask questions and (once you've gained some experience) provide answers. There's a Tracker for reporting bugs, requesting enhancements, and finding ways to contribute. And if you want to make significant code, documentation, or sample-report contributions, contact the Project Administrator (listed on the Project Home page) about becoming a project member.

It's a community: the project, the process, and the source are open to you. Because that's the Open Source way.

Welcoming Danube into the CollabNet Family

2010-02-23T16:36:32-08:00

By now, I'm sure most readers of this blog have seen the announcement of CollabNet's acquisition of Danube Technologies, Inc. Our CEO, Bill Portelli, posted a blog entry here yesterday addressing the strategic reasons behind the acquisition, but I wanted to write a note to welcome Danube into the CollabNet team, and talk a little bit about how I think they will make our services offerings stronger.

In its coverage of the announcement, Forrester Research penned a great blog post with a lot of details of why they think this is a key acquisition in the Agile ALM space. While there will be forthcoming discussions of how the CollabNet TeamForge and ScrumWorks products will be integrated, I'd like to focus on another area that Forrester called out in their blog:

"One of Collabnet’s largest implementations is the Forge.mil site which provides a community oriented development space for defense projects to share development assets. Increasingly these projects are looking to adopt Agile methods, but in a controlled and distributed way. The result of Collabnet’s acquisition of Danube is a large amount of Scrum best practice [which] will slowly percolate into this community."

This is a key and fundamental strength this acquisition brings to the CollabNet services portfolio. Danube has an awesome array of talented Scrum Trainers and consultants that will be able to bring solid experience in explaining the details of how to take advantage of all that Agile development has to offer. Where I'm most excited is in how that combination of 'how to do Agile' intersects with CollabNet's own community management consulting practice. A lot of what we do in the community consulting area is about explaining the 'why' of new methodologies such as Agile. Having our new Danube colleagues on board to help us deep dive into the 'how' of Agile will undoubtedly help us as we start to engage additional teams both within and outside of the DoD.

Forrester is absolutely correct that in the DoD space, the move to Agile is all about doing this in a controlled manner that makes sense. There is a long established culture in the department that doesn't exactly embrace this 'new-fangled' way of doing things. Thankfully, the experience of building out Forge.mil has proven that amazing things can happen (180 days to launch initial revision of software.forge.mil) if you apply Agile principles to new projects in the DoD space. With that being said, we've had to build out a 'hybrid-Agile' approach in this space, to account for certain 'back-end' processes like Change Control Boards (CCBs), but we are still moving the department forward and saving taxpayer money in the form of reduced redundant efforts.

I look forward to working with my new colleagues in the services space, and would love to hear from any readers on what kinds of things you'd like to see the combined talents of the community consultants and Scrum Trainers take on. Hopefully, we'll be able to integrate the Danube blogs into this space soon so that we can continue to drive these discussions forward...

CollabNet TeamForge + ScrumWorks: A significant step in merging the disciplines of Agile Management and ALM

2010-02-22T16:37:55-08:00

Great news for the software development community! Today CollabNet announced our acquisition of Danube, the leader in Agile/Scrum management software tools, consulting, and training. Their ScrumWorks solutions have defined the standard for enterprise Agile/Scrum project and program management.

For the past 10 years, CollabNet and Danube have both proven themselves to be thought leaders in the practical application of the entire range of software methods – from collaborative SCM to distributed ALM to Scrum. CollabNet founded and continues to drive Subversion, the largest and most successful open source version control system used in the enterprise. We also provide the tools and the software collaboration methodology services that power the largest internal and external developer communities. In addition, Danube has the largest number of on-staff Certified Scrum Trainers in the world. Via ScrumCORE, Danube has trained more Scrum Masters than any other organization (6,500) and they continue to be highly visible and prolific in publishing Scrum best practices.

Now, this acquisition defines another major step for the market, and is recognized as such by industry analysts including Forrester,

“With this acquisition, CollabNet has taken a significant step in merging the disciplines of Agile project and portfolio management with ALM.”

CollabNet customers will now have access to ScrumWorks, the leading Scrum project management tool, and an impressive team of certified Scrum trainers. Meanwhile, Danube customers can now enhance their Scrum processes using CollabNet’s distributed ALM tools and knowledge.

CollabNet will continue to support heterogeneous development environments and allow you to work with your development technologies and methods of choice, whether waterfall, iterative, or Agile. At the same time, we’ll now be able to provide additional expertise around Scrum, the most popular framework for managing product development commonly used with agile software development. The bottom line is that CollabNet will allow you to bring best-in-class scrum project/program management tools and processes into your organization, but at a pace that makes sense for the individual business needs of each project.

CollabNet is thrilled to welcome Laszlo and Victor Szalvay, cofounders of Danube, and their skilled team to the CollabNet family. We plan to invest deeply in the ScrumWorks products and ScrumCORE services as Agile and Scrum are such significant components of the future of software development. ScrumWorks and TeamForge will continue to be supported as separate products, but will also be available as a bundle. Increasingly, we will deepen the integration of the two product lines, with the first release available to the market in the Q2 timeframe.

We are extremely excited that CollabNet’s acquisition of Danube brings together, from a single vendor, (1) World-class Agile Scrum management and expertise proven to scale from the workgroup to the enterprise, and (2) Robust application lifecycle management built on a collaborative architecture already used to power some of the largest and most respected developer communities in private industry and government. This synergy is impossible for any other loose combination of tools and architectures supplied via companies partnering with each other.

If you’d like more information on our products, this acquisition, and our plans for integration, please join us for a webinar on March 16, 2010: http://www.collab.net/webinar/56/index.html

I hope our enthusiasm and optimism about the future of Agile ALM in the Cloud energizes and inspires you. As CollabNet leads the way in this space, we value your feedback and input in order to improve our products and help you succeed. I invite you to share your thoughts, concerns, and questions.

Hold On

2010-02-19T09:06:40-08:00

The amount of control a community has over process and direction within a project has recently come up in a situation I've been involved with and I think it's a great topic for a post since it strikes at the heart of many company's trials and tribulations in creating vibrant communities. The real question in these situations is not one of control but of trust. Can you just be along for the ride and let someone else influence your project even if you don't agree with everything they do?

Many organizations and people find it difficult to let go and allow their communities to shape the overall direction and goals of their projects. They fear that by allowing users to get involved at a deeper level chaos will ensue and they'll be mired in endless debate over what they perceive as insignificant issues. However, the opposite of control is not chaos, the opposite of control is trust. Trust that you're not the only one who has good ideas. Trust that even if it doesn't follow your established processes it might be okay. Trust that, you don't know everything!

This lack of trust is one of the biggest reasons your community is not growing and it's not a lack of trust in your project (well maybe it is ;), it's that you don't trust your community! This is especially common in enterprises that have well established processes or in any company that maintains a title of Senior Vice President of anything:). In larger organizations that have worked hard to develop processes for product development, marketing, and sales, it's hard to find someone in command willing to allow control to slip through their fingertips and into the community and shape their baby in some way they don't agree with or that their processes can't handle. But that's what it takes to grow your brand and community, hopping on and letting your community take you where it wants to go.

One of the best books I read in all of 2009 was Brand Hijack by Alex Wipperfurth. In it he details the making of many brands that allowed themselves to be hijacked by their communities to become successes: Dr Marten, PBS (Pabst Blue Ribbon not the broadcasting service:), Red Bull, and others. All of these brands did something unique, instead of trying to define themselves in a traditional marketing sense, they let their fans influence and define the brand. And that's what you need to do in order to grow your fan base... let go.

Don't confuse letting go with abandoning all your processes, my point is not to let your community suddenly start running everything without any leadership from you. The point I'm trying to make is you need to stop trying to control EVERYTHING. Pick your battles and arm yourself with good arguments. Don't use coercion due to your position or ignore your communities input, use your communication channels to guide your community during those times when you see it straying from the path. Having this blend of give and take will allow your community to feel a sense of ownership and ... start prospering.