Managing Agile Teams

Is there a place for project management in Agile?

There is debate on the role of management in Agile and Lean projects - is there a place for project management in Agile? Well indeed there is because agile methodologies are in essence nothing other than a set of management frameworks.

What makes a good agile team/’s manager, development manager, chief architect, programme manager or whatever title they are given. The titles are a bit misleading so let’s not start not with a title. Instead let's use a job description to make it easier to decide where this manager fits into an agile framework. Putting the title to one side, the role we are looking at, is the one held by the person who is responsible for leading the team (or teams) to a product release.

They are the link to the customer, or for internal teams the link to the business. They are the ones who are pivotal in translating a business need into a product that delivers value. To them the team is everything for without it there is no product. This is not to say they do not serve the business as well. They serve both by communicating the needs of the business to their teams.

Below I will refer to them as development managers.

Negotiating

So now we know who they are let’s look at the tasks they have to perform. The main one is arbitration, they need to act as the umpire. Smoothing conflict starts by negotiating a path between the desires of the business and the teams who will deliver them. They need to be adept at recognising what desires will deliver value and which ones will not. Above all they work with people.

The development manager will be responsible for requirements elicitation, communication, delegation, facilitation, recognising and managing risk, team building and recruiting. They strive to protect their teams from feature creep, bad smells, anti-patterns. They make opportunities for code reviews, they also make opportunities to obtain frequent feedback.

When their teams have an internal difference it is the development manager who can help them choose the right option. To do this they use their advantages of:

• visibility of the wider picture 
• experience of similar decision points
• technical knowledge
• understanding of the dynamics of the team

They use all of these attributes to moderate the debate and assist the team to find the right solution.

The development manager needs to negotiate the scope of the work the resources required and the time frame to delivery. It is best to keep the scope to the minimum that is viable for value to be gained. Three fast and small but good releases are much better than one large one. The customer may want an all singing all dancing release and this will bring a need for negotiation.

I was involved in a start up business within the group of companies I worked for. The newly installed MD wanted an application with all the features and then some. Feedback was sought as functionality was delivered. He became insistent that without all features he would not accept anything.

He also chopped and changed what this set of features were. This was mainly a ruse to cover the fact that his startup had no traction and was not delivering any sales. While the team welcomed change they were getting frustrated by the apparently arbitrary shift from one thing to another. The negotiation winner here, was to deliver a small product that drove sales.

Development managers lead, they do not write code.

Some hold the view that a development manager should also write code, this is bull. They need to understand code, they need to read code, they will probably have written code but that should remain in the past. They may be a test engineer or a another type application expert.

They need to be technologically knowledgeable smart, aware, experimental and enquiring. They need to continuously improve their knowledge on the subject. They must like the users of the systems they are involved in building. They will have belief and be evangelical of agile and lean principles.

There are very good programmers who are not very good at communicating, the classic introvert. There are very good programmers who are extrovert and just love gassing away. There are those who may have been good programmers but have transferred to a leadership role. The development manager does not need to distracted by writing code good or bad. This is an activity they need to delegate.

Let the development manager leave writing code alone and concentrate on leading those who are actively programing. They will on occasion dip back into getting their hands dirty but they will do it as a scientist not as an engineer. The scientist experiments to find answers the engineer builds solutions.

The development managers interest in new technology may lead them to undertake empirical investigation. For instance they may pick a technology up, take it to hello world and beyond. In doing so they will evaluate the usefulness of different emerging technologies and trends. If these offers solutions they are in a position to introduce it to their teams.

 

The rules are there are no rules

There are rules that applied to the leadership however. Sometimes we referred to them as the non rules. These non rules were really just guarantees as to what the teams were entitled to expect. There were only a handful and all of them had the number 10 in them.

Developers are bad at looking after their own self development or seeking help. One non rule we had was the 10% rule. This was where 10% of the working week (3.5 hrs) is made available for self development. This half day study time was slotted in for learning a new skill or honing an existing one. Individuals pairs or small groups had time allocated for discovering new technology or soft skills.

The 10% rule included explorations into new hardware and processes as well as exploring new languages or trying out a new types of data stores. I have had to drag developers kicking and screaming into utilising this time. The development manager will play a valuable part in the quest to amplify learning.

The development manager will act as the enabler for self learning processes. They will take suggestions on what the team would like to look into further. As a scientist not a developer they may vet new developments in code or databases, they will benchmark and assess. They will prepare the ground for further experimentation and at the same time be pragmatic to avoid trendiness.

The development manager will set up the environments to run whatever the learning process requires. They will establish playground or find an online playpen. They will do a bit of research and sift through what background or resources are available to find the most useful sources. They may take it to ‘hello world’ and then hand over a curated environment to team members to evaluate and play with.

Another non rule was the 10 minute rule. if you are stuck on a problem for longer than 10 minutes ask someone for help. Articulating the problem would most often fix it. The first instinct of a development manager writing code will be to grab the keyboard and try fix the problem. Worse still they may take it on themselves to fix, deeming it too difficult for the skills of person who asked for help. Big mistake, people learn nothing from seeing someone else do it. They learn from discovering how to do it themselves.

Respect

The development manager is not hands on, they are there to help. Leading a colleague to a solution is helpful. Encouraging them to see through the problem and to find a solution for themselves is even more helpful. If the solution is beyond the skill and knowledge of the development manager all well and good. They can research, learn from the team or simply note that this team member has the answers up their sleeve.

The team will respect the manager for not talking down to them and for enabling them, for supporting them and for encouraging them. If they have to write production code they will not have the focus or the time to give enough to their project team. Their project teams will need them focused on the team’s needs and on the needs of the business.

It is said that the team will have more respect for someone also writes code. My experience shows this not to be the case. The last thing the team needs is a part time coder nostalgic to get their hands dirty. They will not respect the coder who is their on the presumption they are a better coder than themselves.

If the development manager tries to multitask the they will resent the time they are not writing code. They will be distracted, they are not delegating. Their teams will resent not having the support they need. If their background was testing or infrastructure engineering or application training there is possibly less temptation for them to get their hands dirty. Yet the focus must be on the team and the product not their history.

The reasons development managers manage is to best serve their teams. It is not to establish a management centric culture. It is not to build hierarchies it is to help, assist and make their team’s lives easier. Management is providing opportunities for their teams to excel, improve and learn. To deliver value to the customer. It is acting as a link between the stakeholders and the production teams.

 

Style

I have been responsible for quite a few development managers and they each have their own style yet they all share some stylistic attributes. They all demonstrate clearly and openly the trust they have in their teams and the individuals within them. They are comfortable in one to one discussions with team members and in group discussions. They all have two ears and one mouth. That is they listen more than they talk.

They also appreciate the style of their teams and its members. The recognise the learning styles of the individuals in the team and are then able to adjust how they deal with the individuals by adjusting their own style. The can also use this knowledge to adjust the team to make it rounded and get a good mix of personalities. With insight into style the team dynamics can be optimised.

Flavours

Style also covers the type of agile framework that is best for the team. Some teams will naturally go for one or other methodology. Some will craft their own. It does not matter too much if all teams follow the same methodology. It demands even more agility on the behalf of the development manager if they all use different frameworks. I would advise against imposing a framework, let team find one.

The team should decide what style of working suits them the most. XP, FDD, Scrum, Kanban, Lean etc. all have agile principles. These main frameworks have enough core tenets on which to build an agile way of working. Agile methodologies need to be agile in themselves, I find Scrum the least agile of all the ones listed above yet it is popular.

Rules v’s culture

All agile principles propose that teams should be self organising and that they should be empowered so let them choose, develop or mutate their own style. In other words a style should fit around the team. The team should not be fitted into the style.

The need for esta­blished boun­da­ries will still exist. It is important to remember this is not the wild west. There are boundaries, anarchy is not to be encouraged, anti patterns are taboo, risk is to be avoided or mitigated, best practice must prevail.

The best way of ensuring boundaries are drawn within the territory of best practice and excellence is to develop, instill and then continue to influence the culture. A development manager will; add to and play a big part in forming the culture that their teams operate within. Cultures need to be built, modified, reinforced and nourished. A culture will contain processes, techniques and patterns.

The culture is what transmits a vision of desirable beha­vior when a system of dictats and rules are not appropriate. A culture where the desire to, empower the team and trust motivated people to do their jobs, is a good replacement for rules. A self organising team establish and introduce best practice. A culture that encourages continual incremental improvement builds integrity into the product.

The structure of communications

Regardless of which agile framework is used the development manager will need to ensure that they have some core processes available and followed. Regular communication being perhaps the most important of these. The XP standup can be held sitting down as long as is not around a table and it sticks to a time limit. The idea is to keep the meeting short.

I found splitting the traditional daily meeting into two daily meetings quite useful. I named these meetings morning prayers and evensong. Daily meetings can be done remotely using any conferencing app that has text and voice or better still text, voice and video.

Daily meetings

Morning prayers were as the name suggests in a morning after everyone had settled in. It was allocated set duration of around 10 minutes (a minimum of 5 and a maximum of 15). It was used to discuss what each member of the team was going to achieve that day and what resources or dependencies they needed, e.g. a test instance on the server, dependencies, a clone of a database or clarification on how a feature should work.

Problems discovered in the stand are then taken off line to be resolved. The purpose of the meeting is to bring issues to the attention of the development manager and identify blockers. It is not desirable to try and fix the issue in the meeting. Once identified the development manager will allocate the resources to remove the problem.

Evensong was an hour before the end of play, the same 10 mins allowed team members would cover what they had actually achieved. By this point it the day everyone has a good idea of what progress they have made. It also everyone a chance to reflect on what they have done. It did this while there is 45 mins left to maybe, check over work done, remove some technical debt, clean it up and better still share it.

If the level of work completed was not what was expected to have achieved it gives a chance to point out what the blockers are. It gives the team and the development manager an opportunity to plan the work for the following day. It provides information for the planning process, updating release schedules and the road map.

Periodic meetings

On Friday afternoon there is an additional ceremony, a sort of special mass, and it has a party feel to it. Wine and bread are imminent at the review theatre. The Friday review allows everyone to put on the finery and parade their work to each other, to other teams, to the customer and to the business. It is the place from where feedback emanates. It is pat on the back time.

Friday demos might not be actually held on a Friday. They could take place anytime when the appropriate stakeholders are available. For the development manager it is a time for pride and praise all round (hopefully). For the team it is a chance to view integrations and deployments in situ.

Retrospectives

I read somewhere that retrospectives should be at the end of an iteration. If that were the case the iterations are too long. Continuous deployment encourages short iterations. Sometimes these are daily and it is possible to have multiple iterations completed in a single day. There is no need to have retrospectives daily. A retrospective is an opportunity to change the way we work and this is not a daily task.

Some functionality may not lend itself to such short iterations and the length of iterations needs to be kept to a minimum. If long iterations become frequent it is time to look at other ways of building a product. The architecture could be wrong and a design that increased the number of services may be a better solution. Ever smaller iterations are not the end of reflection or retrospectives. That dear old mantra:

• What have we done well
• What do done badly
• What should we stop doing
• What should we start doing

is a set of questions that still need to be asked periodically and can really be asked on any occasion. This reflection is the root of the retrospective process and may be done in at some depth. It can take place alongside or within a code review. Natural time periods between retrospectives will appear, as will natural break points in production.

Location

It is important to have the right location, the team must be away from their desks and not on a computer. There were times I gave the development managers my office to hold these meetings. Too many teams and my having no office put paid to that.

The location needs to have a whiteboard, it is good if it has a large monitor. I incorporated informal areas where these meetings could be held. They were also where we sometimes met with stakeholders. They were not formal conference rooms nor were they held sitting around a table.

…

 

Originally published on September 16 2014 It was based on notes published on an internal company blog and relates to the development managers at that company.

With recent events reminding me that once again British cycling is a beacon for teamwork and continual incremental improvement. Derived from Dave Brailsford's framework of the "aggregation of marginal gains" where individuals are charged with breaking down and improving individual elements of their technique and ability seeking to improve their overall performance, the British team taking 12 medals at Rio is as good a place as any revisit strategies for success.

It is not intended as a formula or a prescription to follow. It is an simply an example of how this management role has worked in the past. I was lucky to have a couple of star managers grow into this role, one came from a technical product training background the other from a testing background. Both knew enough about code to understand it. Both were astute technologists, both embraced continuous improvement and continuous integration. Yet the reason they were both stars was because they were very people focused. They also liked users.