Agile ways of working – how to not let ‘good enough’ come in the way of ‘better’

While the agile ways of working and the agile mindset are clearly established as the leading approach to solution delivery and even non-IT work delivery, in most instances, teams have limited themselves to elementary prescribed practices. It is not uncommon to find teams running with the same practices and processes for several months or even years, satisfied with being ‘good enough.’

On the surface, what seems good enough, often turns out to be a by-product of inertia – resistance to change and a proclivity to remain in the comfort zone, for months, sometimes even years.

But then is repetition always a bad thing?

Indeed no, well, not at least by itself. But when it comes at the cost of continuous learning and innovation, and  hinders opportunity for increased productivity and faster time to market, we have a problem. Besides, if the ways of working involve endless repetition without the need to adapt over time, it may be a good candidate for automation.

The problem with not adapting the ways of working to evolving needs is that very often, by the time the realization hits home, it is already too late. Maintaining status quo over a long period, severely impedes the ability of teams to react in uncertain and rapidly evolving situations. The ‘flexibility muscle’ – the readiness and willingness to adapt – begins to atrophy, just as the case is with muscles in the human body that are not exercised regularly.

That brings up the question: Why do teams carry on with the same ways of working for months or even years? Why do they stop at being ‘good enough’?

For one, everyone seems to be happy, including business, at least on the surface. In other cases, the teams follow along processes and practices laid out by a central team such as a Project Management Office, subject to periodic audits to enforce compliance. Adapting the ways of working could raise a red flag in the next audit. Yet in other instances, teams are looking to improve but end up focusing on a small fraction of areas of improvement. This is especially true for long-lived teams working in stable, non-critical environments.

Alright, so that explains why teams stop at ‘good enough’ and what consequences that could have.

So, what is a good starting point for a team to get better? And what if the team has made attempts to evolve their ways of working in the past, based on team retrospectives, but have hit a brick wall when trying to implement change?

All organizations, departments, teams, and individuals are different, with different levels of lean and agile proficiency. Even so, there are some areas that are commonly overlooked and present opportunities to get ‘better’:

1. Domain knowledge: Know what you do and how it fits into the bigger picture

All teams deliver software, but not all of them understand the business and how the system or solution they work on, impacts business. Having a good understanding of the business has several benefits:

• Reduces the load on the product owners leaving them with more time to focus on the evolving business and product needs.
• Helps prevent re-work and idea generation – since the team understands the business better and is aligned to the product vision, day-to-day decisions are made in context. For example, in one of my previous avatars as a product owner, the best ideas came from the team because they understood the context and the application so well and matched that it with their previous experiences.
• Increases accountability – if the team understands the business, they also begin to be aware of the pulls and pushes of it. They feel responsible not only for getting the software working on a test or the live environment but become stakeholders in the success or failure of the work items, from a business context.
• Provides a ‘seat on the table’ for IT folks. Since business sees real value from the ideas and suggestions coming in, they involve IT stakeholders much sooner into the idea to market cycle, which in turn has several benefits, including higher engagement from the team.

Recommended starting point: Map the current level of domain knowledge within the team. Look at the areas where the score is relatively low. Reach out to the product owner and other business stakeholders to get them to support with documents, links, and with their time towards enhancing the business knowledge of the team. The team could also look at articles and publications that help them understand the industry and its challenges better.

2. Work visibility: Transparency is a good thing

What if one were to ask where your team is on the program or release roadmap? What are the timelines? Is it something that is available for everyone to see and is updated in real-time? What about things that matter to business – can they see all of that as well in real-time?

This area ties in closely with reporting. Often, teams prefer to report only those areas that are working well and work behind the scenes to resolve known problems before they come out in the open. Being transparent has several advantages – it alerts the business about potential risks and delays early on, allowing everyone the opportunity to put heads together and find a solution while there is still time.

Recommended starting point: Consider all the reporting that happens within and outside the team. Look at the KPIs used and validate their relevance for the intended stakeholders. Consider including additional KPIs or retiring the irrelevant ones. Also consider steps to validate the quality of data and to automate the collection and its publication.


3. Automation: Automate what makes sense

One of the weaker links that comes into play when looking at team productivity is the time spent on manual tests and on integration, and deployment. Consider putting in place a highly automated delivery pipeline. The level of automation of the delivery pipeline should depend on the feasibility, cost, and the business case for it with a bias towards complete automation.

Recommended starting point: Look closely at all the manual activities involved in getting a work item from start to go-live. Identify the potential areas of automation and the resources and cost involved. Automate what makes sense.

Conclusion

While there are several areas teams can look at to improve, we find at least some opportunities in the ones mentioned. Once a team has zeroed down on the work area, it is equally important to be able to measure the progress and quantify the benefits.