Hear the term Agile Development and you may have a very specific image pop into your head. A room full of (mostly) 30-something men in jeans staring at their monitors as their fingers fly across the keyboards and Red Bull litters the floor. Maybe I’m too swayed by mainstream television and limited personal experience, but that’s what I picture.
The raw idea of Agile is simple and not wholly original: fail fast. A goal is set, and then sprints are timed out to keep everyone on track. Daily or weekly meetings allow all stakeholders, both IT and LOB, to assess what is working and what isn’t. The last bit is what truly makes it an Agile process though; based on the assessment the team actually pivots to ensure they are on track to complete the project and do their best work. This could mean throwing out an entire week’s worth of work or lengthening timelines to ensure things are done well and best fit the consumers’ needs. The workplace becomes high energy, charged with the desire to do things right the first time while still being able to experiment with ideas a week at a time.
Agile Development has proliferated the world of the coder. The process fits software well because beta versions of an application can be continuously rolled out to end users and feedback can be elicited. Working Agile in less technical environments, however, is less common. Especially in an age when knowledge and process are high commodities, this technique can be easily applied to a number of LOB work environments.
In my (admittedly short) experience I have seen what I would call pseudo-Agile attempts outside of software development. Intentions going into a project are optimistic and the small group is energetic. Inevitably what ends up happening, though, is human traits get in the way of achieving the goal. An ego thinks a task beneath him, or an eager participant overstates their skills or other tasks are given priority for no reason other than personal preference. Some very human problem bubbles to the surface and soon all that enthusiasm has evaporated leaving the team to stew in frustration.
In my opinion this comes down to one key variable: Action, or lack thereof. To fail fast one must be able to fail at all, and to fail one must first act. Make a decision. It seems where software is concerned decisions are more prevalent and accessed more easily. Decisions in more human businesses (HR, consulting, management, finance, etc.) seem so much harder to come by. This could be for a number of reasons. Those responsible for making decisions may have been taught failing is bad, and therefore they’re trying to reach perfection on the first go. The decision maker may be overworked and overstressed. Hierarchy may create a silo in the decision-making process.
There are a lot of reason for not making timely, Agile decisions. There is only way to fix it though, and that is for you to start acting. Don’t schedule another meeting to talk about what the group can maybe do next week, and definitely don’t complain and complain and complain. All businesses can become Agile, and grow tremendously in the process. You just have to act.
I hope you enjoyed my first opinion piece. While I am away from my precious microphone this will be my primary source of contact. Comment at will, subscribe on Google Play, follow on Twitter @AmandaDarc_ and connect on LinkedIn.