Agile Implementation from a Manager's Perspective

Since childhood, I have been taught that in order to be successful, I have to be individually the best. This applied most of all in school, when playing a musical instrument or anywhere the element of evaluation appeared. Very few people were interested in whether or not I was able to cooperate with others, whether I could seek compromise or whether I could inspire or motivate others to act. No one paid particular attention to this. We are not taught to cooperate or to assist one another. We are not graded for this. It happens spontaneously, as a result of our soft features, upbringing and the circumstances we experience. 

However, it is more often that teams stand behind success

However, as reality shows, teams stand behind success more often than individuals. I like sports, so that may be why the following examples speak to me the most. Recently, only two football players earned the title of the best football player – Ronaldo and Messi, individually alternately between achieving numerous successes in various competitions, polls, and receiving the title of the best scorer in league tournaments and international tournaments. However, they wouldn’t be able to achieve what they have achieved without their colleagues from Read Madrid, Barcelona, Portugal’s national team or Argentina’s national team. Without the right support of the coaching, medical, PR or marketing staff, they wouldn’t have as many trophies in their glass cabinets. They are individually exceptional, but only capable of fully showing their abilities in exceptional company. This is the recipe for success today. 

Before Agile come to mBank ...

Now putting sports aside, as this is not what I want to write about what I want to tell you about is my experience as a manager who implemented Agile at a data warehouse at mBank. What did it look before we started to approach software development in an agile manner? It will not be anything new if I say that we simply managed, applying mostly Waterfall or other lesser known Agile waterfall-kanban hybrids.

How it looked from an employee's perspective ...

From the perspective of a developer, the process often involved work being delegated to an employee by a business coordinator or a manager. It was mostly independent work with only a few interactions with other developers, or the so-called business. Employees were not bothered with meetings, unless initiated by managers. They were expected to deliver on time, within budget and within the set scope. Specializations were needed from time to time, for example if it was about “refund of card fees”, everyone knew that Chris was the right guy to go to. If Chris wasn’t there, we had to wait until he came back from holidays. Failure? Has Chris taken his PC on holidays?

How it looked from the perspective of a manager ...

From a manager’s perspective, this work mainly involves the delegating of tasks, receipt of tasks, work monitoring, and establishing tasks to be implemented with the business. Instead of a team, a manager had a group of individualists, combined into teams from time to time for the needs of projects, which were resolved just after the completion of a given project. Due to so-called bustling and patching, there was a permanent lack of time for a team’s vision and strategy, cyclical 1-on-1 discussions, systematic meetings with the entire team, and the stimulation employees’ development. But we managed. We manufactured software, and business was going well. 

How did agile appear in organization? 

One day, a new head of IT came to mBank. As it turned out, he had successfully implemented an agile approach to the production of software in several institutions in the past. So far no one managed to convince him that Agile "does not work". 

What did I know about agile? 

What I read on Wikipedia, in a book by entitled "IT project management. Guide to methodologies", and from my friends’ stories. At that time, I also took a course entitled "Agile Project Management", and completed a Foundation level certificate. So, I had quite a lot of information, but little practical experience. I had my concerns, and I was wondering whether such a change was needed for me and my team. We were doing our job quite well. 

Concerns

I had concerns that I would lose my influence over the team

In addition to taking a lot of time, ongoing task delegation and the receipt and monitoring of work progress also brought a sense of perpetration. I was in control of what my employees were doing, how they were doing it and for when, etc. In this agile reality, an outsider appears – a product owner – who defines priorities, expectations and deadlines, instead of me. In fact, a product owner manages the work of my people, and I have to stand down. Not distract anyone; just support them and politely ask if I need something from them. 

I had concerns about wasting time (read Man Days) at meetings 

During the two-week scrum sprint, a team should meet every day for the so-called daily (up to 15 minutes), refinements (once/twice a week for 1-2h), reviews (once every two weeks for 1-2h), and retro meetings (once every two weeks for 1-2h). Adding up all these hours during a two-week sprint, one may conclude that a developer is deprived of at least 6.5h or up to 14.5 hours due to meetings (without which he/she has functioned effectively so far) during a two-week period. In the case of a five-person team, this means 4-9 developer’s Man Days (MD) less in two weeks. This means that we will perform fewer tasks and we will not complete a number of projects in a year. Business will not be satisfied. Scrum is not cheap. 

I had concerns regarding Agile Coaches

What is this strange role of an Agile Coach? On the board of the organization, a group of people who were to carry the torch of agile’s education appeared. They were to stimulate development of the agile development of software in teams, remove obstacles, talk to teams and their manager, and encourage them to think differently about the development of software and discourage the use of old methods. They started talking with my people, asking different questions over a cup of coffee or whatnot. They were sitting together with them in open spaces and observing what was happening. What were they talking about with my people? Or even worse, who were they informing and about what? They sneaked from one meeting to another as a mysterious Agent Smith. What was going on?

I had concerns about changes 

Why change something that works? I did not see the need to introduce Scrum, as my team was reaching the goals set for them without it. Better is an enemy of good ... do not touch it because you will get burnt.

I had concerns that I would not be able to separate the product

I had individuals in my team who had been creating tons of software for many years – reports, system extracts, applications, IT systems, data marts, etc. Knowing that Scrum in its essence focuses on interactive product development, I was wondering how to find one product in this environment which individual teams should focus on. We have dozens of such systems. There is no possibility of offering the team the comfort of working on one large project. We can only try to group the systems and deal with categories of subjects. Then, is it worth trying to create teams around such collections of systems?

I had concerns about geography 

Maybe it is not such a good idea to fight with "geography". How can one create teams with employees working in two cities, Lodz and Warsaw, more than 130 km apart from one another? Obviously, it is possible. It would be best if those from Lodz worked with those from Lodz, and those from Warsaw work with those from Warsaw. But what if it is not possible? Maybe it would be possible in Excel, but in reality, it is difficult. 

I had concerns about the lack of experienced Scrum Masters on board 

Let’s assume that Scrum takes off. Let’s assume that a product is separated, we manage to create teams and I accept the lack of full control over people and their tasks. How can you get Scrum Masters for each team? Where can you find people who will take care of the application of Scrum’s principles in particular teams? Positions are fixed. I cannot employ anyone new. On the other hand, I had some hope. 

I was hoping for more time 

I wanted the bustling and patching to take less of my time. Dealing with task delegation, establishing priorities, verifying work progress, responding to escalations ... this was my daily bread and butter; an important, momentous and much needed task. The question was, must it be me doing it from beginning to end? There was never enough time to work on the team’s vision, development of employees, etc. There was always something more important to do, as though the development of employees and the team was not the manager’s work. It is indeed, but only after completing "actual work". 

I was hoping to introduce substitutability

If an employee is on holiday leave, then in 99% of cases we can expect that something will go wrong. I did not have all the functions in the team double-staffed. It increased risks and was irritating when failures occurred. I had to cope and call a friend ... who was on holidays. I hoped that the result of team spirit would allow for the interchangeability of positions and people would replace one another efficiently. 

I was hoping to build real teams 

As I have already mentioned, I managed a team of individualists. There was a good opportunity to change something; to encourage people to cooperate with one another, transfer knowledge, learn from one another, notice better solutions their colleagues applied. Thanks to this, we were able to produce better written, less defective software more optimally, for which a group is responsible instead of an individual.

I was hoping the business would assume the responsibility of establishing priorities

It is a pleasure when external customers call you and request a developer to be delegated to implement a task. You feel important and needed as a manager. It is less pleasant when they request the developer to do it twice as fast as in the estimate he/she provided. It is even less pleasant if there are no developers, and stakeholders start to threaten you with penalties or remind you of being acquainted with the CEO. Obviously, it is a corporate daily norm and it is commonplace for the demand of MDs to exceed the supply of resources. On the other hand, it is tempting to just drop it and leave it in a business product owner’s hands who understands IT and knows its product and business – it is an Agile dream. 

Concerns or hopes? 

It took me a while to decide whether my concerns or my hopes would get the upper hand. However, I knew that I needed to risk it, commit some time to preparing, get some answers, and the rest would take care of itself. 

What did I start with? 

Meeting with practitioners, people wiser than me, people who used to work in Agile. People who were able to show me what the process of transferring from Waterfall to Agile would look like. I was asking questions, and my doubts started to disappear. In the following year, I selected an area which we could try to "make agile", together with a new team and an Agile Coach. The reporting area was chosen. A kick-off meeting took place, and so it started. First, one team took off, and then every few months subsequent teams in other data warehouse areas took off. We activated four teams in total. One of the teams went through their journey from Scrum to Kanban. The other three worked in Scrum the whole time. Each of them had its specificity, its challenges and its attributes. One team broke up to return in a different configuration, and became one of the best teams on board. 

What was the most difficult element for me?

F...g Scrum 

One day a colleague from one of my teams, a product owner, told me after a team retrospective: "F...g Scrum. Before, I would just order, now I have to ask". In Scrum, if you wish to build solid bases in order for the team to become independent, you cannot just order them to do something. You have to ask and present arguments. This obviously takes time; on the other hand, it teaches people to be responsible. This was quite a challenge for me when I had to ask a product owner, a business person, to allow my people to implement an important task for me ... which is related to the following point ...

Giving way to the product owner (PO) 

Which means allowing the PO to establish priorities, talk to stakeholders, be the face of my team. I had to take a back seat and I had other tasks to implement (the development and integration of employees, stimulation of team development, vision and strategy of the team, managing large projects, budgeting, etc.). 

Combining the role of a manager and PO 

From theory and experience, I know that it is much healthier for my psyche and team work if the manager and PO are two individuals, and not one person. One of the non-standard tasks I had to fulfil was the PO role in my team. The PO had a long sick leave period (several months) and without finding an alternative, I agreed to replace him. It was fine for the first few weeks; however, later inappropriate behaviours started to sneak up - micro management, unnecessary pressuring of the team, etc. As a result, my subordinates asked me not to attend daily meetings, and they had several retros without me. This was not easy - neither for them nor for me. 

Scrum Masters needs time 

This was a revelation. It turns out that a person abiding by Scrum’s principles needs half of his/her time, i.e. approx. 5 MDs in a fortnight sprint, for scrum master work. Because we had no Scrum Masters in our teams – this role was fulfilled by developers – this meant that in a team there was half a man less to work. This was most painful for me, as I fulfilled the role of a PO and a manager at the same time, dealing with stakeholders’ pressure on the issue of precious MDs. 

The Results? 

Difficulties, concerns and hopes ... i.e. how did it all end, and what were the results of the changes introduced?

At the stage of data warehouses, there were four teams with three Scrum Masters and one Kanban Master. I lost a bit of power, as POs delegated tasks. On the other hand, I regained time for other operations (development and integration of employees, stimulation of team development, managing large projects, educating successors). 

My fear that the time spent in meetings, in particular in the case of Scrum, would take up developing MDs, has come true in a way. On the other hand, the organization gained something that is difficult to quantify - propagation of knowledge about systems, more thought-through IT solutions – as discussed in a group, as errors constitute material to learn, and are not to be swept under the carpet. I am convinced that the time we invested has been paid back in full in the implemented projects and their maintenance. Substitutability in teams has appeared and the operational bottleneck risk has basically ceased to exist. 

It turned out that Agile Coaches were not informants, but very kind people who wanted to help ... as our success was their success. We should not have been afraid of change, as even though they caused some confusion, they also introduced new quality and additional energy. Now, no one wants to return to the old method. 

We did not manage to implement everything the way we would have liked to. We were not able to separate one product per team, and we are still working on it. 

The Lodz and Warsaw teams are functioning. It would be ideal if they were situated in one location, but beggars can't be choosers. Skype, phones, cars and trains do the rest.

After some time (approx. 2.5 years), successors and managers who wanted to introduce additional changes appeared, allowing our business stakeholders to group products, and giving developers the chance  to change the team they work in. Changes drive changes ... but that is another story. 

It is not necessary to change. Survival is not mandatory. William Edwards Deming 

About the Author

Tomasz Dutkowski is an experienced senior IT manager in data warehouse area at mBank for retail and corporate customers. 14 years of experience in banking both on the business and IT side.  A leader in the transformation of agile software production at the team level. An enthusiast of innovation in teamwork. Personally, a husband and father of two kids.