Is Agile working for you?
With growing demand from business for realizing more functionality in shorter time intervals, many IT organizations choose Agile methods. In these organizations, with the necessary training and coaching, the teams practice Agile principles and see visible benefits.
At an organizational level, successful Agile adoption would result in improvements in multiple areas, across business, development, and support function. How does an organization know that Agile implementation is effective? This article identifies key indicators that show that Agile is working at an enterprise level.
Business is happier with the solutions delivered by IT
When Agile projects deliver what business wants when they want it, the stakeholders are happier. This would reflect in the results of the customer satisfaction survey. The business stakeholders would typically look for the following before ticking the "Extremely Satisfied" box in a typical survey:
Faster releases leading to shorter time to market
Improved quality of deliverables -- fewer bugs and less rework cost
IT solutions meeting the nonfunctional requirements as well
Better visibility into "what's coming next," and when, in production
With effective adoption of Agile practices, the Agile teams would be able to deliver all these.
Business appreciates that the development team has graduated from "Doing Agile" to "Being Agile." A happier business stakeholder who is fully engaged with the Agile team acts as a partner in development and could eventually speak for the IT teams!
Development teams are better able to estimate and predict releases
Successful Agile adoption means that the development teams benefit as well. They are now able to estimate better and commit the right amount of functionality to business. This results in a better "say-versus-do ratio" -- stories committed versus stories delivered and accepted.
With successful Agile adoption, configuration issues are fewer and the release team does not see surprises just before production releases. The self-organizing teams identify risks and are better equipped to mitigate them. The ScrumMaster is empowered to interact with different stakeholders to remove impediments.
With improved planning, estimation, and solution engineering, the technical debt shows a drop and the final product is robust and less prone to failures.
The operations team has bandwidth for more value addition
As a result of robust and fail-proof solutions, the production support teams see a decline in high-severity tickets. They still need to address user queries related to settings and configuration, but issues related to poor quality of code would be far fewer. The release and deployment team would be better equipped with the necessary hardware and software platforms to move the solution to production.
Thus the operations team would have bandwidth to contribute in the upstream activities of the solution development life cycle -- right from requirements analysis and the operations/deployment perspective through the final stages of system integration/release testing. This is a welcome scenario for DevOps!
Enterprise architecture is robust but flexible
Agile principles encourage technical teams to develop and improve the architecture as the solution development progresses. With incremental design and regular refactoring practices, the technical team would be able to build a robust architecture that could scale up to increasing demands of functionality and performance. At the same time, because the team constantly validates the design through testing, a higher number of use case scenarios would have been considered while working up the solution architecture. With multiple teams building the different parts of the solution and integrating the parts on a regular basis, the enterprise architecture evolves into a robust and flexible platform on which to build multiple applications.
Teams participate and contribute to common corporate initiatives not directly related to their projects
Yes! Agile teams are an enthusiastic lot, and successful Agile adoption would mean the teams are not stuck in their sweatshops testing, coding, and refactoring all the time. They now know their capacity and velocity. They engage closely with the business stakeholders and better estimate their stories. They better predict the outcome of their sprints. This would ideally result in less "crunch" time every day. The teams will have an opportunity to read emails(!) about corporate announcements, initiatives, and competitions. They would have a better chance to participate in these initiatives -- examples include volunteering for social-responsibility events, conducting or participating in technology quizzes, or conducting technical or Agile learning sessions for larger groups outside their delivery organization.
Business stakeholders actively participate in Agile ceremonies
This may sound like an insignificant outcome of successful Agile adoption. However, it actually is an important indicator that business is completely on board with the IT teams in implementing Agile practices. Agile is about collaboration -- the IT and business teams should work in tandem for successful Agile adoption. If the business stakeholders perceive Agile meetings as mandatory and attend them for the sake of attending, the essence of collaboration is lost. With effective Agile implementation, the business stakeholders would talk about Agile ceremonies and their effectiveness in their internal interactions. They would look forward to the Agile ceremonies to actively contribute to solution development. They would evangelize Agile practices in the business portfolios that are in early stages of the Agile journey.
Thus an organization that has successfully adopted Agile practices sees rounded improvements in multiple areas. As a good "side effect" of those indicators, the following signs could also be seen in such organizations:
Leadership would be willing to invest to promote Agile in more lines of the business.
Delivery teams would select the right projects to execute using Agile; they not choose Agile for such reasons as "Agile means no documentation!" or "With Agile, requirements can be changed any number of times, anytime during the development cycle."
There would be an Agile framework with the necessary processes, guidelines, and process aids. The process compliance team would use the Agile framework as the reference for audits/compliance checks and would not flag Agile practices as "noncompliant"!