So How Does Agile Work?
By now most people have probably heard about Agile and the advantages it has to provide any IT project. Whether it be Scrum, Kanban, Lean or Extreme, Agile is among the latest “catch phrases” in the world of IT project management. So how does Agile actually work?
During a recent project here at Solve, we had the opportunity to implement Agile within a tool named Jira. Jira contains all of the stock-and-trade aspects of an Agile project: stories, sprints, bugs, and issues. The first thing that struck me about getting the required information into Agile, was the amount of time it took to write the stories. There were more than a few times during the 5-10 minute daily calls, that a member of the team advised that the morning would be spent writing stories. One question arose from all of this:
Was this use of time on the front-end providing a demonstrable ROI?
The answer, based on experience with other projects involving multiple team members, appeared to be a clear yes. The stories provided a common framework from which the product owners were able to operate. Each story was related to tasks within a sprint and those tasks were assigned to a certain developer.
Jira provided us an easy-to-use interface that enabled the team members to move a task to statuses such as in-progress and done. This in turn provided a good idea of how far along in the sprint the team had progressed, and how close the team was to completing the sprint in the estimated amount of time.
The advantage of this system, good or bad, reflected the progress that the team was making towards the ultimate goal. The use of “bug reports” allowed end-users to submit a report of items that did not function exactly as they had originally expected. Those cases revealed both instances where a developer needed to make a change, as well as ones for which requirements couldn’t be met with the existing data. Those bugs were assigned to developers and provided the ability for product owners and the project manager to quickly gauge the number of bugs and the progress made towards resolving them.
Overall, the flexibility of the Agile process seemed well-suited for a project in which the outputs were known and the methods by which to achieve those outputs were a bit more fluid. The solution consisted of a myriad of ways to solve unique problems and the development team was able to compare notes, judge the effectiveness of each method, and start to build a standard arsenal of best practices.
While it is easier for any project team to complete its work using a defined methodology – often times the issue is forced without considering if the project and team in question is well-suited for that particular methodology. In this case Agile proved to be flexible enough to handle the unique project requirements, provide benchmarks for stakeholders, and allow for developers to use their personal knowledge to create effective solutions to challenging problems.
With fine-tuning for your particular project and culture, we’ve concluded Agile can indeed be a valuable addition to your tool kit for successful project management.