Implementing AGILE in small teams

As well as working on updates and refreshes to our products we’ve been busy implementing some processes and working habits to make our development teams faster, smoother and more Agile.

Recently, our growing development teams have been working very hard to introduce and work to a more flexible and adaptive set of development processes. Like most modern development teams, we opted for the Agile methodology.

We’ll share some of our practices, approaches, and pitfalls in this article in case you’re a smaller team looking to improve your working habits or you’d just like to know more about the inner workings of IAM Cloud.

Traditional software development

Our development teams at IAM Cloud are smaller and more autonomous than in major software enterprises. We previously managed this with a more traditional, waterfall-driven development style. The downside to this approach however meant quite a few of our developers ended up working in a vacuum. The classic "silo" problem. 

The problem is that silos don’t adapt well to change or shifting requirements, which happen a lot in the modern world for several reasons:

• Technology evolves at a rapid pace
• We have a diverse range of customers with equally diverse needs
• As a Microsoft partner, we are partly driven by changes to Microsoft’s core products and platforms

Additionally, there is a risk of falling into the trap of working on whatever is shouting the loudest, rather than from a prioritised roadmap of user needs and feature requests. It also leads to less-than-ideal team communication with more effort being needed to stay in contact and find out what everyone is up to.

Enter the Agile era

Agile development is not new. In fact, it’s been around for decades, but there are well-documented and defined sets of practices and processes available to aid teams nowadays that have been tried and tested in the real world.

Recently, we’ve been taking the time to adopt some of the more common elements of Agile and introduce them into our development teams. So far, it’s working superbly, and we already have more visibility on work and improved communication.

The benefits for us are clear:

• Visibility
  Everybody in the team has much more clarity about what the overall goals we’re working towards are and can see, at a glance, where different members of the team are on their assigned work areas.
• Transparency
  Again, by having a shared backlog and ongoing ‘doing right now’ sprint work, each team member has a much greater insight into other teams’ work. We can see how what we do affects others and how the development is progressing overall
• Improved communication
  What with daily stand up meetings, a shared Kanban-style board and integrated Microsoft Teams, we all get work moved forwards and can instantly communicate blockers or areas where we need help.
• Adaptive not reactive
  By spending the time planning and prioritising up-front, we avoid the common ‘fire-fighting’ scenario where the most pressing thing is done next/now. We can decide, as a team, what need to be done, in what order, and gain a clear picture about our capacity and output. This also helps us to inform customers more precisely on timelines for features.

If you’re thinking about implementing Agile to see some of these benefits for yourself, then we have a few tips that have helped us, as a smaller team.

Start small but keep scale in mind

If your company or team are new to Agile, then you’re likely going to fight two battles:

• Internal adoption friction
• And a lot of unknowns about how and where to start

People are generally resistant to change and so introducing lots of huge changes to working practices is going to be met with a lot of resistance, valid or not.

Also, Agile can be a quite prescriptive beast with lots of different parts. If you’re a smaller team (or even if you’re not) then trying to implement the entire menu of Agile dishes is going to be a challenge, especiallyif you don’t have a knowledgeable practitioner on board, such as a an Agile trainer or consultant.

So, start small. Choose the areas you think will help the most and implement them in chunks, one or two at a time.

That said, it’s important to do things as accurately as possible to begin with and choose habits that can scale if needed as your team and knowledge grows.

For example, at IAM Cloud, we introduced stand ups a handful of times a week and asked developers to plan out their tasks as simple ‘build widget ABC > 3 hours’ blocks (much more easily adopted as a lot of our developers are the doing the work they themselves have planned).

Write it down in a living document

Whether you’re an Agile whizz or not, chances are that with some training and the natural passing of time, a few of your team will become more knowledgeable than others.

This is fine for those in the know, but it can lead to siloed knowledge and those team members getting interrupted regularly to share how XYZ works in Agile.

Here, we wrote a small, lightweight document (again visible in Microsoft Teams) that everyone can refer to, add to, question and generally treat as a set of working guidelines.

Choose what works, ditch what doesn’t

As we’ve mentioned, Agile can be very prescriptive and some practitioners have been known to zealously guard the Agile rulebook. However, in my experience, the best teams tend to pick and choose the parts which work best for them.

Yes stand ups are great and heartily recommended, but no, it’s not going to ruin your sprint if you don’t have them every day.

No, you don’t have to have retrospectives right now; perhaps there’s a better way for your team to share and review feedback?

Talk to some development outfits that have perhaps implemented a good Agile process and get some of their opinions.

Consult your teams

Remember I mentioned resistance? An easy way to mitigate this is to get your teams involved. After all, you’re asking them to adopt this new way of working.

By presenting your planned changes, you can open up a great channel of communication with the teams to see what their thoughts are and how they’d like to see things work.

At IAM Cloud, we’re very fortunate to have teams that are ready to embrace new things that will improve our development lives for the better, but we still had a lot of opinions and experiences from our careers to help give Agile at IAM Cloud the best start we could.

Treat Agile like Agile

At its heart, Agile is an iterative process: you decide what the priorities are; you work on them; you reassess the priorities; you work on those; repeat repeat repeat.

But why shouldn’t you do the same for the process itself?

If you’re new to Agile (or even if you’re not) then be sure to evaluate the Agile process itself and see what’s working, what’s not, what can be improved, what can go. Etc. This can be done through team get togethers or more formal retrospectives.

It can also be a case of having an Agile Roadmap where you build a list of ‘things we’d like to implement from the Agile bible’ and then introduce them slowly or incrementally over time.