A year ago, Daan and I were sitting in our most favorite pub in ‘s-Hertogenbosch. As usual and besides many other things, we were talking about some challenges we faced at work, for example: how to improve on our review process, how to get team members engaged and get them in learning mode again. Stuff that most managers will recognize and that we can fill many a conversation with. I am not sure if it was because of the beers or that one of us simply had a bright idea. But, at one moment we started to compare XP to Management. In the past, the both of us had already made the link between pair management and pair programming. We like to keep each other sharp and improve on each other’s ideas, as developers do when pairing. We came to the conclusion that many of the other XP Practices were also highly applicable to management. Since then, we have been consciously using various principles taken from XP and have applied them in our-day-to-day management job.
As a manager, you sometimes tend to forget to look at the world that is closest to you. Sure you read management books, blogs, view LinkedIn updates or you get lost on TED. But we realized that we can learn and adopt a lot from other groups, like for example the developers, testers and agile practitioners that are near to us. When we discussed further about XP Practices and management, we realized we could easily use those practices to help us try find creative, new solutions for management problems based on good patterns already out there. Since then, incorporating XP practices in our management mindset has grown our toolbox with some nifty power tools. OK, open door warning: we are very much aware that there are many worlds out there that you can learn skills and best practices from: how to run a music band, how to be a good sports coach, how to run a logistics company, how to run a military operation, how to train yourself for a marathon, the examples are numerous. It is just that the world of development is so comfortably close to us and it is easy for us to understand it and learn from it.
So in this long-read blog, we will share our ideas about how XP practices can also be applied to management. But, let’s first take one step back and quickly revisit what those XP Practices actually were again:
So, looking back at last year, we actively used some of these XP Practices to help us find solutions for a number of problems we encountered. Let’s walk through these problems and take a look at how XP helped us.
In most organizations, you are still reviewed by one manager and if you are lucky that person asks feedback from colleagues around you. In the end the review is, as it is stated by most HR policies, a meeting where the manager gives their opinion about how the employee performed last year. This manager, however, is also very busy during the year. He or she maybe needs to manage some projects, help implement a new HR system, manage budgets, talk to stakeholders, etc. In most cases it is very hard for the manager to know what a team member is doing on a daily basis. The manager will then try to compensate by asking 360 feedback, but after a couple of years this feedback mechanism no longer provides new insights. In our organization it was fortunately, not that extreme but we had some of the challenges we just described.
Looking at the XP Practices, we concluded that reviews should be related to the practices Whole Team, Collective Ownership and Small Releases. A review should be done by the whole team or at least everyone who can give input should be able to do so. Furthermore, multiple managers should be able to give input to the performance of employees at least when they interacted with that person. So next to our existing review mechanism, we implemented 360 dinners and Kudo cards to solve the problem, or to make it less of an issue.
A 360 dinner is not eating in a tower with a 360 view of a city… For a 360 dinner, you invite the whole team for dinner and you tell them in advance that before, during or after dinner, the entire team will evaluate each other’s performance. All participants will do so at the dinner table, face-to-face. Note that many people find this scary as hell. Therefore you, as a manager, will volunteer to be the first one to be evaluated. Really invite people to give feedback good or bad, it shows courage and respect. It helps to loosen up the atmosphere so that people know what to expect (and how to behave) when it is their turn to receive feedback. Feedback can concern things that people appreciate (keep), things that people do not like (stop) or things that people feel you are not doing (start). So bring a pen and paper and make notes on what people tell you, remain a listener, and this is very important: really thank every person who gives you honest, valuable, and constructive feedback. Because sometimes it is not easy to be honest. You need to reward that. Read more about the 360 dinner here. A 360 dinner will give an entire group of people working on a shared end result an opportunity to provide feedback to each other so as to inspect and adapt. By having all participants give and receive there is collective ownership. Note that we have been part of 360 dinners where compliments were given to people where the compliment had remained implicit for years, because people thought it was obvious that others were doing a fine job.
Kudo Cards are small gestures of gratitude. We found out what Kudo Cards are through Jurgen Appelo as described on the Management 3.0 website and in his book Management 3.0 Workout. Kudo Cards are a written and public recognition of a colleague for something he or she has contributed to the team. A Kudo is not just given from the top down but can be peer-to-peer, cross department and cross organization. Anyone, or the whole team, can publicly recognize someone else’s work. Over time, people can be given multiple kudo cards for various reasons. It is a way to break down hierarchical limitations and to encourage everyone to offer instant feedback and to publicly show appreciation. You can read more about how to implement Kudo cards here. Using Kudo cards, we gave everyone the opportunity to give small pieces of feedback to everyone and to do it time and again. The feedback is positive, but we believe a review should in general have a positive approach. As a manager you can read the Kudo cards and find out where to go for information about the performance of an employee. Also, managers are able to provide feedback to other employees by using Kudo cards. Again it has been noteworthy that certain people in our organization gave a good Kudo card to others where we did not know that there even was a work relation between the two.
You are reading this blog. That almost implies that you are interested in developing yourself: you want to be updated so you can perhaps learn from it. We hope you read some interesting things in this blog. If so, you maybe share this blog with a colleague, “Hey, Jim, I read this interesting blog, you should also read it.” He will say yes and will probably never read it because he has other things to do that are more important for him. This is a problem that happens in many organizations: people are just too busy with projects, deadlines, implementations, escalations, and other important stuff. They forget that they also need to invest in themselves, because when they wake up from their daily grind, they may learn that the world around them changed while they were busy with their day-to-day tasks. Take the Windows desktop developer who finds all other products in their company went web or the exploratory tester who finds all other testers really engaged in Selenium. You need to keep learning and you need to be able to answer the question: “What did you do to become a better professional?“. We have seen this problem at multiple companies where we worked.
Again, we looked at the XP Practices to come up with ideas or to reflect ideas we already had. We linked Pair Programming and Small Releases to this challenge.
We don’t know about you, but we feel that learning together with your direct team members is much more effective and fun. So we had to come up with an approach where people can learn together. With this we don’t mean sitting next to each other in a classroom for a whole week on a technology or product that you will only be using in a couple of months’ time when you will have forgotten all about it, but really learning together and getting hands on with the stuff at hand. The other practice that we feel is applicable is small releases. We think it is way more motivating to learn about new things in small chunks. Ralph has been participating in an online training these last weeks, Fundamentals of Business Process Management, a very interesting topic. The training, however, takes two months and requires several hours per week. You could argue that Ralph lacks discipline because the training is turning out to be a bit of a struggle, but then again would it not be easier when the training would just be a few weeks, with a deliverable every two weeks?
Taking these two practices in account we concluded that Exploration Days could maybe help us. In basics, a group of people gets self-organized and takes 24 hours to explore something, no further strings attached. So no hackathon where the goal is to create a usable deliverable otherwise you failed. Note that there are many names for events like these. Exploration Days are meant as an invitation to your employees to learn and develop themselves by running experiments and exploring new ideas. The goal is to get employees to learn as much as possible and perhaps even to come up with new ideas and insights. Experts agree that the purpose of hackathons and other forms of exploration days should be to experiment with ideas, not to ship things. Organizations must now learn to run such experiments regularly, because those that learn fastest are the ones best able to survive. You can read more about how to organize an Exploration Day here. Our takeaway from one of the exploration days is not to be too formal: let the people get organized themselves and come up with ideas perhaps a couple of hours before it starts. For example we now know of an active Selenium users group that formed out of an Exploration Days experiment to investigate the usefulness of Selenium in a certain product.
We encountered several times that management, and that certainly also applies to us, made decisions and that we thought that it was crystal clear why these decisions were made. Time and again we found out that it was unclear to the people around us why these decisions were made and on what grounds. We know that professionals are sometimes just really engaged in their scrum team and are not that aware of the world around them. We feel, however, that it is the big-time role of the messenger to change the format in which news is delivered about decisions that were made. Now, in some cases different managers make different decisions or they communicate in different ways or the people listening are just lacking a piece of background information. Looking again at the XP Practices we picked Test-Driven Development and Coding Standards.
So test-driven development: When you create your test first, before you write your code, it will find be much easier and faster to create the actual code. The combined time it takes to create a unit test and to create code that makes the unit test pass is considered to be about the same as just coding it up straight away. But, if you already have the unit tests you don’t need to create them after the code. This saves you some time now and lots of time later on. Now let’s compare a management decision with this test-driven development principle. Think about how you will establish that a decision has the desired effect. Well to really establish this, you need to have facts, or data. And to do so you need to have facts about the before and after. This means that you need to collect data so your decision can be evidence based. This will allow you to verify whether your solution has an effect. Since you have smart people working around you, having this data will then also help you to explain about why you are going to make a decision and it can be easily shared with the team.
“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” — Jim Barksdale, former Netscape CEO
The other practice that immediately applies, in our opinion, is coding standards. Remember we just said that different managers make different decisions and they often communicate in different ways? Coding standards keep the code consistent and easy for the entire team to read and refactor. People deserve consistent answers when they ask questions to their managers: respectful, truthful and transparent information. People in IT are usually very smart people and they will know when your info, well to put it boldly, sucks… Additionally, it does not mean that you want to describe every situation and/or question in a policy which will turn into the world’s most sovereign sedative. That would only create an organization with lots of bureaucracy, a place where no one wants to be, let alone work. We believe that you should have some high-level policies for some topics, actively share the commander’s intent, and then give the managers the freedom and responsibility to deviate when he or she would like from this standard. After all, what fun would French grammar be without its irregularities and exceptions. In our opinion, one ring to rule them all only happens in fairy tales.
We had a discussion with some team members about the costs of flying to our other development center. The Dutch crew did not particularly enjoy that they had to go Schiphol, a long drive, fly with KLM, have high parking costs, etc. They claimed that flying with WizzAir from Eindhoven would be much cheaper, less travel time, cheap parking costs and a cheaper flight. It turned into a recurring discussion until we decided to create the test. Note that we should have made this test upfront and we should have shared it with the team already, we know, we’re not perfect… So we set down to think about which costs we should calculate for the company for a visit from an employee to a remote location. After drawing up this full list we filled it with the actual costs: parking, extra costs for luggage (you know where cheap airlines make their money), etc. etc. and divided that by the actual time spent with the development crew at the other development center. KLM flies daily, where WizzAir only flies a few times a week. The entire calculation then clearly showed that flying with KLM, via Schiphol, was way cheaper when you look at the hours spent with the team, than the WizzAir option. We shared this calculation with everyone and there hasn’t been any discussion since. Still, life would have been easier if we would have shared this knowledge upfront with the team. So now, we try to make these calculations or tests in advance.
Team members at all sites were complaining, at the coffee machine (as it happens in NL 🙂 ), about the fact that John was allowed to work from home and Perry not. John reported to manager Elton and Perry to manager Katy. There was an old, huge, corporate working-from-home policy. It was old, too long, boring, overcomplicated and no one used it because you needed a law education to understand it. We as managers decided to make a much more readable and usable working-from-home policy. We used this blog of Rich Armstrong as our example. A very readable document that makes it clear for everyone and still gives room to the manager to deviate. Since adopting this new coding standard we only ask, will you meet all requirements and we have not had any issues since.
For fun, search for the phrase Change management books on Google and you will get 114.000.000 hits. Yes it is an open door, but change is hard, very hard. People just don’t like change. We all know that changing things is hard and sometimes very necessary. So again turning to our coat rack with XP Practices, which one could we use? There are three practices that helped us: Release Often, Simple Design and Whole Team.
We firmly believe that you should always make a lot of small changes to be able to deal with a big change. Do not try to come up with a masterplan to change everything in one big bang, please don’t. Make small changes, constantly. Small changes that in the end lead to the big change you would like to have. Hey it is just like an agile project, so probably you will find out that the big change you wanted in the first place is something you did not really want :). Small changes are much easier to manage, to test, to deal with, but also to revert. There is no shame in trying a small change and reverting it when it does not work.
A team or department is not a computer. You cannot write a program that will exactly change the department as you want to change it. It just doesn’t work like that, a team or department is a living organism, a community. It is hard to predict, even close to impossible, how it will behave when you start changing it. So, we believe that the best approach is to have many simple and easy changes. As in XP: Always do the simplest thing that could possibly work (and then still you will sometimes be surprised). So keep it simple and do it constantly. We firmly believe in 1% improvement per day. If you improve 1% a day, you improve 167% in 100 days! Additionally, always try to involve the whole team. Who are you to think that you are smarter than a whole department or a crowd of smart people? Involve your team, make them help you, get buy-in, get your facts straight, and make them realize the change you would like to happen.
In one of our projects, we had an external consultant do a quick scan on our testing processes. As expected we found loads of possible improvements in our testing process. The result of the quick scan was a report with many recommendations. We decided on a staged and finely sliced implementation of the recommendations. Every development team focused on one improvement first, a small step. Every four to six weeks we then discussed their progress. As soon as the team had completed an improvement, we shared the improvement with the other teams, making it easier for them to adapt and if necessary adopt the best practice from them. One quick 1% fix was to have a team start using a mind map template to describe how to test certain fixes. A second small change then was to implement a peer mind map review in their workflow. The new system has been running ever since and other teams have adopted and changed or tuned the mind map template.
Another example is that we had a team that was a bit reluctant in attending retrospectives. In their opinion, it was a waste of time and they could no longer see the added value. Their team lead always ended up as the one doing most of the talking during the retro (and also taking home most of the next actions). We thought about what to do… this was definitely not a Whole Team experience. We simply decided not to make the retrospective mandatory anymore. For some Scrum Masters or Agile Coaches 3,8 bridges too far. We also asked the Scrum Master of the team not to focus on big plans to solve all problems of the world anymore. What then happened did surprise us, the first retrospective just a few team members attended. However, they had a very constructive meeting, the ROI of the meeting was perceived as high. The next retrospective more team members attended, still not mandatory! After a few retrospectives almost the whole team attended again, and the actions now were small improvement instead of large complaints outside of their circle of influence. The team lead did not attend anymore, it was no longer necessary. The team took ownership of the meeting and the actions, step by step.
“I think Team 1 is performing better than Team 2” or “Why does team X never deliver what they forecast?” Almost all leads or managers will have heard these statements from a higher-ranking manager, including us. The performance of a team is as good as the last user story they delivered. So how could we provide insight in how teams are doing and where do they need help to improve? Providing context is essential in metrics. Telling a manager that team Red is not performing is OK. That person should then also should be informed what the team could be helped with, how things were in the past and what is being focused on right now.
We concluded that we needed some metrics (we don’t use the word
KPI’s anymore, it gives us shivers nowadays). When thinking about metrics and XP Practices we made the following links:
Taking those practices in consideration, we looked at several metrics. In the end we decide to use the Improvement Scoreboard, the approach described by Anders Ivarsson and Henrik Kniberg in the paper Scaling Agile @ Spotify. Every Scrum Master fills in a scorecard every three months and the team has to decide on the score itself. It is their scoreboard. This already resulted in very interesting discussions within the team. Developer Julia is happy with the Product Owner and developer Andra really believes the Product Owner should improve. Discussion is good, it gets the communication in a team going and it is a different way of getting to inspect and adapt that you would normally have the retro for. It is also the same approach as with Planning Poker, if there are different values on the table, the team members have to share their opinions and as a team they learn. Next to the current score, you will see the score of the last time. This gives the team, manager and any other stakeholder, insight in how things are and how they are developing.
The most important thing to keep in mind when talking about metrics though: it is just a tool get to a discussion going. We do not believe you can only make decisions based on metrics or decide which way to go based on metrics. A metric is just a tiny fact. You can even call it a small rumor, and as with all rumors you need to gather more information to find out what the real facts are. Please note that we believe in evidence based decisions and for that you need statistics, metrics or data, just be careful. Having the XP principles has helped us many times in gathering data: Summit 2015: The Results.
As we discussed before, change is hard. Do you recognize the situation where you finally implemented Scrum in your team(s)? It took some years but Scrum is finally common practice within your department. You did it! Started bottom up, your vice president was a bit hesitant in the beginning, but you managed to convince him. Again, congratulations. The business, however, starts to complain: they need to prioritize their requirements every two weeks, they have to wait a week to get a burning customer demand or the deal will not pull through, they just need a couple of days from your guru developer for an internal side project, err now…, they have to calculate the business value of a user story instead of having their proven gut feeling as true. You explain the concept of backlog, sustainable pace, not disrupting the team, but it doesn’t help.
We had a similar problem with some development teams who were not really open to start using Scrum. They wanted to keep the whoever-shouts-loudest-will-get-his-feature-first-because-we-always-did-it-that-way framework. We decided that we had to use a metaphor to explain Scrum, to the team and their shouting stakeholders, and let them all experience Scrum. The metaphor should be as simple as possible. Explaining to a group that software development is an empirical process in which you have to apply the circle of Deming as much as possible was not the best approach to explain Scrum.
This was clearly related to the Metaphor practice, explain something using a figure of speech in order to imply a resemblance.So we set up a workshop, a Lego Scrum Workshop. The goal was to have a group experience what Scrum is, in a fun and relaxed way. In this workshop we explained some basic concepts and in three small sprints we let them experience what it is to do Scrum. Instead of building software, the group uses Lego to build a city, a metaphor that everyone can relate to. The team really liked it and based on the workshop they said: “OK, we are in. Let’s give it a try”.
We used the metaphor in another project as well. It was a product where users could make a reservation in a facility management application, the back end would synchronize the facility reservations with Exchange. The small development team of two developers built a prototype and also the first version. The next step was to grow the team with some developers, but also testers and a business analyst. However, the two developers had a lot of implicit knowledge. They didn’t create any documentation… not good but hey we have all been there (and will be there again 🙂 ). We could ask the two developers to write down everything what they learned so far… and then the new team members could read the documentation…. well even if I write this down it sounds a bit inefficient. We tried another approach: we role played the software. The business analyst was the end user, one developer was the client, another developer was the Exchange server, etc. The business analyst asked the first developer: “Can I have an overview of all my reservations”. “Sure, let me see… who do I need to ask this?”. So he asked the Exchange server: “Can you give me an overview of the reservations? “. “Stop”, said the tester, what about security? The “game” continued for a couple of hours and in the end all team members had a proper overview of the system and the intricacies that came with it. We still didn’t have any documentation but at least we shared the knowledge, using the team members themselves as metaphors for the system.
Congratulations and a big thank you, you made it to the end! Now, what can be your take away from this blog? We hope we gave you some ideas on how to solve some of the challenges you encounter during work. Sure we gave some pragmatic solutions. We also told you about some truths that are out there in XP. Most importantly, we tried making clear that you can use an existing framework to help you overcome a challenge. So try to look at things from a completely different angle, and use a framework to make sure that you are thinking about all facets.
In the end, there is nothing new to what we described here. What was new to us in that bar was to actively start using all these concepts and principles when tackling the next management issue we would face, instead of implicitly trying to deal with all angles.
If you have questions, remarks, ideas, notions, please contact us, just leave a comment, reach out to us or join us in our next session at our favourite bar.
Daan van Osch is Director of Software Engineering at RES Software. He is the manager of some 30+ people in three different locations. Daan is responsible for sustaining engineering at RES: maintenance and fixes of released products for customers experiencing issues. Throughout his career, from starting as a software translator, then techwriter, to software tester, test lead on to scrum master and development manager, and now to member of the RES Engineering management team, Daan has found that this experience is really close to offering what IT professionals need for management. Always with the customer in mind, he is a pragmatic manager and a firm believer in making a 1% change every day in his team, department and company. Keep it small and simple, make a plan and let’s get things done for the customer. Most of all, Daan has a drive to help people experience a safe, fun and challenging work environment where they can grow to become people that are energized by their job.
Ralph van Roosmalen believes people make all the difference in every project. The skills of people, how they work together and how they feel. Scrum, Kanban, eXtreme Programming, Management 3.0, these are just tools or frameworks that exist to help people. He has been working in IT since 1997. He had different roles: developer, tester, Scrum Master, Agile coach, lead, manager to VP. What he always liked most, however, was working with people to improve the processes and the environments they work in. He is an active member of the Agile community and shares his insights and knowledge by speaking at conferences and writing blog posts. He is specialized in recruitment, building (distributed) agile software teams and Management 3.0.