Blog Feed Post

Setting rules of engagement for scaling Agile

I like the daily stand-up meeting in scrum. The rules are clearly laid out. 

Each team member is supposed to speak just on 3 things - what they did yesterday, what they plan to do today and impediments, if any, in their way. Team members are encouraged to be brief and to the point. The entire meeting is not supposed to go beyond 15 minutes. 

World over though, managers are moving away from a "command and control' approach to management to a more hands-off, goal oriented, decentralized and empowered way of management. They talk less about "how" and more about "what". One of the 12 principles of agile software development is that "the best architectures, requirements, and designs emerge from self-organizing teams". In fact the word "manager" does not exist in agile lexicon. The more accepted word is "servant leader". 

In fact, a scrum team is supposed to be a self organizing team where the team is supposed to decide how they will go about achieving their time boxed goal. Viewed in that context, the rules regarding the daily stand up might appear to be interfering with the independence of a scrum team. But the fact is that unless you set this rule a 7 member scrum team can talk about 700 things in a stand up meeting and still not achieve the primary objective of updating themselves about the progress made.

What often gets missed in this discussion is that while managers should and can shun "command", they cannot shun control. While they are not supposed to control how the team members go about achieving their time-boxed goal, they still have to control the larger ecosystem in which they operate and in which other similar teams operate. This becomes all the more critical and challenging when organizations are trying to scale agile and large number of teams are involved. Please note that a rule is also a "command", not one which has to be blindly followed but that can be debated, questioned and if required, changed. It is the degree of prescriptiveness and rigidity in a rule which needs to be modulated. Do daily meetings, do daily meetings for 15 minutes, do daily meetings for 15 minutes where each member talks atleast for 2 minutes - these are all rules with increasing degrees of prescriptiveness. The general recommendation is to be less specific and provide more room to interpret and apply a rule in a given context.

Just like the rules of a daily stand up meeting, program managers / master scrum master / master orchestrator have to define similar rules of engagement for the various entities who are part of the scaled agile ecosystem. 

Below is a simple scaled agile structure and the 8 areas of team interactions - both intra and inter teams. Of these most critical are 1, 2 and 5, as explained below. 

Between Scrum Teams

This is the most critical interaction happening in a large agile team and probably the weakest link. Whether scrum teams are working on different features or epics, there will be dependencies between them. They need to communicate and collaborate amongst themselves but at the same time maintain their individual team identity and focus. A dependency map should be created and kept updated. In my experience, just like the daily standup which happens within the scrum team, a daily dependency standup should happen between the scrum teams to quickly talk about 2 things - a. Is there any change in the dependency map (add, modify, delete) and b. Any inputs either team needs from the other to proceed with their work. Keeping the discussion focussed on these 2 points will ensure that it is short and effective. 

Between Scrum Teams and the SME/Shared Resource Pool

Architects, UX experts, performance and security testing experts, database / network designers, etc., are important players in a development team but their relative workload is less compared to the actual coders and testers. This mix will obviously vary depending on the specific needs of a project but whatever it is, there will always be roles who are better off being shared amongst the scrum teams rather than being dedicated to one. 

Different scrum teams will reach out to this shared pool for various requests and if this is not controlled, it can quickly lead to chaos. In my experience, maintaining a common SME request log which is accessible to all the scrum teams helps in prioritizing and utilizing these resources more effectively. Keeping an oversight on what kind of requests are coming in from the various teams also helps in deciding the right mode of involvement for the SMEs (dedicated or common communication sessions). In many organizations and projects, some of these SMEs become part of a 'hardening' sprint which occurs after every 3~4 development sprints. However, a hardening sprint is more for review and validation rather than design which is more of a continuous process in agile. 

Between Scrum Team Members

The conventional wisdom is nothing within a scrum team should be controlled as it is supposed to be a self organizing team. Agree. However, what do you do when you see a dominant personality within the team adopting a command and control approach towards the other team members - the very behaviour we want the team to be shielded from? How long do you wait when you see a team perenially in the "storming" state? Then there are questions whether the team gets to choose its members or are they assigned by somebody? What do you do when you see issues related to committment, motivation, integrity or skill? Do the teams self assign features / user stories or are they assigned by somebody? Unless the operating rules around these decision points are well laid out, they will be personality driven - not a good recipe for scaling. 

Master scrum masters / equivalents have to set these rules of engagement upfront. Instead of going as commands, they should go as proposals - which can be debated, questioned and changed, if required, but finally collectively agreed to. 

Read the original blog entry...

More Stories By Sujoy Sen

Sujoy is a TOGAF Certified Enterprise Architect, a Certified Six Sigma Black Belt and Manager of Organizational Excellence from American Society for Quality, a PMP, a CISA, an Agile Coach, a Devops Evangelist and lately, a Digital enthusiast. With over 20 years of professional experience now, he has led multiple consulting engagements with Fortune 500 customers across the globe. He has a Masters Degree in Quality Management and a Bachelors in Electrical Engineering. He is based out of New Jersey.