The Benefits of Building a Truly Agile Team

By now, we’re all familiar with the concept of agile development and are all working in agile teams… Right?

Josef Puchinger
Josef Puchinger, June 26, 2017 9:00 am
Blog > ARA | Continuous Delivery | Agile | DevOps > The Benefits of Building a Truly Agile Team

Since the emergence of the Agile Manifesto back in 2001, agile quickly established itself as the prevalent software development methodology. The industry rapidly adopted shorter sprints of work, regular reassessment and so on. So, surely, in 2017 there’s no question as to whether we’re working in an agile manner? I think you’d be surprised.

Big Businesses – Big Mistakes?

Let’s face the facts: no tech company worth its salt is going to be operating traditional waterfall methodologies in the digital era. These days, everyone’s claiming to offer an agile working environment. But there’s a problem: the agile definition is broad. Really broad. It can mean any number of things to any number of people and up to a point each interpretation is correct. I put it to you: Your business may not be as agile as you think it is.

Many enterprise companies have moved towards a model enabling agile delivery, which is great. But there remains a level of bureaucracy which is preventing ‘true’ agility. Project managers, dedicated QA teams, designers, are still being segregated into in-house silos. Inevitably, this creates an ‘Us versus Them’ culture which leads to no end-to-end accountability for the delivery of the overall product on any single team.

It’s an age-old issue, the ongoing battle between “my code” and the released product. Enterprise businesses may have adopted agile principles – sprint-cycles, stand-ups and the like – but they still have segmented front-end developers, designers, middleware teams, each of whom can argue, “My code was fine”, or, “Testing isn’t part of my job” when the end software breaks. Sound familiar? Moreover, does this sound like a truly agile team to you?

Enter the Cross-Functional Team

Companies that offer agile teams, delivery and environments have discovered the answer is ‘cross-functional’. Put simply, it’s DevOps in action. It’s bringing specialists – developers, quality assurance, operations and the like – together into one small, compact, hyper-efficient team. It’s stripping them of dependencies, removing the limitations of micromanagement, giving them a feature of the overall product to own – end-to-end – and allowing them to do what they do best.

There will be no more exclamations of, “Well, my code works fine”, no more hiding behind the testers. With reduced dependencies, there’s no delay in the story delivery of feature teams. They’re free to work at their own pace, moving from one story to the next without pause. With reduced dependencies, cross-functional teams are simply left to deliver one thing: working software. If they fail to do so, there’s no passing the buck. It’s not about starting a witch hunt; agility is about encouraging you to take responsibility not only for your code but the product itself.

Transitioning to agile isn’t something which can be implemented by product owners or managers. It’s a decision which needs to come from the very top of the company, and it’s one which needs to be implemented properly and entirely. That doesn’t mean it should be introduced in one fell swoop – far from it. Lots of enterprise firms have been quick to adopt agile principles, but not as quick to implement the necessary culture to augment them. Creating small, cross-functional feature teams and giving them full responsibility and accountability for a process, from end-to-end, encouraging them to do what they do best.

Continuous Delivery is the Next Step, Creating the Real Value

The ultimate aim of creating an agile environment is to enable continuous delivery; the next step in the evolution of agile development. It’s the realization of multiple cross-functional feature teams, each of whom deliver stories for your product, from code to a stable release. It’s allowing them to work at their own pace, building release-ready software which will ultimately improve your product by incrementally improving their own code base, adding and deploying new features continuously and squashing bugs.

Automation is a key part of continuous delivery, as it enables the deployment of every change to an application (from code changes to environment alterations), to every environment ­ – in turn, creating a continual stream of releases and updates to the end-user. Agility and continuous delivery are aimed at accelerating your ability to change. Ultimately, your company must be able to adapt to change in order to thrive: you must be able to adapt to new challenges, new software, new user demands, at any time and often with minimal lead times.

Continuous Delivery
Back to the blog
Josef Puchinger

Josef Puchinger

Josef leads Automic's Engineering departments in Austria, France, Canada, USA, Vietnam and India. He has more than 19 years’ software engineering experience in Development/Technical QA/Technical Lead/Team and Lead/Management positions.