Background
It had only been two days since I left Saflink … a small-sized software company, working within an enthusiastic, agile project group in Seattle Washington … to a large, bureaucratic, development team working on a government contract in Edmonton Alberta – and the differences were already starting to wear on me.

Before I continue, I feel the need to state my intended purpose for writing this blog. While I do admit a certain amount of spite and malcontent (and I’m sure this will become obvious), I do not intend to speak ill of plan-driven environments and their effectiveness – I’d be foolish to think that these methodologies are not needed in certain scenarios such as large, governmental, highly formalized projects. However, I do believe there are many lessons to be learned and practices to be adopted from the agile startup world that could benefit these top heavy projects. Having a background … and what I like to refer to as a startup mind … I am constantly seeking ways to infiltrate the seemingly impenetrable wall of process definition, best practices, and documentation with injections of agile practices. The intended purpose of this original blog is to define these two environments. Further blog contributions will discuss ways in which I (and hopefully others) have effectively instilled agile methodologies within a process-driven environment.

The agile culture
Instead of going to great lengths describing the previous agile, startup environment I worked in, I will attempt to summarize briefly. Our small project team was proud, passionate, and had ownership and belief in the product that we were building. We were small, adaptable and not bound by procedures and best practices. Each team member was not defined by their role (as a matter of fact, we avoided using words like project managers, developers, testers) however we were expected and trusted to do whatever work was necessary to succeed. This included seeking common or unnoticed tasks and completing them. Side effects of such a culture were long hours, hard work, innovation, new technologies, team lunches, playstation sessions, over the shoulder code reviews and troubleshooting, ad-hoc collaboration, outside the box thinking, and a lot of progress towards our end goal.

The plan-driven culture
In contrast, the environment which I have been immersed in recently is a plan-driven culture. People feel comfortable and empowered only when there are clear policies and procedures (and a document) defining their roles. Their work is done when their current task can be ticked off on a spreadsheet. As a matter of fact, you are discouraged from starting up a new task until given direct instructions (in the form of a new task in a gant chart). Developers (who insist on being referred to as “analysts”) are instructed (only by project managers) on exactly what to build and exactly how long they have to do it. I often reflect on a comment made by a project manager – “Our goal is to define the software to such a degree, that we can hand off the specification document and developers can simply *puke* out code”. While this would be about enough to cause any believer in agile practices to jump off the 10th floor, I have tried (unsuccessfully however) to believe that the nature of some projects (such as ours) require such definition and precision. After all, developers … er I mean analysts here … don’t seem to mind this mentality.

Boardrooms outnumber test labs 5 to … well … there are no test labs. This would disgust Vincent Maraia who wrote in “The Build Master” that the success of a software organization can be directly measured by the ratio of computer labs to board rooms.

Finally, the sense of ownership and pride is non-existent. On my first day, my question on how to acquire remote access to the domain was answered by a look of confusion. People simply don’t have an affiliation and a sense of ownership over what is being built.

Removing barriers and applying agile methodologies
Again, I am a strong believer in agile approaches and feel this is where I’m most effective. However, I believe there are some projects that call for more of a structured approach. The challenge is finding the balance between the two … I believe the lessons I have learned from the agile startup environment can be applied to this top heavy process. It is our challenge (as startup minds in slow-down cultures) to cut through the red tape, and fly under the radar in our attempts to speed up (while not undermining) the processes currently in place … and overall, maintain our sanity.