Being Agile while not really being agile  - How frequent disruptions can derail organisational Agility
Adobe Photoshop | Ashlar Creatives

Being Agile while not really being agile - How frequent disruptions can derail organisational Agility

Lets apply the first principles approach and acquaint ourselves with the word - AGILE

In English ‘Agile’ is defined as: “Able to move quickly and easily.”

Simple enough, right?

Not so, even this simple 6 word sentence holds a key component that’s hidden, which now means that we need to scratch the surface and delve deeper in the ‘move quickly & easily’ part.

If you have ridden a two wheeler, bicycle or a bike doesn’t matter but for the sake of argument, let’s assume you are very adept at riding a bicycle. What does it take for you to ride it over an uneven surface?

Close your eyes and envision this scenario - You’re riding the bicycle and come across a patch on the road with loose gravel and pot holes - What do you do?

1.???? Go around it?

2.???? Go over the rough patch of the road?

?

Regardless what option you pick, in both cases ONE thing remains common – You’re balance is maintained, your reflexes are quick enough & you know what to do and how to do it.

WHY?

HOW??

Simple – Stability!

1.???? You’re familiar with the cycle and understand how to manoeuvre it through the uncertain road

2.???? You’re confident about your skill and are able to decide well ahead on what course to take keeping in mind point 1

It’s the Stability that comes with the above two that ensures that you’re able to make it through a rough terrain.


So how is this connected to Agile, again? Let me draw some parallels.

·????? You, the rider, are the Leadership (SM/PO), armed with the knowledge of Agile – well versed with the mechanics of manoeuvring.

·????? You’re barrelling ahead iteratively with your team - The bicycle.

·????? And you understand their capabilities sprint on sprint – Familiarity with the capabilities of the bicycle.

?

Unless your Scrum team and/or the Leadership is STABLE, not only in composition but also in the implementation and understanding of Agile practices, you will always be in a state of Disruption!

?

Broad Instances of disruption:

1.???? The team is shuffled where team members are moved about often, sometimes several times within a years’ time!

2.???? Leadership tends to change often owing to organisational re-structuring etc who then tend to re-focus strategic objectives that affects the work being done by the team

Such frequent disruptions bring the scrum team in a situation wherein its almost like taking two steps back to move one step ahead. While you, as a Scrum Master, have been spending your time and energy building trust and rapport, the moving away of the team members/leadership/stakeholder only leads to re-investing time from scratch with the new people all over again.

And what comes with new people joining in? – Their own perspectives/beliefs/understandings about how Agile should be implemented, new areas or a modification of the areas of strategic focus etc, change in the work being done etc

So, what now?

Its important to never lose sight of your North Star – Core Agile Principles


Here are some ways to mitigate the effects of such frequent disruptions:

1.???? Prepare an on-boarding document –

a.???? It need not be an excruciatingly detailed and lengthy document just a one-pager should suffice

b.???? Enough to let the new person know the ground rules of the squad/hive and helps to clarify the basics like cadences, tools etc the rest they can assimilate while on the job

c.???? The core idea is to ensure that the basic practices and expectations are clear and forms a solid base for the member

2.???? ‘T’ shaped skill development through knowledge sharing –

a.???? If a team is under frequent disruption then its crucial that the members are skilled in more than one area of execution

b.???? A programmer should also be able to do QA, for example; this way while the core skillset is a strength, an auxiliary skill helps the team to hold the fort and minimise dependencies when the team is short of resources

3.???? Standardize core practices –

a.???? Establish a core set of Agile practices that remain consistent across teams. This provides a foundation for collaboration and reduces confusion and friction

4.???? Harness the power of Retrospectives –

a.???? Regularly conduct retrospectives to identify areas for improvement, even with new team members

b.???? This fosters a culture of learning and adaptation. Use this forum to ensure everyone is on one page at all times

5.???? Transparent communication –

a.???? Maintain open communication channels with all stakeholders & leadership about team changes and their potential impact on projects and set clear expectations accordingly

b.???? Often times such changes don’t necessarily lead to positive and happy outcomes but sugar coating it or, even worse, downplaying the impact WILL come back to haunt you later!

6.???? Leverage technology –

a.???? Utilize collaborative tools and platforms to facilitate communication, knowledge sharing, and project management

b.???? Ensure that teams have a running commentary on their tickets and use tools such as JIRA/ADO etc as Single Source of Truth regarding work progress etc and avoid using emails for such updates/record keeping

7.???? Invest in Agile training –

a.???? Provide ongoing training and coaching opportunities for team members to deepen their understanding of Agile principles

b.???? Here again the Retrospective is a good place to leverage such opportunities to fine tune on what’s the need of the hour

Above all, Be there for the team!

While the team executes, it’s the Scrum Master that they will look up to; to help manage disruptions and set priorities.

Be the Rock, the solid foundation that your team can take refuge in order to weather the storm!


sumanth kumar

Scrum Master at Altimetrik

1 年

agile should always be a push system not a pull system

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

Shishir Rattan的更多文章

社区洞察

其他会员也浏览了