Going Agile

So you’ve gone Agile – How is that working for you?

With increased exposure, many organizations are trying to become more “Agile”. But what does that mean exactly? How the term “Agile” is interpreted can lead to different processes even within one organization. In many cases, “going Agile” can mean as little as “we will do what we want to do” to “we have no discipline or process whatsoever”. These are extreme cases, however with most organizations legitimately trying to change the way they think about or do software development. For our purposes, let’s assume that “going agile” means we are trying to find a way to develop software that is "better" than what we are doing now, as we try to address organizational pain points.

The more common pain points normally center around speed of delivery, quality of delivery or team maturity. Addressing these issues seems simple enough, most organizations I work with tend to be places where things have gotten to a pain point so great, that they need outside help to assess and determine where things went wrong and what they can do to try to change them. Most of these organizations have had some exposure to the Agile movement, usually through a blog, a book or a person that tried it in their environment. Usually, the initial attempt to “go agile” is a silver bullet approach, with some tools picked and others passed over for what seem to be logical reasons. But inevitably, it seems that a large percentage of these attempts (60-70%) end in something other than addressing the main issue that was being felt and help to surface NEW issues within the organization!

It seems like for this type of change, an organization really needs to consider a helpful third party that has achieved results in a full Agile implementation. Because, as simple as Agile is, the basis for most of the tools is counter-intuitive  And knowing when to change things and when NOT to change them is really the most important skill to bring to the table. But I go too far, let’s start at the beginning and move from there.

A lot of the “failures” encountered with an initial, in-house Agile transformation have to do with expectations and assumptions. It is a fine thing to become educated in the Agile concepts, to try to understand how they piece together to get you the best results. It is quite another to put these pieces in place to get the desired results. Most people who are considering these types of changes are actually extremely smart individuals, and the concepts of most agile processes seem a bit simplistic at first. One of the tendencies that we encounter is that people oversimplify or underestimate the effects of such simple processes, and inadvertently take away tools that are critical before the process even begins. In other cases a lack of understanding in terms of impact and time tends to cloud the water and results in undesired effects. The two most commonly seen types of this failure are the “silver bullet” effect (this simple process will fix EVERYTHING!) and the team loss effect (we are a great team, everyone will LOVE to work with this process!). In both of these scenarios, finding the undesired effects can sour an organization or a team badly enough to result in a re-build exercise, again, without addressing the root cause of the issue.

For us, the most important thing to do is to partner with you and help you understand the breadth and depth of undertaking a truly transformational change to the way you run your business. The changes that are seen in an in depth Agile implementation transcend software development, and reverberate across the organization. Knowing what to expect, how you will be impacted, assessing the risk involved, putting an action plan in place and showing HOW to succeed after we are done are all important parts of what we want to help you with. We want to partner with you, so that education, maturity and success are left with you, and we can be able to help you as you mature with the Agile process.