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:
- Test-Driven Development: Think about how you will test it before you start coding.
- Refactoring: Refactor mercilessly. Refactoring is changing the structure of code without changing its behavior.
- Simple Design: As a strategy, always do the simplest thing that could possibly work.
- Pair Programming: Two people working together will create as much functionality as two people working separately except that people working together will produce much higher quality.
- Coding Standards: Coding standards keep the code consistent and easy for the entire team to read and refactor.
- Sustainable Pace: Set a sustainable, measurable and predictable pace.
- Metaphor: Explain something using a figure of speech in order to imply a resemblance.
- Continuous Integration: Integrate components early and often to make sure problems are visible asap.
- Collective Ownership: Everyone owns everything, to make sure there are no bottlenecks.
- Whole Team: The customer should always be available.
- Planning Game: Have a plan for the next months.
- Small Releases: Release often to gather feedback fast.
- Customer Tests: The customer is actively involved in deciding what tests need to be performed.
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.
How to review people fairly?
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.
People are not learning anymore
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.
People have a hard time understanding management decisions
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.
Managing travel costs
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.
Working from home
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.
Challenges in change
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.
Can you quickly show management how the teams are doing?
“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:
- Whole Team: The metrics should be supported by the whole team. Customer, Product owner, Manager, Project Manager, Development Team, Program Manager, just pick the ones who are stakeholder to the team or organization. Include as many dimensions as you can.
- Collective Ownership: The metrics should be owned by the team. They should be filled in, reviewed and discussed by the team. We believe that metrics are so much more powerful when the team is responsible them themselves.
- Simple Design: Keep it simple because metrics can be dangerous. Don’t use complex statistical formulas to calculate the happiness number divided by the number of bugs found squared by the lines of code committed on an average blue Monday while taking in account time zone differences, motivational indexes and cultural differences.
- Coding Standards: If you are going to use metrics to compare apples to apples, you need to keep your metrics consistent and easy for the entire team to read and fill out.
- Small Releases: Have loads of different small metrics, add metrics constantly, that helps from getting them rigged. You cannot say that a person is healthy by only checking their body temperature. You need loads of small differing metrics that in combination provide a valid diagnosis.
- Metaphor: Use metaphors in your metrics. Accept that it is impossible to show the exact reality in a metric. If you accept that you use a metaphor, things will become easier.
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.
Who has challenges explaining Scrum to the business?
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.
I have helped many teams and organizations to set up distributed teams. In most cases, it concerned a multi-site team setup. Two locations and team members at both locations.
When you have teams at different locations (cities, regions, countries or even continents), there will be a culture difference. I believe this should not be a problem, after all wouldn’t the world be a more boring place if we would all share the same culture? As long as you are aware that the other team members may have a different culture, you are already half way of dealing with these differences.
Furthermore, it is very important to have a strong team culture. When there is no team culture, people will fall back on the culture of the organization. When there is no strong organizational culture, people will fall back on their home culture. You can imagine that in some countries you would prefer a strong team culture to minimize the impact of the country culture. For example, some countries are quite hierarchically oriented and do you want that in your team?
Now how do you build a strong team culture? There are many tools and approaches but one thing that I personally find important is to have a team identity.
I find it boring to have a team Red, a team Green and a team Orange or team A, team B and team C. C’mon… you don’t name your kids child 1, child 2 and child 3.
In his book #Workout, Jurgen Appelo talks about Identity Symbols what they are and how they can help your business. According to Jurgen: identities are crucial for purpose definition and value creation. A team, a business unit or a company has only really achieved an identity when people are eager to associate themselves with its symbols. Management can take an active role by inviting groups of workers to create symbols that represent their shared identities.
At one of the organizations I worked, we had distributed teams in The Netherlands and in India. We started with teams called Alpha, Beta and Gamma. Yep, pretty boring indeed. However, as soon as we had to make some changes to the teams we asked the teams to come up with their own team names and team logos.
They came up with their own names and logos, some nice examples:
- Team Galaxy. Why Galaxy? Because they said they were the best team of the Galaxy and loved to play Super Mario Galaxy.
- Team Atlas. This team was providing support to the other teams. They maintained the build environment, databases, etc. They were carrying the other teams on their shoulders.
These teams turned out to be strong in their team culture. They had clear working agreements and they were proud to be part of their team. For the fun part, they had competitions with other teams about how often they broke the build 🙂 It helped the team members to get closer to each other.
However, the team adopted the color orange as their team color. They clearly established themselves as a separate team within the service provider. However, be careful not to overdo it. You should also respect their local identity. When the Dutch soccer team played in the World championship in 2014 we gave the team members orange caps as part of a Dutch marketing campaign. This proved to be a bridge too far… within days, caps of their local team popped up at the office.
You cannot force people to accept a certain identity, it should come from the group itself. The group must want to belong to that identity. As a manager you should facilitate and support the team when they have ideas to set up and grow their own identity.
We also had discussions with higher management. They believed that the names of the teams were not professional and it could make the company look bad in the eyes of customers. I don’t believe in this statement. When you explain that your team came up with the names themselves, that they are proud of their names and logo, that it strengthens their team binding, then I do not believe any customer will think what a weird company… I believe they will even have more faith in the company.
I told them let’s wait and see what they come up with. It turned out of course that no team used such a symbol, so it was good thing we didn’t limit the teams in their thinking. As a manager you should have trust in your teams, they will use their common sense and a group of professionals usually is able to clean and repair itself in that sense.
But what if you as a manager want your team to come up with cool names and logos and they don’t? Should you decide on their name and logo? Nope, just leave it. You cannot force them to come up with a nice, meaningful and cool name if they don’t want to or if they are just not that creative. What you can do is maybe to share this blog, or just ask them why it is not important for them? Maybe they feel too much pressure from management and therefore don’t feel comfortable to take time to think about a nice team name and logo. But if your team comes up with a name, make sure you use it in all communications and reports. Show them that you as a manager are ‘committed’ to support and market their team identity.
The final test for you, when teams have their own team names and logos. Order sweaters or T-shirts per team, with their team name and logo… now will they wear their shirts or not…?
What I found very useful is using the feedback wrap as described in #Workouts by Jurgen Appelo. It is a wrap, not a feedback hamburger: “You did a great job last week, oh by the way how you could write that piece of code, but still a big thanks for the great paper you delivered this morning.”
The feedback wrap will give you a structured approach to provide feedback. It will help you make your feedback more constructive and it will minimize the risk of miscommunication. The feedback wrap has five steps:
- Describe your context
- List your observations
- Express your emotions
- Sort by value
- End with suggestions
When I worked as an Agile Coach at a certain company, there was a VP Product Management that lived abroad with a time-zone difference of 9 hours. As you can imagine this person had a very busy agenda. It was extremely hard to get a Skype meeting with this person. The company was just getting started using Story Points and this particular VP had decided to use the number of story points delivered by the teams as an MBO for the Product Owner of that team. When I heard about this, I thought…, well let me not repeat what I thought… let’s just summarize it as “Jeezzzz…”. So, I decided to give him feedback about this. Note that I actually had no real involvement with this person: I was not coaching him, I was not hired by him, I had not met him in person (yet)… so how to give feedback and make sure he would not be upset, or worse? I was a bit afraid to give him the feedback.
I started my mail with providing some context first. I was in Eastern Europe at the time and it was hot, more than 34 degrees Celsius. Therefore, I had already slept badly for a few nights. I told him this for starters and I also told him that I was a bit annoyed about some discussions with some people, and what the impact was for me. So he knew I was not in my best mood.
I then shared my observation with him. I kept it as clean as possible, and presented it just as a fact. I said, I learnt that story points are being used as MBOs. The real description of the observation was a bit longer of course :).
After sharing this, I described what it did to me, in an emotional way. An observation is an observation, when you describe it correctly, there is no discussion possible about it. Your emotions are your emotions. No one can say your emotions are wrong or not allowed. They are your nonnegotiable feelings. I simply stated the observation that story points are used for MBOs which made me feel sad and also a bit upset.
So I sent the mail and waited… Would he be upset, disagree, escalate to higher management? Within a few days I got an answer from him. He agreed with me and he thanked me for my feedback. He changed the MBO directly and wanted to think about how to implement the Definition of Ready.
I am not saying using the feedback wrap will always give you good results. However, it will help you to provided feedback in a structured way.
I realized that using some kind of template makes it easier to provide feedback. But as with every template, it is just template. Use it as a starting point and change it when you need to change it.
One other important lesson is: take your time. Do you know any people who tell you to just write a quick mail? Trust me, writing a good email, and definitely a feedback wrap, is not done in five minutes. Make sure you take your time, writing a good email can easily take up to 30/45 minutes.
A Guild is an organic and wide-reaching “community of interest”, a group of people that wants to share knowledge, tools, code, and practices. Some examples are: the the Tester Guild, the Scrum Master Guild, etc. The goal of a Guild is to become better craftsman. This can be done by discussing new technologies, sharing experiences and inviting people from outside. The Guild is not intended to discuss work-related issues.
At my current company we have for example a Scrum Master Guild. I consider myself the Guild Master and I am therefore responsible for facilitating the Guild sessions. Besides, the Scrum Master Guild sessions we also have the Testing Guild that is very active.
What about management?
When you are going to organize your Guilds it is important, as with many things, to have support from management. Explain the concept of guilds and perhaps include ancient concepts such as apprentices (juniors), journeymen (mediors) and masters (seniors). Note that there is a lot to learn from the historical ways a guild was organized, mind you not all was well though. Then explain why you are going to organize the guild sessions. For me the goal is to increase the knowledge of the people who attend the guild, in my case make them better Scrum Masters by exchanging experiences. The Guild is not intended to discuss project issues. We are not going to discuss specific problems of teams of individuals. My statement is: “Every Scrum Master in the world should be able to attend our Scrum Master Guild session and find it interesting.” No knowledge about the project or company should be necessary. Arguments to convince management of the advantages of Guilds can be:
- You will develop knowledge of your professionals because people who attended external conferences can share their knowledge in their Guild.
- You can use it to build your company brand and promote your company, I believe you want to hire professionals who want to attend Guild sessions.
- It will grow cross-team relationships between people with the same profession working in different teams.
Mandatory to attend or not?
Who will organize all those Guild sessions?
To be distributed or not?
A Guild doesn’t stop at 12:00
The Guild doesn’t stop after the meeting itself. Provide a location where people can share information about what is discussed in the Guild. In one company we used Yammer and we had a Yammer group per Guild. In this group, we shared the materials of the Guild sessions but also had discussions about topics outside of the meetings and shared interesting blogs and/or websites. Again, lead by example. If you are the Guild Master, make sure you share something every week. Make sure the Guild group is the place to be when you want to know more about the topic of the Guild. If you don’t have Yammer you can also use a Wiki or maybe even a private group on Facebook or Google+.
What if you did everything I wrote in this blog, you copied all the best practices from Spotify, you read the workout How Corporate Huddles and Tribal Culture Build Team Collaboration by Jurgen Appelo and it still doesn’t work. What to do? Of course the answer is: it depends… but I only say it depends if I can finish the sentence as well:)
- No one attends, nobody seems interested. You should ask yourself the question: is my organization ready for Guilds. Perhaps people don’t want to learn, perhaps they just want to work and not spend any energy in self education? If that is the case, I advise you to check out this site.
- We are having Guild sessions and people are organizing sessions but the quality is so so, and sometimes even worse. Not everyone is a brilliant presenter, not everyone is gifted with a talent to speak for a group of people. It is OK, accept it. The good thing is people are willing to share their knowledge, they are willing to learn! Maybe you could take a look at the course Introduction to Presentation Design on PluralSight and share the highlights in a Guild session?
- Having a single Guild session where multiple locations join in just doesn’t work but we really want to have one Guild session. Er, if it doesn’t work, it doesn’t work. However, who wants to have one session exactly: you, the attendees or someone else? And also why? And why doesn’t it work? Try to find the root cause and solve that problem. Try to make small improvements and review those improvements. And do not let other people decide what a Guild should or should not do. Let the Guild decide themselves.
- It is getting too big… people from other departments would like to join in, testers are joining the development Guild session now as well. HELP? Why? Why do you need help? Congratulations! You made it a success, you don’t think in silos. Wouldn’t it be great if developers will learn more about testing, testers more about development, and support engineers join the Testers Guild?
Closing thoughts and where to go from here
Organizing guild sessions, making people aware and giving them the opportunity to learn is important. In my opinion, it is part of creating a self learning organization. However, it can be very challenging to set up the Guild sessions. However, when you get it up and running, it can be very rewarding. So give it a try, inspect and adapt, make it a success!
If you want to read more about Guilds I advise you to read the workout Business Guilds and Corporate Huddles that Jurgen Appelo describes in his book Workout. In his workout he also refers to other articles and blogs about Guilds.
Innovation: the buzzword of today. Every company claims they need innovation to stay relevant. Without innovation there is no future. Adobe has Kickbox, Google has a 20% time policy, Atlassian has ShipIt Days, etc., etc.
Kickbox is a new innovation process that Adobe developed for its own use and then open sourced so everyone can use it. Adobe Kickbox delivers an actionable process for discovering new opportunities, validating customer engagement, and evaluating new business potential. It includes tools that help innovators define, refine, validate, and evolve their idea. I feel that you could ask yourself the question, however, is it really possible to define a process that stimulates innovation, a process that will fit everyone? Or should people be free in their approach? After all, you cannot really schedule something like next week tuesday person X will do a remarkable discovery.
At Google they state “We encourage our employees, in addition to their regular projects, to spend 20% of their time working on what they think will most benefit Google, this empowers them to be more creative and innovative. Many of our significant advances have happened in this manner.” Huge 20% products include the development of Google News, Gmail, and even AdSense. In 2013, Chris Mims wrote for Quartz that 20% time was “as good as dead” because it became too difficult for employees to take time off from their normal jobs. So how do you make sure that people have time to contribute and that it is really adding value? That giving people 20% is not only there to promote your company but that it actually leads to something?
Atlassian describes their ShipIT days as: “24 hours to innovate. It’s like 20% time. On steroids.” Team members can work on whatever they want. Something that inspires them, a dream feature or just smashing a huge bug. They can assemble their own team. It offers a chance to combine ideas and skill sets from different teams. They have 24 hours. Execution matters too, but the best idea wins. What happens, however, if you fail to come up with that great idea in those 24 hours, is what I ask myself?
Now in his Book #Workout, Jurgen Appelo describes the concept of Exploration Days. In basics, it investigates the notion how many organizations struggle with self education of employees. Jurgen states that a very effective way to make learning enjoyable is for people to organize themselves using exploration days. It is just a name, but essentially a group gets organized themselves and take 24 hours to explore something, no further strings attached. They are sometimes also called hackathons or whatever days. 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 is 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.
At a previous company we organized an R&D Summit. As a distributed shop we regularly chose to have all R&D Employees in one location so we could see eye to eye on things! This was the best moment to organize the first Exploration Day. A colleague manager and I organized the R&D Summit and therefore also the first Exploration Day.
So what did we do, what happened and what did we learn… Organizing such an event itself is not that difficult, you will manage. However, to make sure you learn from our mistakes or successes, I want to share them with you (in a random order).
1. It is mandatory for people to participate, or is it…
There were various discussions with people new to the concept of Explorations Days, for example the HRM department. We explained the setup of the Exploration Days and told them that we felt it was not mandatory to join. People could decide if they would participate or not. One of the remarks we got was that we had to make it mandatory. Not sure why the person said this, perhaps the notion of one size fits all, but the person concerned was definitely new to the concept of Exploration Days. We explained that you simply cannot force people to participate in an event like this. Imagine you are in a group of enthusiastic people, and there are two or three people who are required to participate but they do not really want to. I do not think we have to explain the impact on the morale and the stress this can cause in a team. On the other hand there were more than 100 potential participants. So it was up to us to make as many people enthusiastic.
So our view, do not make it mandatory. People should be able to decide for themselves if they want to join, or not.
2. Lead by example
You are a manager/facilitator/coach/project lead/… anything except a developer and you want to organize the Exploration Days? Good idea! You can take care of the facilities, of course that is you role, but will you also join in? We most firmly believe in lead by example and therefore also participated. Not with a development project, that would make me look silly because my development days are long behind me. I decided to work dedicatedly for 24 hours on my new Chromebook… in our corporate environment. I tried doing all my regular tasks and tried to find out if a Windows laptop is still required to get my business tasks done. As a side note, I learned that a Windows laptop is still required to work effectively. Office365 is not yet mature enough and interacting with people who work in a Windows environment (Skype and OneDrive) is hard when you are working in a Google environment (Hangout and Google Drive). The most important thing is, I participated! I created the first project description on the Wiki section Exploration Days and tried to lead by example. The other organizing manager was not able to participate due to his working part time and taking care of his kids one day a week. He did, however, pass by in the evening when the kids were in bed, inquiring all teams how things were going and if they needed something, if only a pizza or a cup of coffee. Actively showing a genuine interest in people, what they were exploring and how things were doing proved to be highly appreciated by the teams taking part in the Exploration Days.
In short, participating or at least being there and showing an interest worked well for us.
3. People feel guilty
Good professionals love their job and are committed to deliver great products. They love to help the customer, in this case the product owner. As a result, people tend to focus 100% on their job and sometimes forget to take time to develop themselves. They even do so when they get an opportunity to participate in Exploration Days. We informed the Product management team and the Program managers a few months before the Exploration Days about the upcoming event. Be careful we said… worst case scenario is that the whole department will participate in the Exploration Days and they will not be available to you those 24 hours. We tend to be optimistic :). This could impact the progress of your iteration, project or release if you do not take it into account. We communicated to everyone quite clearly that everyone could participate, and that the Exploration Days had the highest priority. It turned out we did not communicate well enough. We could now make excuses that people did not read their mail, but I believe you should always look at yourself when somebody did not get the message. There were some people who did not join the Exploration Days because they wanted to focus on the project and would feel guilty when they would join the Exploration Days.
Next time we will communicate more clearly about such an event. We will, for example, attend all standups and following a standup make sure that everyone understands that they are allowed to participate in the Exploration Days, no need to feel guilty. Perhaps we will even do it a couple of times (do you know what is coming? did you form a group yet? do you have an idea yet what to explore?). Make sure you have full support of the entire management but also that all team members know they are allowed to participate. Additionally, do not feel sad when not everyone joins in. Some people just prefer to focus on their work at hand.
4. Management asked for success criteria
Management asked us to define goals regarding the R&D Summit to check if the R&D Summit was a success and part of this R&D Summit would be the Exploration Days. We thought about it… and came up with the objective “Organize R&D Summit to improve knowledge”. We identified three important results:
- At least 75 people of R&D attend the Super Guild Event
- At least 23 people participate in the Exploration Days
- We do not spend more money than in the budget
The second result was about the Exploration Day. Why 23 people out of a potential 100? According to the 2015 Developer Survey of Stack Overflow, the average developer spends more than 7 hours per week coding on the side. We expected only the developers who spend more time than average to attend the Exploration Days. This is 22% according to the survey. Therefore, we wanted 25% of the people of R&D to attend the Exploration Days. In the end a total of 36 people attended.
At first we were a bit puzzled by the question from management: what data were they specifically looking for and how do you measure whether something is a success. We believe in management based on data, so again lead by example. By defining these criteria, we showed to management AND to ourselves that the Exploration Days were a success. When everyone was back home, we sent out a survey with questions to gather further feedback. Did people attend the Exploration Days, did they receive enough information, etc. This data showed us that the people that participated really liked and will do it again.
Think about your goals, yes it is fun to organize Exploration Days. However, when is it really a success?
Sorry to say… but sending one mail to everyone and telling them that you are organizing Exploration Days simply is not enough. You have to promote your event, like professional marketeers do and you have to repeat your message. We first came up with this poster.
We, or at least I was proud of it. My partner manager kindly suggested to ask one of our own visual designers and/or interaction designers to make a poster. OK, I said…. the following result clearly shows that I have other talents.
We also made a movie, a short and fun movie to explain the concept to people. It is fun but recording it was a bit awkward for us :).
We then sent mails to keep people warmed up for the idea, we posted updates on Yammer, we specifically invited people who are always trying new things out to register a project for the Exploration Days.
Don’t wait till people register a project, you have to interest and challenge them. It is your task as a manager to motivate people to participate in events like this.
6. Sharing what people learned
Perhaps the most impressive moment for me was the session where the groups shared what they learned with everyone. We just had a beamer, a screen, a table and a group of enthusiastic professionals eager to learn what other people managed to find out. We invited everyone from R&D, optional of course. However, almost everyone was there. The participating groups all had one person showing the things they learned, sometimes it was just that things didn’t work as expected and sometimes it was really adding value to our products. Now what was really cool was that people who normally never would present something for a group, chose to be the ones from the group to share their findings and they got a big applause from everyone. Goes to show that when you are passionate and knowledgeable about a subject, it is not that hard to give a good presentation, even when the presenter still feels it is scary! We got to know some people in the organization being really capable of presenting in a fun and passionate way where we never expected that from them.
In total there were 13 projects. We wanted to give everyone a fair opportunity to present their findings, including some time to get “on stage”, “in the zone” and “off stage”. We scheduled 10 minutes for every team, so roughly 15 minutes per team. Multiplied by 13… resulted in almost 3,5 hours. It was fun. There were some good laughs and everybody loved the knowledge sharing and the passion to be seen in colleagues that you perhaps may not know that well. However, it was very close to taking too much time. Energy levels and concentration dropped. We will make sure that we have chairs for everyone next time. We may also split the sessions in two parallel tracks and record them on video. However, I know everyone loves to see everything in real life.
Make sure you think upfront about how to share the results, and be aware it can be a long session.
We, the organizers, loved organizing these Exploration Days, it was fun and we really enjoyed seeing all the energy. People who attended also liked it, 67% said they will definitely participate next time. However, next time will be different. We choose to do it in a distributed setup then.
Oh yeah since we are at it, I just mentioned six things… What about the other 232 things? Well, I don’t know… but it seems a blog nowadays has to have a number in its title and I was exploring whether the higher the number… the more readers ;)?