Induction into Agile
My introduction to the Agile world goes back about 3 years. Charged with the new buzz of Agile, a team at Digité attended an Agile workshop conducted by a local Agile/ Scrum trainer.
The first part of the workshop was really very exciting where the coach educated us on the Agile Manifesto. In the second half, we learned of various Scrum characteristics. At the end, the coach made a remark – ‘You will be an Agile Organization only if you follow ALL of the Scrum methods described in the workshop’.
This didn’t go down too well with the attendees. We started to discuss how we would adopt Agile in Digité. The change was going to be significant. We operate from three different locations – so getting people together in a room was not possible. Further, ‘Paired Programming’ was not feasible mainly due to cost constraints. At that time, our regression test cycle was a manual (and hence huge) activity before delivering each release to customers. Not to mention all the typical ‘change management’ challenges for overhauling existing systems and processes.
When co-workers asked about it back in office, most of us termed Agile as ‘Star Trek’– all great, but fiction – not designed for a Software company like ours!
Reality bites – are we Agile?
Over the next several months, egged on by Management, we adopted some elements of the Agile methodology successively. The Product Management team was the first to move. Instead of working with the perceived value of features, we started to rank order the Product Backlog. The Engineering team started to plan releases in multiple monthly sprints as well, ensuring a phased delivery and the ability to accommodate changes through the release lifecycle. The QE team was next in the queue, with Test cases automated and a nightly build available for testing.
At the same time, we retained many elements of traditional planning. We were committed to scope and timelines of each major release and there was no moving back from it. All the major software design and architecture decisions were taken during initial Release planning itself. We continued with formal ‘Review’ processes for code review to ensure code quality. Time tracking was also a key requirement and continued as is.
When posed with the question, “Was Digité Agile?”, I was never a 100% sure. Many customers I have spoken to clearly indicated that their methods are a combination of Traditional and Agile. While they abstracted from the “good parts” of Agile, they did not give up on what worked well for them all these years using traditional methods.
Agile or Agility?
Recently, I attended another Agile conference where David Hussman presented a session on ‘Doing What Works Over Doing What You are Told’. David, an Agile coach for a range of companies, presented diverse and real-life views on Agile.
His thrust was – most of the organizations have mastered the art of software delivery after a number of iterations. If organizations have developed a certain way of working over the years, they don’t have to necessarily scrap it all to adopt Agile. Agile manifesto is not prescriptive; it’s a set of simple principles that teams should aim for. There may be various methods to become Agile, but being Agile didn’t mean we’d to follow them all!
This certainly resonated with what our customers were telling us. Agile has great positives; however, it also has challenges – for certain type of projects and organizations. For project sponsors, Agile projects lack visibility of final scope. There is no up-front planning of who will work on what. Large/ distributed teams have been slow to adopt Agile. This is where Agile ALM tools such as Digité, which enable both Agile and traditional methods, are helping significantly.
Overall, the message is loud and clear – our customers want Agility, where their customer requirements are being met better, faster and cheaper!
Sr. Product Manager, Digité, Inc.