Since I take Agile to task here for not engaging with team related problems, I feel bound to pontificate based on my own experiences.
It's perhaps worth noting that the whole idea of a 'Team Lead' or 'team leadership' is somewhat alien to the Agile way of thinking. Scrum, for example, has no formal role of 'team leader'. Neither the PO or the Scrum Master are team leaders in the traditional sense, although between the two they cover many team leadership responsibilities.
However, what the Agile principles actually seem to be getting at is a rather more subtle, even political, perspective - namely that there should be no team leader imposed on the team. This is Principle 11, self organising teams. What I've found in practice is that the developers often do have an informal leader, even if it is only a 'spokesperson' or 'leader-by-default'.
Of course, these ambiguities complicate the whole idea of team building, which would otherwise revolve around the duties and responsibilities of team leadership. Nonetheless, it is certain that teams do not spring into existence of their own volition.
So I'm going to assume for the purposes of debate that even in an Agile environment there is at least a role that corresponds to team leadership, even if the duties of that role are spread across more than one individual.
I've found that team building and leading tends to revolve around three topics, which I refer to as the 'three P's ', namely :
You will never have a perfect team. The challenge of team building is not to build the perfect team, it's to build a high-functioning team that can overcome the imperfections it will certainly have and deliver the regular, predictable, stream of high quality increments that is the objective of Agile.
Doing this requires acknowledging the differing abilities of team members, the different motivations that they will have, and the different career objectives they will have. This is not meant to suggest that a team leader should just shrug their shoulders and accept the status quo whatever it may be - that's obviously not in the spirit of Agile, with it's emphasis on Inspect and Adapt / Continuous Improvement.
However, it does mean that getting the best out of people can't be done without relating to them as individuals. Simply demanding that everyone on the team should do whatever it takes for the sake of the team is chickening out - it's your job as a team lead to do the work that will allow you motivate each individual on the team, and give them the confidence and ability to communicate effectively with each other.
The concept of having the 'right' people is also challenged by the fact that teams are dynamic things - people will leave, people will join. If you can create or leverage a strong team culture, this can help to minimise the impact of such events, but again the emphasis for team building is on acknowledging that people are different, and you will not normally be able to simply drop a new team member into an existing 'hole' and expect things to work exactly as they did - the team must, to some degree, adapt.
Team members should understand that they have an important role to play when this happens - they should be open to change, because it's likely to be required.
My belief is that, in Scrum, much of the responsibility for the things I talk about above falls on the Scrum Master. But not all. The Scrum Master is there to help the team, to educate the team on certain matters, but cannot dictate to it. Developers must ultimately recognise their responsibility to act as a team, and so they need to have, as individuals, some appreciation of what this means.
'Have you got enough people ?' The situation in which this question usually arises is where the business is seeking ways to increase the amount of software delivered in time T. It's a deep seated 'Mythical Man Month' - style perception of the relationship between 'workers' and 'work'.
My take on this from an Agile perspective is that yes, I can increase the overall rate at which stuff gets done, but :
Firstly, to use an 'Agile Estimation' concept, a mature team will have a velocity - a rate at which it can do stuff ( note the caveat described in more detail in the Performance section below - velocity does not measure the rate of business value delivery ). There is the question of whether adding people to a mature Scrum team will increase it's velocity. This is not an easy question. In fact there are two questions - is this the best use of additional resource, and if resource is used like this, will it work ?
If a Scrum team has identified a specific capability gap that is holding them back, and this gap can be plugged by adding a suitable person, then the answer to both questions is probably yes.
As an example, take test automation. If the team would like to automate more of their tests but doesn't have the skill set to do it nicely ( or at all ), that would be a capability gap that could enhance the team's productivity if it could be filled.
But if the team isn't aware of any such gap, then the disruption of adding an extra person just to increase the man-hours will be counterproductive in the short term, and from a long term perspective that person might be better used in an entirely new team.
Secondly, asking that team to deliver more stuff than it's velocity allows is simply a mistake. I've encountered a situation in which a PO wanted to 'challenge' their team to deliver more story points in the current sprint to 'make up' for missing some last sprint. The Scrum Master should be very careful to knock this tendency on the head.
From the empirical perspective that Scrum values so highly, asking a team that delivered X-N story points last sprint to deliver X+N this sprint is nonsensical. And from the team's perspective, it looks like a punishment - miss some points ( which will knock back the teams average velocity anyway ), and you get even more to do next time, making it more likely that you will fail, and so on.
If the business needs work ( measured in story points or whatever ) to be done faster than the sum of the velocities of it's existing teams, then it's highly likely that it needs more teams. That needs forethought and careful planning, it's not a tap that can simply be turned on. Key to this planning is the question of structuring the work so that teams are actually working together effectively ( doing 'the right' work, as I put it above ), and that requires strategic thinking that is beyond the remit of any individual team.
It is possible to have too many people on a team. The problem that defines the effective limit is communication. In the limit, if you assume that everyone on the team must communicate frequently and closely with nearly everyone else on the team ( that is an Agile assumption ), then those communications scale geometrically with the number of members. Scrum suggests a limit of 10 people for a team. Even that is challenging.
If you relax the communication constraint, or change the communication pattern from meshed to hierarchical, then you can have more people on the 'team' - but at some hard-to-determine point, it will cease to be an Agile team.
Agile is entirely, and probably intentionally, silent on the topic of personal development. Individual developers are rarely so silent. No single topic ( including salary ) has, in my experience, been more often cited as a source of discontent.
Now perhaps my experience, a lot of which has come from working for consultancies, is biased. Consultancies do not want their employees doing training when they could be doing paid work, and they do not want to pay for training when the employee is not engaged on a project and hence can 'train themselves'. Ahem.
Clearly a business will only ever want to spend money on personal development where it sees a potential productivity ( or perhaps staff retention ) advantage. Also, in a growing business, it is likely to be cheaper if you can fill new higher level roles from within, so having people who can step up is useful. But not everyone will fit the bill. The team lead can play an important role by working with team members and the business to identify such cases.
Individual team members also need to take responsibility here, and if some particular training would enhance the team's productivity then they should feel confident enough to make that case. Such training need not be technical - for example, time management or communication skills could also help to enhance productivity.
I have a very particular and specific view of how Process should fit in to the life of a developer or development team.
Very often, Process is viewed as a bounding box or set of constraints on how a thing shall be done. Developers frequently chafe at such things, because they believe can see how it might be done better, or even not done at all.
It's hard for me not to have sympathy here. It's normal for developers and development teams to have no control over many of the processes they must comply with, whose purpose is not directly related to development, or was defined eons ago using some no-longer-relevant set of conditions or assumptions.
However, developers are spending the business's money and interacting with other parts of the business and with the business's customers, so a certain degree of formalisation of these interactions is inevitable for similar reasons to those that a developer would give for formalising a communications protocol or API.
What are most important for developers though are those processes which do relate to development. The key here is to view those processes not as bounding boxes, but as assistive tools. Processes relieve you of the need to reinvent the wheel. They reduce the risk that you might forget some key but obscure thing. They can capture a shared understanding. Viewed in this way, processes are, or should be, enablers not overheads.
A consequence of this 'tool' view is that tools need to be kept sharp by suitable maintenance, and you must use the right tool for the job. If developers are empowered to do this maintenance, and select process as appropriate, then much of the 'burden' of process compliance falls away, and instead process becomes a support for enhanced productivity - it actually makes life easier.
However, if it is a PITA to change a clearly deficient process, this is a strong demotivating factor, and may well spill over as a negative attitude to processes in general. This is a drum that team leaders should beat - appropriate process is Good, inappropriate process is positively Bad, and the business should recognise this by building the ability to adapt processes into it's process framework.
Suitable process also has the effect of making things repeatable. Without repeatability, analysis of performance ( knowing what level of performance you are actually achieving ) becomes much harder.
Performance has many dimensions, perhaps too many to really be treated as a single topic. But from a team building/leading perspective, there are some obvious ones :
Productivity is tricky 🙂. For the sake of argument here, I'm going to say that 'productivity' means 'the rate of delivery of business value'. In Agile, the 'unit of time' for value delivery is the iteration, which in Scrum would be the Sprint. So the business is essentially seeking to optimise value per sprint.
My purpose in this section is not to write a treatise on Agile Estimation. Books have been written on the topic ( and new ones will certainly be written ). What I want to do here is to talk about the roles and responsibilities of Agile team members, as they relate to productivity.
In a Scrum context, deciding the business value of the things on the product backlog is the PO's responsibility. Whether she does that in abstract terms or by assigning an actual $$$ amount is immaterial. This is definitely a 'leadership function', whether it is done in a Scrum context or not, but it is a commercial function, not a technical function. It will usually happen in consultation with various other parts of the business, and over an extended period of time, and it's one of the things where the PO needs to be 'ahead' of the developers. In a Scrum context, there's relatively little direct assistance that the Scrum Master or the developers can provide here, beyond just talking about the product.
Clearly the more work that developers can get through in a sprint, the more value ( on average ) can theoretically be delivered. So to state the obvious, all team members ( including developers and non-developers ) have a responsibility to ensure they are working effectively and efficiently, both as individuals and as a group. Here is where it starts to get complicated 🙂.
Scrum's view is that a team has a certain capacity for work, and that it is the responsibility of developers to choose tasks that will fit within that capacity, but it says almost nothing about how that capacity is measured or determined, or about how tasks ( product backlog items ) should be assessed/scaled to determine whether they will 'fit' into a sprint. The Agile Manifesto is no help here either.
If there is only one team to consider, then this is simply an agreement between team members. Leaders and developers may have relevant experience to bring to bear. Many techniques and variants of techniques are available. Rolling your own is allowed.
However, this is rarely what happens in practice in an organisation with multiple teams. Usually an organisation will determine the techniques that it's teams should adopt, since having common understandings and processes across an organisation has many benefits.
A commonality amongst these techniques is the idea of an abstracted unit of scale for a task. The history of Agile estimation is almost literally littered with variants on this theme, which should tell you that the label used for this unit is irrelevant. I will refer to 'story points', but some people will refer to 'Gummi Bears'.
The really important point, and a key developer responsibility, is that over the course of several iterations they should endeavour to converge on a shared understanding of what 'one story point' means for their particular team.
The team focus here is key. From the point of view of the outside world, it's the team that delivers value, not an individual developer. So it's not meaningful to estimate the task as if it were you, as an individual, who had to do the work. The team has to do the work. This is one reason for trying to get away from estimating the size in terms of man-hours - at the point of estimation, it's not any particular man's job.
I've referred already to the 'v' word ( velocity ) in the above section on People, but I need to address it here too, because velocity is sometimes mistaken for a measure of, or proxy for, productivity. It absolutely isn't.
It's critical to note here that 'velocity' is not defined by Scrum, nor by the Agile Manifesto. It's a very difficult concept to grapple with for all concerned, and I'm not going to pronounce here on it's merits or otherwise, save to note that it is usually based on an abstract notion of the size of tasks ( see above ), and is expressed as 'task size units per sprint'.
Note that two different teams may well perceive the same task as having a different size, and this is not a wrong thing, it simply serves to highlight the fact that different teams have different capabilities.
As to why it is not a measure of productivity, just consider the definition of productivity that I offered at the start of this section. It is expressed in terms of business value. Velocity is not expressed in terms of business value. There will be a business value associated with the stories , and therefore the story points, delivered by the sprint. However :
Business value and task size are different things
Is that clear now ? 🙂 Actually, it isn't so clear. It's reasonable to think that it is more likely that a large task will be more valuable. There may be some correlation between task size and business value - but it is definitely not an identity. It's entirely conceivable that a small task may be highly valuable to the business, and that a large task may have little value.
Being able to decouple the idea of 'task size' from 'business value' is absolutely key to effective planning, and to understanding the performance of a team.
Because the PO knows the business value they gave to each story, they can calculate the business value that has been delivered by a sprint, and therefore they can do stats and get an 'average business value delivered' figure.
This is a measure of the productivity of the whole team, including the leaders who assign business value, refine the backlog, and prioritise tasks. It is not a measure of the productivity of the developers, who will very likely get quite annoyed if you pretend that it is.
In Scrum at least, developers should be selecting work for a sprint which reflects the priorities in the backlog - which is not quite the same thing as attempting to pick items that maximise business value. Of course, it would be perverse if the developers actively avoided high business value items, but the issue is easily avoided if only priorities, and not actual business values, are visible to developers for sprint planning purposes.
Bug rate is really a cross check on the team's DoD - ideally 'Done' implies 'zero bugs'. This will very rarely be the case, so a more useful way to use the bug rate is to monitor it over time. If it looks like it is converging on some low value, that's good.
If it looks like it is not converging, or is converging on a high value, this is not good, and merits some examination of the team's testing and Definition of Done to see how it can be reduced or brought under control.
If there are non functional requirements that define product performance parameters, then these should certainly form part of the DoD. But simply meeting the requirement should not be where all consideration of product performance ends.
Product performance is a quality attribute, and improving it is always a good thing. If the team identifies ways to improve product performance beyond the requirement, but they would require non-trivial effort, a good practice is to put these tasks on the product backlog so that their business value can be assessed by the PO.
A key aspect of Agile is that it provides ample opportunity for course correction. The question for performance purposes is how well the team responds to a need to head off in a different direction ? What is the productivity hit if, for example, a key technology must be substituted ( assuming this switch has a positive business value and is not just technical debt recovery ) ?
Team leadership, in conjunction with the team, may determine that a hit can be avoided or minimised with some appropriate training, or that some additional resource can be temporarily involved to help out. In both cases, the team must adapt.
Is this really 'team performance' ? The underlying assumption here is that if team leadership is performing well, and helping to create a happy and productive team, then members of the team will be less likely to leave. Poor team leadership is not the only reason people leave, but if an objective test versus other teams is available, it may be possible to isolate it as a cause.
How good is the team at coming up with fresh ideas for improving the product or their own processes ? If several sprints have gone by without some bright idea for improving something, then 'continuous improvement' is not happening, and team leadership should be concerned.
Sometimes team leadership is about supporting and encouraging initiatives from the team, and stimulating creativity may be as simple as pointing out to people that they are empowered to change things.
© Mark de Roussier 2021, all rights reserved.