Is your company doing Agile for real?
Or are you only pretending?
It can certainly be effective (as we wrote about in our last article) to introduce Agile to small, self-contained units of your company before adopting it wholesale. However, we have seen numerous companies attempt to adopt the Agile methodology another way: with the company-wide implementation of a software tool. The problem we most often see with this approach is companies mistaking a tool that can be used in an Agile process for the Agile process itself.
Agile is not a software tool; it is a methodology, a way of getting work done. The various software tools that have been developed to support this methodology—while often useful when configured correctly—will not, in and of themselves, deliver the results most companies are looking for when they decide to try Agile, specifically, a faster and more flexible software development cycle.
This is why we say some companies are only pretending to do Agile.
It’s not the tool. It’s how it’s used that counts.
A real life example
A software company had been trying to follow the Agile process for several years but hadn’t seen the results they expected. When they called us in for help, we found a semi-chaotic scene. The company had been using Trac, an open source project management system frequently used in Agile projects. The problem was, the company wasn’t using Trac correctly to support an Agile process.
Part of the problem was the tool itself. Trac has very restricted resources, demanding repetitive and tiring operations on the part of its users. As result, at this particular company, users frequently failed to update the status of their projects in Trac. It was also common to see people working on projects that had not been mapped into the system at all.
Our first priority was to get this company using Agile correctly, so despite its flaws, we did not throw out the tool. Instead, we helped the company use the tool to deploy the Scrum methodology (an Agile framework) for a single project.
Using the company’s existing tool, we:
- Detailed user stories – brief statements written from a user’s point-of-view describing the need for a particular feature.
- Described epics – more complex user stories that can usually be broken down into several smaller stories.
- Planned sprints – well-defined work cycles intended to take a specific amount of time and achieve specific goals.
- Defined tasks – each team member’s responsibilities within a sprint.
- Registered estimates – an assessment of how much effort a task would require.
- And, we made sure statuses were kept up to date.
By using the tool with all the rigor required to do the job right, we were able to impress the company with the results we achieved following the Agile methodology. We were also able to demonstrate the limitations of Trac, and the company has since migrated to JIRA, a much better tool, in our opinion, for implementing the Agile methodology.
Proof of Concept
The example above shows that the most effective way for a company to start out with Agile is not to force a new software tool on its employees without regard for how it’s used. Instead, the best way to transition from a traditional software development process to Agile is to start small.
Try Agile out with a single team working within a larger project. At this point, you don’t need to worry about what software tool the team is using. You can always change that later on. At the beginning, the important thing is to adopt all the critical elements of Agile: user stories, epics, tasks, and so on. Once this small unit has demonstrated the effectiveness of Agile you can point to their success as a proof of concept as you expand Agile throughout your organization.