Last week I discussed how IT groups of all sizes can benefit from Agile Methodology—even in dispersed, tiny organizations. I described what could be considered a nightmare situation in my previous post , and today I want to show you the light at the end of the tunnel.
HP recently released Agile Manager software as a service to provide Agile Methodology globally for small to medium businesses—for less than the cost of the slush fund I discussed in the last post. Software as a Service (SaaS) is a proven, lean software-development process with one of the best-known application lifecycle management platforms on the market today. SaaS has come to the rescue for small- to medium-sized IT teams, let’s take a closer look and see what it can do for you.
Thinking out loud in the cloud—the good
If I could point to one single item in the Agile Methodology that makes it so attractive is the ability to think or talk through issues with peers/team members. This is especially helpful when you are working down in the trenches. This flow of information can eliminate any type of delays or miscommunications at any layer of the business. Communication is paramount to team success.
If the key communication dynamic is not carefully managed trouble can ensue. A cooperative effort based on team work can quickly turn from a Gilligan’s Island scenario—which any problem could be solved within 30 minutes or less—to instead resembling William Golding’s “Lord of the Flies”. It doesn’t matter if it is a consolidated or distributed agile environment, this dynamic can be managed and even enhanced with real-time reporting and communications. This can be improved with leveraging on-demand documentation, design and several other types of artifacts within the integrated environment.
Set up time for distributed team—the bad
One of the most frustrating items for any person creating distributed teams is getting everyone access to the environments and tools they need to be successful. I think the ulcers of most project managers can be traced back to the relentless effort needed to have external resources gain access to internal tools and email. Alleviate a lot of these small roadblocks that tend to eat up precious time and qualified team leaders with tools like Agile Manager implemented as a software as a service.
I think that accountability of the tool in service directly correlates with the success of an individual project. Instead of having a small to medium-sized company heavily invest in a tool that also requires an internal support structure, these same companies can lease tools like Agile Manager as a service, and remove all the overhead of supporting and managing such a large investment. They can look at tools as just another part of a project success or failure criteria not to mention a tax break.
Motivating and training teams as well as individuals—the ugly
I just recently read about Lance Armstrong losing his Tour de France titles because of his use of performance-enhancing drugs. The use of these substances is wrong, right? The truth of the matter is that most of the managers, project managers, and scrum masters I know would gladly feed their teams cups of fruit cocktail full of performance or motivational drugs if it improved their performance.
On the other hand, if I asked developers, analysts, testers or anyone involved in the software development lifecycle they would pass up the performance substance. They would all say the same thing, which is “give me the tools to be successful”. Agile environments can sometimes be highly motivational because they play on human nature: both the competitiveness between us and our desire for social interaction. A lot of times this motivation is reflected in the weekly meetings and in the Agile environment when reviewing burn down graphs. These graphs are magic. I believe that Agile Manager has tapped into the motivational properties of real-time graphs and the reporting progress of projects, teams and most importantly, individuals.
The other side of the coin is the length of time it takes someone to be trained properly in the Agile methodology. There’s two distinct philosophies when it comes to training of agile team members:
- Train everybody up front even if it eats up one or two sprints. This is very time-consuming, but in the long term everybody seems to be on the same page.
- The most common method of training is what I refer to as “train as you go”. This allows the teams to engage in designing, developing and testing software almost immediately. Unfortunately, most untrained individuals find this frustrating because they feel the Agile team leader is holding back and making changes as needed or modifying rules as they go.
My favorite part of the “Matrix” is where Neo simply downloads the concepts of karate and becomes an expert. With this in mind, we now have a third option. Take a day, train your team on the tool that will guide them from the beginning to the end in the Agile process. In other words, you build the tool (or the pill) to your agile specifications and allow the tool’s workflow to guide inexperienced users through the process (since instantaneous knowledge isn’t available—yet).
Weighing interaction and processes
Most Agile enthusiasts stumble over the statement “individual interaction over processor or tools” when looking at platforms such as Agile manager. I believe this statement has been taken out of context or misunderstood by the computer illiterate.
Any platform on the Agile Methodology in a distributed resource environment should be construed as a leap forward from notecards, whiteboards, and Microsoft Excel spreadsheets. You just have to remember is long as you don’t lose focus on developing software/applications that communication and especially documentation that interactions is a good thing.
Imagine how Agile can revolutionize your IT environment, especially if you are in a small- or medium-sized business. Are you planning to start a new project using the agile process this year? I’d like to hear some of your ideas implementing agile for large project in a small environment?