Table of Contents
The year was 2001. A new methodology appeared in a still young, yet maturing Industry of Software Development. It came with the Agile Manifesto. The new way, the Agile management way, came to break the old, strict, narrow and deep hierarchy in which the developer was way too far from the software’s user.
Quickly embraced by some, completely ignored by others, Agile management spent the last decade and a half gaining popularity, becoming nowadays one of the most trendy phenomenons, and most of the companies claim to have adapted and applied its principles. And indeed, that is true, yet almost always in a modified and even sometimes in a corrupted way.
Most of us in Software Development have been in different teams and projects, as developers in some and as team leads & managers in others. We coped with clients in kick-off meetings, decoding Acceptance Criteria and Wireframes, defining the MVP, accepting changes in the requirements and modifying the Scope in the middle of the Sprint. We made mistakes, and learned the hard way. Mistakes that we should not commit again. Yet sometimes, we see them happening again, in our own team or when visiting clients or meeting teams with whom we will collaborate, etc. This will be my focus today. The troubles I see the most among managers with software developer teams.
AGILE MANAGEMENT COMMON ERRORS
Meeting a tight deadline by adding additional resources to the team
You check the estimation for the running sprint, and find out that the team is currently 16 hours behind the schedule. It seems like no problem at all; you have a developer that just finished his project, he will join the struggling team for two days, and you guys will be back on track.
By doing this, the team probably won’t meet the deadline. Why? The mistake here is to think that a developer performs an easy, automatable work. Well, he doesn’t. Even if he is familiar with the technologies used in the project, he still needs an introduction to what the project is about, what has already been done, where all the documentation is, what wireframes are still being reviewed, and a very long list of other things. Besides the fact that the productivity of this developer will be low (at least in the beginning), he will also need to be assisted by the rest of the team to be taught everything described above. A task that is usually assigned to one particular person. Well that person’s productivity will also drop as he will be distracted and will have to spend hours helping and training the new member of the team.
Parkinson’s Law
In the beginning, Parkinson’s Law had a different meaning. Today it states that Work expands to fill the time available for its completion. Let’s say we are having a performance issue in a particular project. So we assign, probably to one of our best developers, to investigate what the problem is and to fix the bottleneck. To do that, we decide to spare a week of time.
Parkinson’s Law is not always present in a developer; sometimes it’s stronger, sometimes it’s weaker. Yet a freedom of time in a task, specially if it doesn’t have a clear where-to-end point, will lead to it’s expansion, occupying all the time available for it. Sometimes it can even be worst, where the resulting solution suffers of Over-engineering that adds unnecessary complexity to the project. To avoid this situation, the task must have strict goals and acceptance criterias, or otherwise, a frequent polling in order to see the results achieved so far.
Multiple projects and distributed teams
Although out there you can find enormous amount of articles on how to succeed with distributed teams applying Agile or doing following Agile management, keeping in mind an even distribution of tasks, understanding time and cultural differences, etc, not all project are good to do such a thing. Specially when each developer forms part of different teams at the same time. In the attempt of making each one of the developers an ‘all-terrain’ developer, they end up working on multiple projects at the same time; per instance, Monday & Tuesday on project A, and from Wednesday to Friday on project B.
You probably heard about the developer’s focus, which is when he’s being the most productive and that once he loses it, it takes time to find it back. Well, the same thing happens when switching between projects and checking what was missed while being away. Although some tools help to mitigate this effect, as for example Dailies, Jira or Trello, it still drags down one’s productivity.
It’s easy to disagree about this topic, but by default I do defend the 6th principle of the Agile Manifesto, for both ‘co-location’ and ‘co-time’:
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Time pressure increases productivity
It’s surprising how common it is to discover among your co-workers and professional colleagues that they had the same dark experience. Often in a startup or in a small company, with a very talented manager that made them ‘believe in themselves and in the product’, which ended up in countless extra hours, tons of stress and impossible-to-meet deadlines. As developers accept to work in these conditions, it allows their manager to presume that the team is quite productive, as the ratio of delivered functionalities and time is unbelievably high.
In fact, the productivity of the team might be considered high, as long as you don’t take into account the quality of the work done, and the extra (and unpaid) hours. Those kind of conditions inevitably lead to two results:
First, the quality of the code resents. This means more bugs passing through (no need to explain that a bug in production is hundreds of times more expensive for the company than the time needed to get it done right in first place), the test coverage fails, functionality is implemented partially, etc.
Under time pressure, developers won’t work more, developers will work faster. Basically quantity over quality.
Second, at a certain point the developer ends up quitting. Once he realizes that things won’t change, and that his workaholic attitude and commitment to the company isn’t really good for him, he will definitely find another place where to try his luck. Usually, the one that leaves is the one that had the most pressure. The one that can actually leave because he knows he has another option. And guess what? That’s the developer that you can’t let go.
To finish with this paper, I would like to point out the link between the code of a developer and his motivation. Usually, Software Development is not something that ‘pays the bills’, it’s someone’s passion. For a developer, to have the chance to write quality code means a burst of motivation. Take that chance away, and the motivation is gone.
Often in Agile management, the manager’s focus for the team is to keep up the productivity, and rarely does the quality increases in a significant way. But when the focus is on quality, productivity tends to soar.
If you need help with Agile Management, you can count on us, we have Product Owners with technical background who have worked in many different projects and countries.
