Should managers be involved in decisions about what technical practices the team adopts?

Question

With the popularity of agile methodologies on the rise it comes the time to make decisions about what it means to be done with a given feature/task. Should the managers be involved in the decisions about which technical practices the team should or should not adopt? Examples of such practices are:

• Test driven development (TDD)
• Pair programming (PP)
• Continous integration (CI)
• Continuous delivery (CD)

A common objection to adoption of such practices from a managerial point of view is that they "make the progress slower." I'm not trying to imply micro-management is bad per se, but in modern times it has gained a negative connotation since the rise of trends like empowering your employees and the fact the a lot of people perform better when they are given more autonomy over their work.

Is there any framework that deals with the question of when managers should micro-manage and when they should not?

Answer 1

This is an interesting question, worded well (thanks @CodeGnome for editing) and highly relevant.

Unfortunately the answer is, like many questions regarding ideal practices, a firm "it depends".

It would depend on the

• Nature of the Development Team
• Existing Practices
• Organisation Culture
• Exact type of Agile implementation
• Individual personalities

Management are imposing practises upon the team

I would draw out two considerations;

Appraisal Targets

A manager imposing particular types of technical practices may be forced to do so by an inflexible appraisal, bonus or review process.

Our organisation (and I suspect many Fortune 500 / FTSE 100) are committed to Continuous Improvement programs which mandate a CI target to be hit as part of the employee or department objectives. Therefore, regardless of our Retrospective or team decisions CI is a mandatory aspect of our work.

Matrix Management

The situation can be complicated when the ScrumMaster, leading Sprint Retrospectives to improve team practices on behalf of the team can butt heads with the Line Manager of the team members because they feel like they own the working practices of the team and also write the appraisals.

I wish I had a fuller answer for you but I don't; it is a very tricky ledge to navigate.

If the team wish to adopt practices and management are challenging

My Approach

I have banned any management from the Sprint Retrospective (even if they are part of the Scrum Team) and capture all of the feedback confidentially producing a highly sanitised Retrospective Report (less than 1 page). Normally, supported by the team, I unilaterally impose changes to the working practises of the team without speaking to management.

A Scrum version of "Ask forgiveness, not permission."

The team like this, it demonstrates the ScrumMaster will fight on their behalf and take the fight away from their work location and the truth is most managers are too busy to actually notice the micro-changes. It took the upper management 3 months to realise we had binned velocity completely from the Kanban Board and reports.

Selling Practices

If a change is going to be a major undertaking and unlikely to fly under the management radar I would take a data-driven approach producing a Proposal which contrasts the current practice with the old specifically drawing out the benefits. Since Management never read it I also distil the proposal into a PowerPoint.

Normally any proposal would be backed up by a number of Lean Six Sigma models to demonstrate the benefits of the new approach. Managers respond to savings in time and/or money. If you can demonstrate that I don't think you will have any problems.

Answer 2

Consideration should be given to the nature and size of the organisation, and the number of projects / initiatives being run. If the team is likely to flex significantly in terms of the people working within it, and if there are several (or many) teams all working on different projects, then it may be necessary to consider the reality of having people moving between teams and having to adapt, if each team is allowed to agree its own approach. If this is a genuine barrier within your organisation, then you may need some sort of management direction to be given.

Also, if the wider organisation is not geared up to accommodate continuous delivery (or similar) - for reasons of complexity, size, training, or a requirement to comply with external regulation (such as a highly regulated industry such as financial services), then again, there may be a requirement for management to lay down standard approaches that must be followed.

You ask whether there is any framework that deals with the question of micro-management. I am not aware of any, and I would make two points here:

1. This is not necessarily micro-management, and if done carefully, it should be the strategic management of acceptable approaches that are relevant for your organisation. There may be good reasons why an approach may or may not be acceptable (as discussed above), and the role of management should be to consider these and make decisions on there appropriateness, then allow the teams to adopt which ever they feel will work for them. If the teams want to bring new approaches to the organisation, they should seek approval for them, then, subject to approval, get on and use them.
2. I would not advocate micro-management as a general rule, especially if the teams and the team leaders are sufficiently mature in their thinking and experience to work effectively without managers breathing down their necks all the time. However, I have also experienced situations where teams don't work unless their managers are checking their work and their approach on a daily basis, in which case you have a different problem to fix, which is much wider than just the approaches to carrying out their tasks.

Answer 3

Always. You said the word "involved". Involved - yes. Dictate - no.

One of the most often unseen aspects of a successful Agile development project is that the team is one cohesive team. Not the technical team and not the business team, but the singular Team. Everyone has a stake and everyone has a say. If I was to ask a different question, how would you respond? Should the software engineers have a say on the launch date? The answer is of course yes. Ten years ago with Waterfall this wouldn't be true, but today with Agile the key aspect is to allow everyone a say. This doesn't mean that everyone needs to be involved in every detail, but rather that everyone is striving for the same thing - a successful project - however that is determined by the cohesive Team.