Request your demo of the Sigrid® | Software Assurance Platform:
Whenever organizations consider switching to an agile way of working, they are always looking to unlock more business value. While this is a laudable goal, it can also be quite tricky, mainly for two reasons. First, it requires the whole organization to work in an agile way. While established practices exist in disciplines such as software engineering, it’s much less common in other departments. Second, it requires some sort of a handle on the concept of business value. This is notoriously hard. When someone mentions ‘business value’ in a meeting, two things invariably happen: people nod in agreement (who could be against business value?) and nothing concrete emerges from the discussion.
So, should we abandon the search for business value through agile working? Of course not, but it does help to recognize that there won’t be an agile revolution in your organization that changes everything overnight. Rather, it will take some time to get all teams and departments to change their way of working and to really understand what business value means in your context.
That does not imply however that no gains can be made during that time: in this post, I want to focus on benefits that can be gained from an agile process that may be more local (limited to a team and its immediate surroundings) but are nonetheless of substantial value and, because of their local nature, easier to unlock. Let’s call it local agility. This concerns frictionless onboarding of new team members and enabling a culture of cooperation and continuous improvement between and within teams
When you’re onboarding new team members, you always want them up and running as quickly as possible, and typically the new members themselves want the same. Our process provides a clear framework to onboard people. Since the team organizes the work, a new hire is not dependent on one manager’s availability to get started. A well-defined set of meetings (SUMs, retrospectives, refinement sessions) provides structure and facetime with your colleagues, which is very relevant in a hybrid or remote work scenario. A well-maintained backlog provides a set of work to choose from to get to know the codebase and get meaningful work done quickly. A combination of automated and peer code review makes it clear what conventions and quality standards we expect work to adhere to.
And it doesn’t stop there. The time-boxed nature of agile working provides built-in moments to reflect and improve, and our teams take them seriously, resulting in a continuous stream of small improvements that aren’t earth-shattering in themselves, but the cumulative effect of this continuous tweaking is significant. Improvements can be procedural, like establishing a standardized way of working with stakeholders outside the team to address recurring requests of a similar nature, or technical, like initiating an effort to improve the speed of development pipelines to decrease idle time in day-to-day development. Creating a feedback loop like this also creates a more level playing field between people who would speak up anyway and those who like to have a recurring event in their calendar to prepare for.
While teams have room to organize themselves, having a shared rhythm, a shared set of meetings (SUM, retrospective, refinement) and the same platform to store code and structure the work makes it easier for people to move from one team to another or collaborate on smaller or larger work packages.
But wait, one might ask, ‘local agility’ sounds cute, but isn’t this a kind of agile in name only, the thing agilistas have warned us about? Well, yes – if you think you’re ready after this. Once you have well-running agile teams in a certain discipline, you need them in other disciplines as well.
Let’s say you’re building a software product and you have agile software development teams. On their own, they will have a hard time creating business value. They typically don’t do market research to decide what to build. They don’t do marketing to make users aware of new features or consulting to help users understand how your product supports their process. So if you want to decide what feature to build next, build it, introduce it to users, measure adoption and decide what to do next based on that, you need all disciplines working in an agile fashion. This is where we get into the area of business value.
I want to leave that for another time. Here I want to make the point that it helps to get some local agility going. To stick to the earlier example, you started with these agile software development teams and then you need agile marketing. While marketing is not the same as software development, it helps to have an example of a well-running agile team so that the marketing folks have something to look at to get them started. So while it shouldn’t be the end goal, getting some local agility going is nothing to sneeze at.
Author:
Head of Development
We'll keep you posted on the latest news, events, and publications.
