Demystifying Agile Transformation

There is a lot that gets talked about teams working in traditional ways and thoughts of transforming them to Agile ways of working. Before a particular Organization (or a Department) within it gets this thought and starts looking out for ways to transform, there are several things to consider and go through phases in the transition.

Benefits

As a first step, understand the benefits of being Agile.

• Visibility

With Agile software development, there will be a greater visibility for all the stakeholders across business/customers, product and resource management on the progress of work through the visible backlogs, incremental deliverables, productivity (by looking at the velocity or cycle time, etc) and quality (by looking at things like escaped defects).

• Teamwork and collaboration

Agile teams work together and collaborate more than those in the traditional models and interact more often with the Product Owners and/or Customers. The lengthy and time consuming hand off processes between Customers to Customer Representative(s) to Managers to development teams gets eliminated. The direct interactions help the developers better understand the requirements and the turn-around time greatly improves. The teams also work together right from planning to delivery iteration over iteration.

• Early delivery and early feedback

Customers and/or Product Owners have a long-term vision for a product and it gets better envisioned and materialized through delivery of smaller chunks of work continuously over short development cycles. With shortened cycles, Customers also have a chance to provide continuous and early feedback.

It is much easier to change something early than identifying and worrying about it later. For eg, with User Interfaces, there is always a better way to design and a scope to improve the user experience. With an early cut of the UI giving a view of the screens, the look and feel related feedbacks can be taken early and can be changed while the other parts of the product are being built.

• Fail fast

If the code/design is incorrect, let it fail fast. Lengthy development process in traditional models leads to a delayed realization of any incorrect assumptions, defects, etc. In certain cases, it will be too late for this realization and the entire design might need to be changed. If something is wrong, let it come to notice early and fix it early. Shortened development cycles get us these benefits.

• Better Quality

Agile development teams continuously integrate developed code and write automated tests. There is a greater focus on automated testing than on manual testing, which is time consuming. Its not practically possible to re-test every case manually for a complex product. Continuous integration and automated tests help in eliminating this problem and any new code/design breaking earlier code can be identified quickly and also early in the development cycle. With certain Agile frameworks like Extreme Programming, the development teams get to an extra mile where they write the tests before the code as part of their Test Driven Development approach.

• Responding to change

Agile teams by nature are willing to change. As opposed to the traditional process which involves getting sign offs on huge docs and/or designs upfront and later resisting to change due to fear of costs or delays in a large delivery, Agile teams allow change and respond to it. There is less documentation or they handle smaller requirements in each of the iterations. The overall product and requirements evolve as time progresses.

Its very important to remember that change is not always for free ! The cost to change something depends on the amount of change. A larger change in requirements might need more work and can turn out to be costly. With the way Agile teams work, it is not often that such a requirement for a huge change comes into play. However, there can be things driven by external factors like a change in business model, changes in the industry as a whole, etc.

• Customer Satisfaction

With Agile development, Customers are more involved with the product owners or the development teams. There will be regular feedbacks taken from them in the form of demos/sprint reviews, etc and they can view the product evolving through continuous incremental deliverables. An engaged customer who can provide constant feedback resulting in product improvements will be highly satisfied.

• Metrics

Agile development teams are measured through their velocity or cycle time and not by the number of hours ! It is not possible increase the number of hours in a day to work longer and it is totally incorrect to judge how much is being delivered purely by the number of hours. Imagine teams working for hours and hours, stretching weekends but the issues still dont get solved. There is no real value with it. There should be an extra value out of the extra hours.

Some people might take 8 hours to do a piece of work, some 4 and some 2. At one point, 8s should improve their capabilities through experience and get to 4. Now, how do you measure that? Its meaningless to say teams should deliver more hours. Its more meaningful to say teams should improve their velocity or cycle time.

With Scrum and XP, teams use Story Points to estimate User Stories. Once the knowledge in the teams improves through reading and experience, the number of points they deliver improves over iterations, which is called the Velocity.

Early Challenges

Once it is understood what Being Agile brings to the table and get excited, here are few things to consider and be courageous before making the next move.

• Transforming to a new way of working requires an all-new mindset. Yes, its true ! If the mindset doesnt change, the teams will end up Doing Agile than Being Agile. The entire organization should understand and appreciate the 4 values and 12 principles in the Agile Manifesto. And then each framework has its own pillars. With scrum, it has 3 pillars (Transparency, Inspect and Adapt).

• There is a great commitment required from the senior leadership for a successful transition. Its crucial to note that its a transformation that is going to happen and the teams have to just move forward by resolving any hurdles. There should never be a thought of going back.

• The senior leadership must be ready to handle any pushbacks or questions from the teams. It will be really challenging to change the mindset of people and get them to adapt to new ways of working. There will be numerous questions to be answered and potentially a resistance to change.

Making the first move

The next important step would be to hire/consult an Agile Coach. Though there are loads of documentation and training resources to learn Agile, an Agile Coach brings in a lot of real-time experience. They are knowledgeable and have helped several organizations transform. They know the processes and the potential hurdles. With their knowledge and experience, they help in overcoming the hurdles and guide the organization in the entire process of transformation.

An Agile coach can also help in training the associates of the organization in understanding and appreciating Agile way of working.

There are several Agile process frameworks or methodologies (more famous word) which are available. It is important to understand what each of them is and choose one of them (and in some cases two of them based on different types of work in the organization).

• Scrum

• Extreme Programming (XP)

• Kanban

• Feature Driven Development

• Dynamic Systems Development Method

• Crystal

Scrum is the most commonly adopted process framework for complex/large software development and Kanban is for stabilized products with minor changes, L3 support, etc.

Adopting to the new development process

After the teams are trained, the decision is taken on the process framework or model to be adopted, the next would be a series of steps in adopting to it.

• Re-organize

It is quite common for traditional teams to be component specific, each handing different component(s) in the overall architecture of a product. The testing team is also generally a separate team from the development teams.

For teams adopting Scrum, it is strongly recommended that teams are:

• Cross-functional: The individual teams should be capable enough of taking care of everything from business analysis, development and automated

• Self-Managing: Agile teams are self-managing teams. They do not truly need a traditional manager. The development teams closely work with the Product Owners in the prioritization and pick up the top items from the backlog. While things like mentoring associates might still be needed through a line manager, it is not must for him/her to be part of the development team. And for things like Appraisals, more and more organizations are now getting rid of them.

• Co-located: Cross-Functional developers sitting together at one place are proven to deliver more as opposed to those being spread out in the same location or across locations.

• Hire Agile Certified Practitioners or make them in-house

While getting an Agile coach, training and re-organization are early steps in the game, it is important that each team has a certified practitioner like a Scrum Master, Queue Master for Kanban teams, etc. They play a key role in guiding the organization through the transformation and be with the teams after that with several responsibilities like facilitation of meetings, enforcing the processes, eliminating the hurdles, etc. It is often confused with a project lead/manager but its not the same !

• Setting up the process and artifacts

Scrum teams begin by creating an initial product backlog usually through a workshop. They decide on what their smallest quantity of work is and compare every other work with it to get to estimate in Story Points. They have to setup several artifacts like Team Charter, Definition of Ready, Definition of Done, etc. Teams also need to decide on iteration length and shipping/release dates. It is important to note that while each increment is ready and signed off by Product Owner and/or Customer at the end of each cycle, the teams can ship/release work from 2 or 3 iterations at once to Client location.

Kanban teams begin by setting up their queue of work and things like WIP Limits.

• Set up required tools

Agile Development teams deliver increments over iterations by continuously developing, integrating and testing through automated test suite. They will need tools for build automation, continuous integration and running the tests.

The teams and product owners would also need issue tracking software like JIRA to maintain backlogs, visual boards, etc.

Switching over

The organization will need to decide when to switch over to the new development process and start delivering over iterations from there on and keep the ball rolling.

It should also be noted that a process should be adopted as a whole and the process itself should not be modified. The full benefits cannot be achieved by adopting only a part of the process. However, the transformation might expose few problems that take time to fix. In those cases, a short-term change can be done. For example, certain organizations adopting Scrum make short-term changes to it by creating ScrumButs but they need to be eliminated sooner than later.

PS: I originally posted this on LinkedIn Pulse in Jan 2016

About the author

Vishnu Vardhan Chikoti is a co-author for the book "Hands-on Site Reliability Engineering". He is a technology leader with diverse experience in the areas of Application and Database design and development, Micro-services & Micro-frontends, DevOps, Site Reliability Engineering and Machine Learning.