Agile Transformation — not really by the book

Agile Transformation — not really by the book

Let’s start with a situation that is all too common: You have “successfully” finished your Agile transformation, which means you have finished all the goals you set out to accomplish. In addition to establishing value streams, synchronizing Sprints, putting in place basic Agile UX practices, etc., there are many other things that needed to be done, such as setting up the chosen tools to provide everyone with the right training they need (even making it required and/or part of the onboarding process), and you’ve done it all. Bravo to you! And now that you are Agile, the sun shines forever, and the entire landscape is bright. Everyone is happy and lives happily ever after as unicorns fly around. Right? …well…

In real life, let’s say your organization has numerous streams of work going on (as most companies do). For this example, let’s call them programs, and each stream is highly organized with a program and portfolio manager. Communication between the portfolio and product teams runs smoothly. Great. Let’s now raise the stakes. Both programs make use of your development teams. Individually, communication is great, but how can you tell what the priorities are for so many different programs? Even worse, what if there are developments that need to be shared across multiple programs and/or depend on multiple teams?

In this case, top-down communication inside each program is effective but not across programs. Who ultimately suffers, anyway? Starting with the teams themselves, who are entirely at a loss as to what should be developed first, how they affect and are affected by other teams, and are unable to swiftly identify dependencies across teams and programs, and of course the organisation overall, which is unable to deliver as planned.

The fact is, even if you cross all your “i”s and “t”s, the key to a successful transformation is being able to recognize and pursue the appropriate communication. And by appropriate, I mean to comprehend how your company operates without reference to the current organizational structure. Communication streams frequently do not adhere to preexisting structures. And we typically and wrongfully consider those structures to be our routes for reporting. It doesn’t really make any sense.

Although it is insufficient — in fact, the seminal book “Team Topologies” by Matthew Skelton and Manuel Pais (Team Topologies) ???? ???? provides a 10-point list of issues that need to be addressed, including Purpose, Psychological Safety (for more information, see Amy Edmondson ’s work on the subject), iterate, and Improve, among others — I’d like to concentrate on a few of those related to effective communication:

  1. Establish team parameters: Establish the team’s parameters, including its scope, dependencies, and duties. As a result, team members are better able to grasp their tasks and know with whom to coordinate various areas of their work.
  2. Identify the channels of communication: Select the channels of communication that are best for your team by taking into account all the options (such as in-person meetings, email, chat tools, and documentation). The objective is to promote effective communication while minimizing needless noise.
  3. Utilize the right tools for collaboration: Use collaboration and communication tools to their full potential. This could include tools for video conferencing, chat platforms, version control systems, and project management software. Make sure the tools are appropriate for the team’s needs and encourage communication and transparency.
  4. Encourage direct communication: Even though virtual communication is often necessary, face-to-face encounters are still important for developing bonds of trust and a deeper understanding. When face-to-face interactions are not possible, encourage team members to participate in regular in-person meetings or use video conferencing.
  5. Accentuate communication that is context-rich: When communicating, make an effort to supply and ask for context-rich information. Avoid communicating in a way that leaves room for misconceptions or delays. In order to achieve a shared understanding, context-rich communication requires communicating pertinent details, goals, limitations, and dependencies.
  6. Encourage knowledge exchange: Establish methods for the team to share information and best practises. Regular team meetings, lunch and learns, internal documentation, wikis, and mentorship programmes are a few examples of this. You may help team members learn from one another and use their combined experience by promoting knowledge exchange.
  7. Use good meeting management techniques. Make meetings productive and useful. Each meeting should have clear objectives, an advance agenda distribution, participation from all relevant parties, and adherence to the time allotted. To guarantee alignment and accountability, follow up with action items and summaries.

It is clear that simply putting tools in place and employing boards, sprints, or another structure is insufficient. Effective communication is considerably more important and makes a huge difference.

Therefore, start examining the actual channels of communication between teams and business units while concentrating on giving each of them efficient means and instruments and working to improve communication. And always keep in mind that these channels probably do not reflect organizational structure.

Additionally, communication should generally provide results rather than merely outputs. As a result, if you look at producing reports from the bottom up, those are typically just outputs that most people don’t really look at or can’t benefit from.

Finally, think about this: The mere fact that you completed the entire tick list does not guarantee that a change, Agile or otherwise, would immediately yield advantages. People must change just as much as processes, tools, or even structures for a transformation to be successful.

Ricardo Dinis

Agile Coach in Business, creating simplicity and improving growth

1 年

When a transformation takes a form of a project where you fulfill all the boxes seems that you're halfway on the wrong path. And there isn't a recipe to do a transformation... (if there is, take it like guidelines). Transformations are ways to improve WoW, and our vision and mindset toward what we are trying to attain. Very good article Ricardo Vercesi Picoto

Ricardo Vercesi Picoto

More and more focused on agnostic agility.

1 年

Thank you for the share Manuel Pais (Team Topologies) ????

要查看或添加评论,请登录

社区洞察

其他会员也浏览了