Pitfalls On The Way To Business Agility

If you are someone who is taking an active interest in agile transformation and is seeking information pertaining to the topic of scalable business agility, then you may find this blog post interesting. I’ll be sharing some of the pearls-of-wisdom that Mark Richards revealed at the Enterprise Agile Russia conference.

For those of you who may not know, Mark is one of the 18 people who have been awarded SAFe Fellow status. These are recognized SAFe thought leaders and practitioners who have not only demonstrated the highest degree of mastery in the implementation and practical application of SAFe, but also contribute to the development of the framework.

Mark was one of the keynote speakers at Enterprise Agile Russia 2019. The conference was dedicated to Scaled Agile Framework and its implementation in large organizations in Russia. It was organized by ScrumTrek, the largest agile consultancy in the country. In recent years there has been a growing interest in the implementation of agile scaling frameworks in Russia. ScrumTrek is at the forefront of the Agile movement and this conference is a response to the growing demand for information, guidance and case studies in this realm. 

I’ll cover things that resonated with me most in the light of SAFe implementation in our company. 

In the presentation titled “Enabling Business Agility by Forming ARTs That Go Beyond Technology” Mark shared the lessons, he had learned over the years of Lean-Agile coaching and facilitating SAFe implementation at various enterprises.

1. Software is the Product

 Agile Dev Teams use a consistent recipe, but Agile Business Teams require more creativity and Kanban is usually a better fit.

Mark noted that agility in software development is somewhat a regular notion by now as there is a lot of information and guidance available in this domain. It’s not quite the case when it comes to business agility. SAFe attends to this problem. Anyone who has attempted to apply Scrum to Sales and Marketing teams knows it’s easier said than done. Kanban is a more suitable solution for Marketing, Procurement, Human Resources, and other key business functions.  

When I first learned about cross-functional teams it all seemed rather simple. A reality check was when we attempted to form a team involving people with different expertise. We soon realized that the team would not even survive the prototype stage. It may not be an easy task to put a sustainable cross-functional team together in an outsourcing service company (to learn what we do head here). If you have relevant experience feel free to share in the comments below.

You’ve spent years learning to live apart, now you have to learn to live together. 

The Agile ReleaseTrain helps teams align and maintain focus on a common goal. Some people get used to working on components and they develop a mindset whereby they produce a specific component, without seeing beyond the requirements and what they need to do to realize that particular set of requirements. It might be the case that in an attempt to pull people like this together to be a part of a single ART, they will discuss how to work together but once started, will revert to their old ways, each one working on their component. In our experience, it proved to be an extremely difficult task to get people from the business teams and development teams to work in complete alignment.

It’s easy to forget your early struggles and how much you had to learn. You have to slow down and support your new Business Teams as they begin their journey.

We have come to embrace that on the path of Agile transformation you’ve got to be ready to go through the innovation adoption lifecycle. There will be those who buy in straight away and will help you orchestrate and manage the transition and those who will be slow to come on board. 

Adoption of innovation, be it innovative technology or organizational innovation, is challenging. These challenges can be aggravated by the fact that the newly formed team has no previous experience of working together. The Tuckman model describes the stages the team will go through. They are forming, storming, norming, performing.

You also have to anticipate that all the metrics you had in place would go out of the window. However, you should persevere and continue to help your teams mature and develop as, in the long run, it has the potential for substantial payoff.

2. Service is the Product

When change impacts staff, frequent change is hard! The best people to figure out how to solve that problem are business people. 

You can’t do without change management if you want to implement strategies for effecting change, controlling change and helping people to adapt to it. Change can be detrimental if not handled properly and introduced too often. For some, people and businesses alike, it may even be a destructive force. 

One of the most common situations in development is when the client bombards the team with change requests. Such a client may be bursting with ideas and, instead of discussing it with the team and checking the ideas’ viability, starts submitting new requirements with great regularity. All too often such a client expects to see results sooner rather than later. A client like this is not an easy one to work with but there is a way to manage them constructively. One should use the language that they will understand – the language of money works well. Not everyone is good at it, unfortunately, and starts the blame game: “All the requirements have been agreed and documented. You constantly change that. Doesn’t look like you are clear on what it is that you need. Some teams abiding by the Scrum rules may respond: “We are in the middle of the iteration and your change request hasn’t been approved yet. We can’t add it to the Product Backlog.” Now, some responses may lead to mutual accusations of incompetence and will get you nowhere. In my humble opinion, it is best to approach it from the following angle.

By changing the rhetoric you can get a valuable message across and be heard. For example: “The regularly changing requirements force the team to change context, which affects productivity and effectiveness. In the past two weeks, this has cost you X extra dollars. This can be avoided if the requirements are thoroughly captured and defined. I suggest we do the following to approach iterations with more clarity…” We find it helpful to use Impact Mapping и User Story Mapping. It sure pays off to find a common language with the client in such situations. 

In other instances, it may be that the backlog is thoroughly structured and prioritized but the change may be brought in by other teams. For example, system teams can introduce change by regularly modifying standards and infrastructure, or the organizational rules of engagement aren’t something of a lasting nature. 

In such instances, Agile Release Train and Program Increment are suitable change management tools that enable teams to capture the set of new requirements and stay focused on the overall goal. 

There’s far more to assurance than software testing, and it’s a huge cause of delays. Bring your business assurance people onto the team and learn how to achieve assurance flow together!

Testing is an integral part of the development process and is a must. However, if the Feature is not realized as is expected by the client then you are to face delays clarifying what is indeed expected, writing, submitting and approving change requests, etc. The notion of expectation is open for interpretation and what a client pictures in his or her mind may be hard to capture. 

In fact, it is sometimes the case that even though the stakeholders have seen a system description and approved UX-prototypes when it comes to real-life usage, there it is – the unforeseen user scenarios. That’s a discrepancy in expectations in action. By this stage, you would have already put in hours to test the system and track analytics. Developers resort to change requests. It is not uncommon that the majority of delays happen during discussions and approvals with the clients. The wider the functionality the longer it takes to approve it, the higher the risk to waste time. SAFe offers the concept of a Feature Team. Mark explained that feature teams are to include Business Owners. SAFe defines Business Owners as a small group of stakeholders who have the primary business and technical responsibility for governance, compliance, and return on investment (ROI) for a Solution developed by an Agile Release Train (ART).

A better way to capture the expectations of a client or other stakeholders is to include them in the team. To ensure collaboration and teamwork, from the very outset discuss and agree with them how much time they will be able to dedicate to the project and what input they will be required to provide.

Don’t have business teams and technology teams. Set your teams up for success by making them real teams with an enabling structure and compelling direction. 

Putting together and sustaining an effective cross-functional team is a challenge. It requires a thorough understanding of the business goals and which individuals are most suited to help attain it. One ought to be a strong leader to navigate the unique issues and situations this environment presents. Cross-functional team facilitation is a tricky task. See for yourself. Some of the challenges are limitations to the optimal number of teammates to ensure team effectiveness, how much of their capacity the individuals can dedicate to the project, and how to prevent burn out. I am still trying to figure out how best to go about it and how to manage such teams within my own company effectively.

I realized I had made the same mistakes Mark was talking about in his session “Enabling Business Agility by Forming ARTs That Go Beyond Technology”. I do hope that the above will draw your attention to the possible pitfalls on the way to improving business agility and help you come up with strategies to avoid them.