How to run an effective agile team within a rules based organisation

Question

How to align an Agile team's working agreements within the boundaries ("rules") set by the organisation.

e.g. manager says you have to be at work at 10am and can only leave after 5pm. you have to email the manager before working from home.

Has anyone got experience with this type of 'rules' based organisation which still considers their teams agile?

My objective here is two fold:

• Work with the organisation to improve their approach. Should they be setting rules? Is there a better way of setting these boundaries for the team?
• Understand what is best for an agile team. Should they define when and where they work? etc.

Update: I guess what I am trying to figure out is how can a team be autonomous if you are telling them where to work and when to work.

Google, for example, lets the developers work wherever and whenever as long as they deliver. So I guess I am trying to achieve too much, but I want to know: is it possible to make delivery of working software the expected output without being super rigid about when and where the team works?

Answer 1

I think I can provide a better answer if I rephrase your questions a bit.

Q. First, is it necessary or beneficial to have rules that apply across multiple (or all) teams?

A. Yes. While consistency across all rules and practices is not necessary, there will be plenty of rules that work best if there is a common agreement. The work hours is a common example. It's hard to have face-to-face communication if you never see people. There are other common examples like code and architecture standards that are only really effective if all teams follow them.

Q. Do those rules have to be set by management.

A. No. Many organizations allow teams to negotiate and create those rules.

Q. Is it healthy for management to set those rules.

A. It is not inherently dysfunctional. However, the problem you run into is that the further up the chain you go, the further away from the work you get and the rules can become detached from the needs. It's also important to remember as you go up the hierarchy, the rule is often applied with a broader brush - sometimes much broader than needed. We've probably all worked someplace where rules applied to us that were important for some other team, but were either irrelevant or detrimental to us. Those are usually rules made far up the hierarchy.

Q. Are all teams able to handle that autonomy?

A. Short answer is yes. There's no research to indicate that any team can't potentially be autonomous. However, some teams need help getting there. David Marquet has a concept called The Ladder of Leadership that is all about helping teams effectively transition from kicking all decisions to their manager to being fully autonomous. There's a neat guide in the form of a printable leadership exercise here.

Q. If we have organizational rules made by managers and other leaders, are we not Agile?

A. Every environment has its constraints. If you have a core working hours rule in your company, then you work with that. There are many ways you can become more agile within almost any ruleset. Challenge those rules when they pose real obstacles for improvement. I wouldn't try to challenge them all just on principle. Even in Scrum, where it does have some things to say about the team, there's nothing in the Scrum Guide that says they have to be 100% autonomous with no outside rules applied upon them.

Answer 2

I guess what I am trying to figure out is how can a team be autonomous if you are telling them where to work and when to work.

Autonomous always means "autonomous within constraints". Agile doesn't mean "developers get to do whatever they want."

"Let[ting] developers work wherever and whenever as long as they deliver" sounds more like Wild West individualism than team-oriented Agile, to me.

If there are opportunities for developer movement within the org, or requirements for coordinated work, then abiding by the org's expectations for work hours & locations is in the best interest of the team.

If my team were very unhappy with the situation, AND believed that they could increase their velocity if they were granted an exception from these rules (which, don't forget, there's a potential social downside within the org to being the "special team" that doesn't have to play by the rules), then I would do the following:

• work 4-6 sprints abiding by the rules. Be sure to track your velocity.

• quietly take note of any relevant issues that come up during the retros, both positive and negative. (I say "quietly" because you do not want to contaminate your data.)

• at the end of this period, review the results with the team. Show the velocity. Share the related items that came up during the retros. Ask whether, given all that data, the team still feels they could increase their velocity if they were exempted from these rules. Ask for a fist or five vote.

• don't forget the Product Owner or equivalent is part of the team for all these purposes.

If you get a strong consensus, then I'd go to management, present my data (including related retro items), explain that the team felt we could increase the velocity if we were exempted from these rules, and ask for a 3-4 sprint period during which to do the experiment.

They might say no. Then you gave it your best shot, and the team has to live with it or go find other jobs.

They might say yes. Then you get to do the experiment, and see if it proves your team's hypothesis.

They might give you a conditional yes: eg, you still have to comply with some of the rules, but you get more flexibility to do the experiment. Then you can go back to the team & see if they still think they can increase velocity under those circs.

Most importantly, make sure nobody's gaming the system. IE no slacking off during the control period, or heroics during the experimental period.

And then you'll see what happens, instead of being caught up in trying to prove that management is wrong. ;)

Answer 3

Should [the organization] be setting rules?

Of course they should be setting rules. "Don't embezzle" and "Don't punch clients in the face" are both rules. You're not really asking if organizations should set rules (I hope). You're asking where the line should lie.

Is there a better way of setting these boundaries for the team? [...] Should [the team] define when and where they work?

It depends.

Have you asked the organization the reasoning behind this particular rule? Maybe your job is expected to include call support, so hours are non-optional. Maybe they expect you to slack off if no one's around to monitor you. Maybe they have a certain process (good or bad) in HR that necessitates this. Maybe they've been doing this for 50 years and no one remembers why.

Some of these reasons are valid, and thus you should accept them. Others are less so, so you should work on convincing the organization to improve them.

To do so, you'll need to convince them how and why making such a change is in their best interest.

Answer 4

In this example, when you say Agile, that can mean a lot of things. If you're using an Agile framework such as Scrum, these constraints can be addressed rather effectively.

Generally, if a team must work within the constraints of existing organizational structure, including these constraints in a team work agreement is a good place to start. If there are technical constraints that require work items to meet a certain standard, including those standards in your team's definition of done is advisable.

Agile teams (Scrum Teams to be specific) advise co-location to increase visibility and transparency into their work, so this constraint sounds like it may be helpful for that purpose. Co-location is a proven method for collaboration and team problem solving as it encourages a team to tackle problems together in the same workspace.

If/when these constraints come up in a sprint retrospective, I advise in gathering feedback for the purpose of promoting them throughout the organization for review and negotiation.

The Agile Manifesto does value Individuals and Interactions over Processes and Tools. Keep that in mind when approaching work in an environment that has embraced Agile values.