Agile transformation is a Journey…

Agile has taken a grip on how we do things and is slowly taking over a variety of industries and walks of life. Some of us remember, back in the days, projects ran for a year or more and only then the time came to decide whether the project was a success or failure. Teams got culled, people lost jobs, companies pulled plug on initiatives when things did not go well and more often than not the projects did not go well. Agile methodology has brought this uncertainty to a halt and has given all the stake holders including the engineering teams the ability to verify and ascertain often and regularly to ensure that progress is being made and in the right direction and there are no surprises at the end. That’s good news (for all)!

Adopting Agile in a large complex organization or team can be daunting, at times horrifying and can result in disoriented teams, fragmented organizational goals. Agile is a paradigm shift from the traditional methodologies and needs a new mindset. In my experience of 15+ years involvement in various types of Agile, I have seen some teams (especially large ones) starting Agile for months into a year or more and then dropping it altogether. When asked “why did the Agile transformation not go well?”, the answer seems to land somewhere between, Agile is not for our organization, we did not have the expertise to implement Agile, Agile did not produce the results we needed, Agile buy-in challenges. Well, as with any organizational changes, Agile transformation is complicated and arduous, period.

As the saying goes “Well begun is half done.”, how we begin the transformation is very crucial for a successful Agile transformation. Not all problems are nails that can be hit in with a hammer; similarly Agile may not be a solution for all organizations or for all the problems being encountered. A careful evaluation of whether the organization needs Agile transformation with a clear mind and with zero bias can save a lot of cost, pain and lost time. Let’s be clear, there definitely are situations, organizations and business problems that may not be conducive for Agile. Understanding who are the parties involved (notably, I did not say stakeholders) in this transformation and why would they be interested in this transformation will help analyze the lay of the land and prepare for a plan of action.

An Agile transformation initiative that starts with the top level and then goes to the lower rungs of the organization would have the most probability of being successful. Some of the key participants in a typical organization would be the Top Management, PMO, Product Mgmt., Marketing, Learning, Sales, Finance, Professional Services, Adjacent BUs and of course the Engineering Team. For the success of the transformation, buy in, participation and sponsorship from Top Management is of paramount importance. In most organizations, the business results or deliveries are the responsibility of the management. Having management participate and understand Agile becomes crucial because they may have to alter or adjust the ways they are doing business. Agile may have impact on releases as compared to the traditional methodologies and thus management would have to work with the customers in a slightly different fashion, setting the expectations slightly differently. Management may have to work with Sales teams and Product Management teams in how their targets are being set based on the releases and business deliveries and may be even the organizational goals and targets. The learning and marketing teams may have to change their work cycles to match the Agile methodology. Finance may also be impacted on how the budgets are consumed and tracked in an Agile environment. As we can see, Agile transformation impacts the breadth of the organization and that explains why it is not easy to make it successful, again let’s not forget that change is hard.

At the cost of repetition, I would say again “Top Management participation is crucial for the success of the Agile transformation”. If the Agile transformation only involves the lower echelons of an organization, then there is a high risk of it resulting in “An Agile with waterfall expectations”. That’s where an Agile Champion comes in very handy. Any organization planning for Agile transformation, would immensely benefit from an Agile Champion from within. The Agile champion would better serve the organization if is in a high enough position to be able to have some influence with the top management and other groups, BUs and participants in the transformation. The Agile champion would also be very useful in acting as a referee in certain situations.

Providing Agile training for all the parties involved is a must as part of the transformation efforts and is a no brainer as well. It is important that the training is uniform across all the divisions to ensure that same practices and methodologies are discussed and included. Again, the training does not have to be done externally, which generally costs a lot more as opposed to in house training. The Agile champion may be an ideal candidate for becoming an expert in Agile and train the rest of the organization. One of the least talked about but the most important aspect of the transformation is the Agile tool. I have seen organizations using the “Yellow Stickies”, spread sheets and other informal means to accomplish Agile. But, using an appropriate Agile tool which can provide the flexibility to tailor the process, steps, validations, templates can make a great difference. Some of the common tools used like JIRA, Pivotal, Rally, Zoho, VersionOne (there are several opensource tools available as well) would fit in well for a variety of situations and organizations. It is important that one tool be standardized for the entire organization and be used from day one. The Agile management tools not only act as the repository and the process tool, but they also come with some key reports that are readily available. These reports are very useful in running the day to day ceremonies and tracking. Some tools also come with the ability to create additional custom reports as the team become more and more knowledgeable and experienced in Agile.

Initial days of using Agile can be very chaotic, confusing and may not produce the output expected. The leadership should keep the teams motivated and the Agile champion should keep all the participants up to date on the progress. This is the phase where everyone involved would have to be accommodative, patience is the virtue here. As the dust settles (3-6 sprints approximately) the teams are now following Agile, getting into the routine habit of all the ceremonies and are able to produce some output. But the focus then would be on how to make it better. As we all have heard and learnt, Agile is a self-managed process, meaning the Agile team should work on their own to improve and find the right balance to get to an optimal state. Following are a few of the best practices Agile teams could benefit from.

·      Clearly define the workflow within the Agile tool as to what states the stories flow through and make it mandatory (for eg. To-Do, In-Progress, Development, QA, Done etc.)

·      Defect may follow a different path and defining that early may help reduce the confusion among the team and improves the quality of the sprints

·      Swim lanes should be created for each of the team member on the board, making it easy to see all the tasks assigned to each team member and what state each of the tasks are in

·      Incorporate peer review as a task on the story, to ensure compliance, put a validation that task cant move to next state without peer review task completion

·      Have a clearly defined “Definition of Done” and this should be discussed and accepted by all participants

·      Although might sound obvious, a list of meeting etiquettes should be defined and accepted by all team members (Mobile & laptop usage, muting of phones, sharing the scrum board, background noise etc)

·      A list of clearly defined expectations from the development, QA (and other) team members should be created and accepted

·      The role and the responsibilities of the Scrum Master should be clearly discussed, understood and accepted by all the parties

·      Each Agile ceremony should be clearly discussed, and the agenda and expectations are all agreed by all the team members

·      Keeping track of the spillovers in each sprint and making them the highest priority in the next sprint will ensure that that there are no incomplete stories lying in the backlog

·      Sprint Review criteria should be discussed and defined as to what will be demoed and what qualifies for demos

·      If the sprint is for 2 weeks, a calendar should be prepared for 10 days and all the ceremonies should be put on the calendar with day and time, all the other activities in the sprint should also be put on the calendar to ensure that every one is aware and expectations are set upfront

Generally, in about 3-6 months, most Agile teams get settled down and start practicing all the ceremonies effectively and have gotten into the groove. The next biggest challenge for the team is to ensure they are performing optimally and are able to produce the output that is cost effective and caters to the organizational needs. That is where the metrics collection and review come in handy. The leadership team could be involved in this activity as well, to understand how well the team is preparing and executing. There are several out of the box metrics and charts available on most of the Agile management tools. Here are a few other metrics that could be considered to get a deeper understanding and fine tuning.

·      Consider having the team prepare a fully groomed list of stories or PBIs (Product Backlog Items) ready before the sprint start date, more than enough for the capacity of the team for the sprint

·      Consider having the list of PBIs that provides the variety of the tasks as the team consists of a variety of skills sets

·      Velocity of the team at the end of each sprint can be a very useful metrics to understand the speed of the team, looking for a velocity trend is useful

·      Capacity Utilization of the team, would provide a good measure of the efficiency of the sprint execution

·      Having a special metrics to measure how many PBIs were 100% completed in the sprint, gives a measure of the focus and the impediments the team is facing

·      Measuring how many subtasks were 100% completed gives an idea of what type of work is moving faster, what type of work is slower and would also be an indication of the team efficiency

·      Having a metrics to measure the estimation accuracy of the PBIs completed gives a good understanding of underestimating, overestimating etc.

·      The metrics to measure the estimation accuracy of the PBIs not completed gives an insight if PBIs are not completed because they are underestimated

·      Capacity Utilization on completed PBIs can be a complicated metric to collect, but would give a good understanding of how much energy is being spent on delivered PBIs

Agile works very well for small teams and startup organizations, but for large organizations having programs with engineering teams of 20, 30, 50 or more members with high cross dependencies, it is very difficult to make it work as a whole. Although the individual sprint teams may be doing well, but the framework does not provide for the cross team, cross BU collaboration. This is where the SAFe (Scaled Agile Framework) becomes a very important framework that provides the various key ceremonies and the tactics needed to make the large team work together. That’s a discussion for another day!

Although, this article may make the transformation sound easy, it is very time consuming and painstakingly complex. I would really suggest and strongly recommend that you have an Agile expert on the team or consult with one. I realize this is a long article and will need some time to read, but then, as I already mentioned at the beginning that this is a journey! All the best for your Agile and SAFe transformation initiatives.

Any views and statements expressed in this article are purely of individual nature. This article and any part of it should in no way be considered as representing any organizations I have worked for in the past, working for currently or may work for in future. Any questions should directly be sent to me using Linkedin messaging.

#Agile, #Scrum, #AgileTransformation, #Agiletransformation, #SAFe, #SAFeAgile, #methodology, #SDLC, #PDLC, #Bestpractices