Anti-Agile Personalities – Part 1

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

The technology development is going in lightning speed nowadays and almost every company has at least 10 competitors who can offer their customers the same or better experiences or goods. This puts quite a lot of pressure on companies and organisations to be nimble and customer focused which in turn does the same on the people working for them. Certain traits have become more important in employees than before, whether it is management or development teams, such as trust, flexibility, passion, curiosity, ability to collaborate, humility, and innovativeness. It also means that personalities not defined by these traits that still worked very well in traditional, hierarchical organisations actually might be obstructing efficient development in modern organisations.

In this, and the following, blog post, I will try to list a few of these that I have encountered during my years working with product development and how you can try to help them adapt to a more constructive way of working. Since there are quite a few of them, I have split them up by ”management side” and ”team side”. Keep in mind: a person you meet can represent more than one of the personalities I list.

Let’s start with the management side:

The Key Person image

The Key Person

This person is most likely an old school waterfall project manager. As such, people expected the person to always know the status of the project and held them responsible for when it did not go according to plan. In order to have some kind of perceived control, the solution was often to be the sole conduit of information. If people working within the project met and agreed on things without the project leader involved, then control was lost and failure was a risk. In organisations where each area of expertise was located in their own teams, this was usually not a big problem, but now, with the cross functional teams being more and more common, this kind of person feels control slipping out of their hands. To at least feel somewhat safe and important, the solution is often to grab and hold on to all contacts with everyone outside of the team so all communication between the team and the rest of the world goes through them. 

How can you help this person adapt a more constructive way of working:

The most important thing this person need to realize is that success or failure of what is being developed is on the entire team – not only on them personally. Everyone should be held accountable, but as a team – not as individuals. After all: accountability for individuals led this person to become this way in the first place. In addition, information should be shared within the team as well as to external people who need it. The development process and the information flow should be as transparent as possible. This might be a bit more problematic in highly sensitive projects, but it is far from impossible. By formally recognizing that the main responsibility for this person is to make the information transparent and shared, they might still keep the feeling of control in terms of access to the information while at the same time sharing it with others.

The Organizer image

The Organizer

In a world where nothing changes, this person might actually be right. If you spend enough time investigating how something should be built and then document it, you have sort of developed a recipe for building it that only needs to be followed to ensure success. However, in the process of investigating and specifying it, you have actually already built it – if only in theory. Why not do the building directly instead? In addition, from the time when it was documented until it will be built, the memory of what the documentation actually mean will fade. You can only put so much on paper. A lot still will only be in the head of the writer. 

Another thing that makes this kind of thinking problematic is the speed of progress in nearly every field of technology that is currently going on. From the time an old-school project is formed until implementation is happening, frameworks have changed, competitors have released something even more sophisticated and parts that should be used in the product have gone end of life. Predicting the future enough to write detailed specifications that hold more than a couple of months is close to impossible. 

How can you help this person adapt a more constructive way of working:

The most important part when developing anything is to define the northern star which is what you’re heading towards. The second most important is to provide the context of that goal, i.e. Why you are going there and what you hope to achieve by doing so. The path taken there is much less important and the route can change during the time the journey takes. Also the goal might change depending on external or internal factors. The most important thing to do when dealing with this kind of person is to get him or her to raise the level of the specifications from technical details to functional requirements in terms of desired outcomes from the product. (The technical details will only produce output which might or might not lead to the desired outcome – you won’t actually know until it’s done.) The ”Why?” and ”For whom?” are much more important questions to answer than ”How?” And will open up for more creative solutions by the team.

The Optimizer image

The Resource Optimizer

Again, this is most likely an old project leader who has never worked as anything else but a project leader. They like spreadsheets and gantt diagrams and is a strong believer in things’ predictability. When referring to team members, the word resources is used instead of names or people. Resources, i.e. people, represents specific sets of skills and might be shared in percentages over several projects. Everyone is exchangeable and should be utilized to a maximum. 

How can you help this person adapt a more constructive way of working:

Before even addressing the “doing anything other than developing”, the splitting of people’s time between projects and teams need to stop. After that, they need to be shown how costly implementing a requirement in a way that fulfils the requirement, but does not actually solve the problem at hand can be. By involving the team members in cross-functional activities, better understanding of each other’s needs as well as the user’s needs will be gained and such costly mistakes can be more easily avoided. After all, as an experienced project manager, they should be aware of the cost of mistakes and remakes in terms of time and money compared to the cost of a slight delay.

Stay tuned to read about the personalities that can be found in the development team in Part 2 which will be published soon.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.