How to prepare for cases where several teams or teams depend on other teams to produce a layer of architecture that enables their work? SAFe is a powerful model, but when scaling up, you need to make sure you are doing so on a solid foundation. This post presents a way for your teams to evaluate their agile profile.
Agile software development methodologies have long ago become mainstream in the industry. The drive to digitalize business has companies both small and large keeping their digital inventories small, reducing time to market and most importantly focusing on doing the things which create most value first.
In agile software projects we have an empowered fixed team, preferably cross-disciplined, working on a prioritized backlog of business items for a fixed period of time. Within the given timebox the team will complete always the most important things iteratively using a PDCA cycle such as Scrum to constantly improve its working practices.
The team will have a Product Owner who is able to distill the backlog items from all the related stakeholders and pass them to the team. In addition, the team will have a Scrum Master or Agile Coach whose job it is to monitor their way of working and to remove impediments.
The above process coupled with a commonly understood Definition of Done should produce software that solves the most important business problem with constant quality while keeping the schedule. Most of us have also experienced that it works in practice in the projects with typical 5 to 9 people team. In other words, keeping things in scale of a project.
The issues I mentioned in the intro are usually found in the problem domain of larger companies. Conveniently, those are also the issues which Scaled Agile Framework tries to solve. So, maybe at this stage it would make sense to present the big picture of Scaled Agile and try to make some sense of it. Here is a picture how Scaled Agile Inc. likes to present its solution:
As you can see there are a lot of roles, lot of moving parts and several levels. In fact, describing those would warrant a series of posts and it is also something we’re looking at later on in the series. For now, we just need to find a contact point that’s guaranteed to be found from any organization producing software: The (hopefully agile) Team.
Team is the level that produces the tangible results, the potentially shippable product increments. In companies the Team level is the most likely level to be run using agile practices so they likely have experience with iterative work. To handle products, portfolio and budgets companies usually have their in-house practices which often have evolved in the era where agile methodologies were still in their infancy. Since the iteration is the foundation stone of all agility it makes also sense to make sure the basics are in good shape on the Team level before we start scaling things up.
On the Team level day-to-day work on a SAFe-enabled organization should not be too different from any other Agile software project. Each team has its Product Owner, Scrum Master and a mix of cross-disciplined, talented team members. The only difference is the added awareness of other Teams and more structured way of making architectural decisions and timing enablers and features. But let’s not go there yet. Right now we’re still in the state where the Team is working on something they can handle all by themselves or maybe we have a bunch of teams all working without alignment. No matter the exact starting setup, we want to scale up so we need to make sure the agile foundation is in shape.
One of the nice things in the toolbox of the SAFe agilist is a Team Agility Assessment Chart which helps teams to quickly do a self-assessment and create a profile of their working practices. The chart I’m presenting here is pretty much the vanilla assessment chart from SAFe which in my opinion is a good way to start. There are a couple of pitfalls when it comes to self-assessment, though. First of all, you need to make it clear that no bonuses or other incentives are tied to this assessment. The reasons should be obvious, but it’s something that’s good to keep in mind.
Secondly, people have different standards based on their experience and other factors. Just keep in mind that in the less quantifiable assessment parts it’s important to understand where the team is coming from. World Class teams could be comparing their way of working to the very best in the industry while other teams might not yet have seen more efficient ways of working. Clearly measurable goals and examples of them help here. It’s also a good idea to ask the teams to elaborate how they reached a specific grade in the assessment to support the resulting team profile.
Below is an example of how a Team Agility Radar might look like:
This Team Agility Radar shows a profile that is perhaps common for Teams that are working with Agile Methodologies in a small scale environment. Regardless of where the team is coming from the radar shows areas which the team has not been focusing on. As a proponent of SAFe you will be happy to know that you now have insight where SAFe can bring value on the Team level and how you can likely to get the buy-in from the teams. Success or failure here is important as it sets the tone of your agile transformation on the grassroots level.
For your convenience I’ll provide you with an Excel template that will generate the above graph. If this subject interests you I’d recommend to read Dean Leffingwell’s Scaling Software Agility: Best Practices for Large Enterprises. If you liked this post, you’ll find especially chapters 21 and 22 useful.
Until the next time!
Originally posted at mikkovihonen.github.io.