Increase the Agility of your IT teams in 7 steps - ACA Group

The people that responded confidently to the question above often start enumerating all the Agile Practices that they apply, be it Scrum, Kanban, retrospectives, stand-ups, demos or Test Driven Development. The hesitance of the other people mostly comes from the uncertainty of what Agile really is. When are you doing Agile? What is enough?

What exactly is working Agile?

Instead of seeing Agility as a rigid thing, it helps to see it as a maturity scale. Everyone and every team is working in an Agile manner, but not every team has reached the same level of maturity. Although the differences between teams or even individuals can be big, just like in Kaizen (Continuous Improvement) or Karate Belts, no one will ever reach the maximum. There’s always room for further improvement.

Speaking of improvement in working Agile: applying Agile Practices will generally improve your Agility. However, to keep that level of Agility from stagnating and to really grow, you’ll need more than copying and applying Agile Practices. The key is to build-in the Continuous Improvement mindset of consistently validating your way of working by the 12 Agile Principles.

Working Agile means that you continuously shape and improve your way of working by challenging it against the Agile Principles. Review your process frequently, using the Agile Principles as guidelines and the Agile Practices as inspiration!

Working Agile means that you continuously shape and improve your way of working by challenging it against the Agile Principles. Review your process frequently, using the Agile Principles as guidelines and the Agile Practices as inspiration!

The same is true for working Lean. It means that you continuously evaluate your workings by the 7 Principles from Lean Software Development.

These 19 principles can be a bit overwhelming, so inspired by these principles, I’ve created 7 steps to increase the Agility of your IT teams.

7 steps to increase Agility for new or existing teams

Think of the whole product development lifecycle for the product that you’re currently working on. It starts from the value you want to create for the customer or the assumption that you want to verify. It ends when the smallest solution for that outcome is delivered to the end customer. With that process in mind, let’s walk through 7 steps that will help you increase the Agility of your IT teams.

1. Visualize, visualize, visualize

Physically visualize what your teams are working on. Visualizing creates more transparency and lowers the barrier for others to join in on discussions. A visible workflow provides a structure for your collaboration and allows for more in-depth discussions. Here’s a small subset of ways to visualize whatever your team is working on:

• visualize the flow of work through a physical Kanban board, using sticky notes to represent the value you’re trying to create and lanes that represent the different steps that are required. Annotate the sticky notes to make impediments visible. Add avatars to make it what everyone in the team is working on.
• visualize the customer journey, product scope and releases by having the User Story Map visible in the team room. Alternatively, hang up the screen mock-ups or product screenshots on the wall. Draw up the personas and list the information you have about the end-users.
• trigger discussions on the design of your software by having printouts of the architecture diagrams in the team space. Visualize your domain model as well to ensure that everyone speaks the same language in these discussions.
• understand the users by visualizing insights about your product. Which features are being used and which not? How many users are facing errors?
• share a common goal by visualizing the progress toward the next milestone or MVP. Any blockages in your progress, e.g. a failure in your build pipeline, should be visible on a TV screen so everyone in the team immediately gets a heads up.

TIP: Next time you have a visitor, especially business stakeholders or sponsors, walk them through the visualizations in your team room. It will give them ‘Boots on the Ground’ and valuable insights about the project. It will be a boost in trust and confidence.

2. Collaboration > documentation

Building complex products requires multiple skills and multiple people. Instead of creating a document and handing it over to the next person the process, focus on collaboration and knowledge transfer in person. A document can be outdated quickly and require a lot of time to be kept up-to-date, while you’d rather spend resources on getting actual work done.

By sharing information face-to-face or participating in the brainstorm, everyone involved in the development process gains a lot more insight and will be able to do a better, more qualitative job. Here are some ideas:

• Regularly walk through the software design, architecture, customer journey and domain model with the whole team.
• Start the development of a story with a kick-off in which the analyst explains the story and its rationale face-to-face. Don’t forget to involve your dedicated tester if you have one!
• Pair programming is one of the best ways to learn from each other and to get a team that is fully aligned.

3. Fast feedback

Building a product is a team effort and requires a lot of work. We want to make sure that we are always doing the right thing with the right quality. The only way to know that you’re delivering valuable work is by providing – and getting – fast feedback. This feedback from the users on the features you’ve built, but also from the next person in your workflow. The faster the feedback, the smaller the chance the next person in line will be dissatisfied with the quality of work you’ve delivered before you improve. Here are a couple of ways you can build fast feedback loops:

• validate early mockups or rapid prototypes of the solution with the end users before starting actual development. Make it a habit in the team that everyone takes the time to play and test the product they’ve built to raise the empathy for the users.
• release fast and often. If you only release once a year, you’ll only know after one year whether it was worth the investment.
• do a technical review of every story at the end of the analysis to improve the quality of the analysis and avoid impediments during development. Also, do a technical review of every story that has been elaborated to improve the quality of the elaboration.
• validate the proposed architecture and consequent changes with the team to get early feedback on the feasibility. Additionally, frequently organize team retrospectives and retrospectives with the external stakeholders or collaborators to capture everyone’sfeedback on a regular basis. Use this feedback to improve your product or processes!
• make new features available to test users, stakeholders and the actual end users as fast as possible. Don’t forget to gather insights on how your users use the features you’ve previously built either.

4. Create a smooth workflow

To get your team to work like a well-oiled machine, you must ensure a smooth flow of work. A good flow means that planned work is delivered in a short amount of time. The investment made by the organization will be a lot lower before they see the resulting revenue.

To get to that point, start by making your epic and story workflow explicit and visible with a Kanban board. Next, improve it further. Here are some tips:

• define WIP (Work In Progress) limits for the different steps in your process.
• reduce the amount of ‘idling’ work by reducing the size of queues like ‘ready for development’, ‘to test’ and especially ‘waiting for deployment’. Don’t fall in the Scrum trap that your work finishes when you have implemented the story. The value is only delivered when the functionality is available in production.
• measure the total number of post-its that are ongoing in your flow, whether it’s a story in analysis, review, development or deployment. Is it increasing over time?
• apply the mantra: “Stop starting. Start finishing!” Don’t just pick up a new story for analysis or development if you can help a colleague to finish a story already in progress.
• swarm impediments, difficult stories or the initial project setup with the whole team. This will drastically reduce the lead time and ripple effects it would have.

5. Split work in small parts

Splitting work in small parts allows your team to perform the least amount of work before actually starting to deliver functionality. Not only does this ensure a faster feedback loop, it also gives your team a feeling of accomplishment each time they finish a chunk of work.

Splitting work in small parts may seem like a daunting task at first. Here’s how to break up your work:

• split a big road map or product into small releases or Minimal Viable Product (MVP) increments based on the value it delivers, while taking the customer journey into account. Focus on bringing the first release live before starting work on the next release.
• split releases or MVPs into Epics or features that you need to deliver. Focus on finishing the most important Epics before starting work on the next Epic.
• split Epics / functionalities into Stories that can be implemented in 2 or 3 days tops. Focus on finishing ongoing stories before starting new stories.

After breaking the work down into Epics and Stories, set the priorities for the most important pieces for an MVP. This way, you always do the least amount of work to actually start delivering without missing the bigger picture.

6. Outcome > output

Continuously fine-tuning your way of working ensures a smooth workflow and high output. However, it’s more important to deliver the right outcome than a high output. Otherwise, you’re just spending money that the organization could’ve spent differently. So:

• evaluate what you’re working on. What is the value your project will deliver?
• focus on finishing work in progress instead of starting new work.
• make sure your team is finishing its work up to the point of bringing it live to the customer. All analysis work that is not yet developed, all code that has been written and is not in production, is still ‘waste’, since it doesn’t bring any value to the end users.

7. Quality & simplicity

Delivering quality needs to be everyone’s focus within the development process. Without that focus, you’re sure to deliver sub-optimal results to the next (or final) step in the process. Think of bugs, impediments, and confusion that end up costing more time and resources. To keep your focus optimal and avoid mishaps, always work on the simplest solution that meets the goals. A simpler solution is easier to understand, implement, explain and support.

• Only implement what you need now and what is in scope of the current story, spike, or epic. Any additional scope might result in work that will not be used.
• Every form of inefficiency in code or the way of working is technical debt that your organization will pay for eventually. Consistently remove small parts of this technical debt. By removing small parts, there is no short term negative impact on the performance of the team and you will still benefit from the mid and long term positive results.
• Use tooling like Sonar to review the quality of code. Make it a habit when implementing new features to reduce technical debt in the code that you are modifying. Continuous, small refactorings do not hinder the delivery of value, but a big rewrite, when the technical debt is too high, will have a huge impact.

Takeaway

Continuously improving the way of working using the Agile en Lean principles as the guiding stars, is still not common in every (IT) organization. This blog post gives some actionable steps you can take to increase the Agility of your IT teams. You don’t have to start implementing all these steps right away, though. Start with a few that are manageable for your and your team, evaluate, improve and repeat. That’s how you’ll increase the Agility of your IT teams in an Agile way!

If you want more information, tips, guidelines or more, reach out to our Agile coaches and they’ll help you out!