An organization decides to embark on its agile transformation journey because every other organization is doing so. It creates a transformation team and hires agile coaches to help in this transformation. This is a huge organization with multiple lines of businesses that have been operating in a highly regulated environment with management heavily depending upon traditional project management, compliance and governance processes that include executing multiple small projects simultaneously and assigning team members (resources) to work on 3-5 projects. There are resources (team members) from multiple partners who carry out software development and testing activities for these projects.
The organization adopts scrum and chooses JIRA for managing the work and tracking progress of projects. Few teams that are early adopters in this transformation journey undergo scrum training and customize JIRA heavily to meet their traditional project management needs. Many other teams start using JIRA without any coaching support or agile training and use Scrum or Kanban depending on what the managers think suits their needs.
8-10 months down this journey, the organization decides to track metrics and report to executive leadership at the line of business level. What are the metrics tracked? You guessed it right – Velocity, Predictability, Moved stories, Lead time, Cycle time etc. etc. for Scrum teams. Numbers are reported every month across all the lines of businesses. But do these numbers make any sense? Nobody knows! There is total chaos as coaches bang their heads against the middle management layer who do not adopt an agile mind-set and execute waterfall projects under agile disguise by adopting a few agile terminologies and practices like user story, feature, daily stand-up meetings and sprint planning.
The Scrum Master’s role becomes that of an administrative assistant who updates the JIRA board and plans meetings for the team. Product owners do not have time to be available for teams and are seen only during sprint demos as they are working on multiple projects in parallel. Business does not provide quantifiable business value for the features that are being developed but is only concerned about when this will be done? Everybody is working towards meeting the milestone and deadline set by the business.
There are multiple dependencies with partners and teams are expected to work at 100% utilization and deploy code to production during weekend. People are so busy delivering projects and weekend releases that they do not have time to discuss about adoption of new practices or agile ways of working to address existing challenges. They have a fixed mind-set which is not amenable to change.
Agile
This sounds familiar, doesn’t it? So then, is the organization really transforming? No. Let’s see how to fix this.
Key Steps for Successful Agile Transformation
Firstly, any organization should identify the existing pain points and create a baseline of the current situation with regards to delivering value to the business. Gather inputs from business and IT leadership involving as many stakeholders as possible. Next step would be to get commitment from business and IT for their participation in creating awareness about the transformation program across the organization.
Create an Agile Transformation Centre of Excellence headed by an experienced Agile leader who has rich experience in enterprise Agile transformation. Staff this team with qualified and passionate agile champions within the organization and hire Agile transformation coaches externally, if not available within. Task this core team with the responsibility of coming up with a transformation roadmap.
Identify a pilot program or initiative for kicking off the transformation. Create an organization structure with right sized cross functional agile teams involving participants from business, IT and any other support function. Ensure that leadership participates in trainings and encourages their directs and teams to attend these trainings.
Leadership has to take time out for these trainings to set the right precedent. Select the appropriate Agile Lifecycle management tool that supports the agile framework or methodology chosen based on organization’s business and technology landscape. Many times, it is seen that although the organization chooses Scrum it does not assign the required Scrum Masters or Product Owners to their agile teams citing budget constraints or maximum resource utilization concept.
If there are vendors/partners involved, then Scrum Master is considered as a role that can be filled in by temporary staff since it is not considered as a permanent role within the organization. This is a serious dysfunction that needs to be addressed, else the benefits of adopting agile ways of working would not be achieved to the level as expected.
Organizations cannot mature from traditional project management mindset to an organization with agile mindset i.e. from doing agile to being agile if they do not align the organization structure accordingly. You cannot get different results by doing the same thing repeatedly. If you need different results you need to do things differently.
Focus the transformation efforts entirely on the pilot initiative and gather success stories to share across the organization. Conduct roadshows to create awareness and slowly scale the transformation efforts to other parts of the organization.
A common mistake is to run parallel transformation initiatives across the entire organization in a big bang approach. This leads to a lot of resistance and challenges that could create a negative influence in the transformation journey. Change management is a very crucial area that organizations need to focus on when embarking on an agile transformation journey.
Metrics play an important role in communicating the achievements of the transformation effort to leadership. This is another area where there needs to be a razor sharp focus. Instead of gathering every type of metric available in the ecosystem, emphasis should be placed on tracking a few simple metrics to start with. Baseline data from business and IT that was gathered before transformation should be compared with the metrics collected after implementation of transformation efforts.
Reporting should be done in a concise and simple way so that these are easy to understand, rather than a huge pile of metrics data that is difficult to comprehend. Focus should be on business value and technological improvements related metrics such as time to market, increase in revenue, reduction in costs, test automation, improvement in quality of code, reduction of bugs etc. and not on velocity, developer productivity, resource utilization, number of stories or backlog readiness which are too theoretical and outdated agile metrics.
In conclusion, the success of an agile transformation depends a large extent on the leadership involvement and commitment in setting up the right organization structure that supports agile ways of working and creates a mindset that gradually changes the culture and DNA of the organization right from the top to the bottom.
