Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Sep 20, 2010 — Enterprise Agile Planning expert

The Illusion of Control

Enterprise Agile Planning

 

What I’m about to tell you will either: a) scare you to death, or b) make you nod your head violently in agreement. Which reaction you have will depend upon your perspective and position in the software development process. Ready? Here goes:

With few exceptions (Space Shuttle source code, etc.), you do NOT have as much control over the software development process as you think.

I can see those of you in camp ‘A’ above stridently shaking your heads and saying things like ‘but we have tools and processes and even a strict policy of reuse, backed up by a fully documented reuse catalog.’ This thinking provides a comforting (but false) illusion of control, and the reality I’ve learned over almost 20 years in the software industry is that most organizations have software developers who will find ways around the ‘process’ so that they can actually deliver working and valuable code. Organizations who spend a lot of time trying to formalize reuse efforts with catalogs, or who view communities as committees (as described by CollabNet’s CTO Jack Repenning) are quite frankly wasting valuable time delivering the equivalent of the shelf full of 3-inch thick white binders that very few (if any) developers actually read.

I can also see the heads shaking out there now because I work for a company that provides tooling to help accomplish some of the ‘process’ of Application Lifecycle Management. Let me set the record straight – there is nothing wrong with tooling to help you better organize your software development efforts. However, even the best tooling cannot overcome the basic human desire to get past red tape. Those who have read this blog in the past can imagine what I’m going to throw out there as the solution to this dilemma. Yes, that’s right, the oft-uttered and mostly misunderstood notion of ‘community.’

Jack’s post had some wonderful descriptions of community, and I’d only add one small wrinkle to his first comment about why people participate in them:

“Community members are here because they’re interested, not (primarily) because it’s their job.”

Achieving community is not a simple ‘do these 10 steps in order’ kind of an operation. It takes serious thought and a dedicated grass roots effort supported by a willing management structure. Where do tools like CollabNet TeamForge fit into this equation? Tooling is useful once you’ve identified who your stakeholders are in the community and how they work together (if at all). Even then, you sometimes have to adjust the tools to fit your community’s expectations; however the overriding goal of tools should be to help loosely couple the community together, not constrict or control them into an overly formal process that people will look to get out of. This is where having an outside community consultant come in to help jump-start the process can help.

I won’t go into great depth here on Agile as a development methodology (you can read much more in-depth and detailed posts on the subject at the CollabNet Scrum and Agile blog), but I have to say that my experience in the past one and a half years using Agile/Scrum is that it best captures the balance of community involvement with just enough process to keep people organized.

People ask us all the time as CollabNet consultants whether our tool can enforce certain strict processes, or function as a reuse catalog/repository, and while it can do that to a degree, we highly encourage folks to view the tool not as a compliance hammer or a way to develop a virtual shelf full of thick binders no one uses. Instead, look at TeamForge (or any tool for that matter) with a critical eye toward how the collaboration features (wikis, discussion forums, and even trackers) help you foster community while you organize and identify your software assets.

Ultimately, software development should be weighted toward producing useful and working code (part of the Agile manifesto), not reams of documentation to feed the process machine. An organization’s time and money are better spent facilitating community, not building committees, because human nature will lead your good developers to find ways around impediments to getting the job done anyway. It’s much more productive to facilitate and foster that behavior rather than try to fight against it.

[Photo Credit: Crunched.org]

 

More from the Blog

View more
Jul 27, 2021

Digital.ai Becomes First to Achieve FedRAMP Moderate “In Process” Status for Enterprise Agile Planning Solution

Enterprise Agile Planning
Digital.ai, the leading AI-driven DevOps value stream delivery, and ma ...
Read More
Jun 21, 2021

How Agile can be implemented effectively across the organization

Enterprise Agile Planning
Just a few decades ago, a “disruption” was seen as an undesirable thin ...
Read More
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Contact Us