I’ve written an article for InfoQ on engineering team speed, inspired by my Why Is Everything So Slow? presentation that I’ve given at Agile On the Beach and Lean Agile Scotland this year. Find out what slows down engineering teams and how to avoid getting the question ‘Why Is Everything So Slow?’
The full article is only available on InfoQ at the moment but I hope to also post it here soon. So head over to InfoQ to read more.
I recently spoke at the Agile In the City London conference. As well as watching a number of great presentations, I also was lucky enough to be able to give two presentations and I’ve shared the slides below.
tl;dr No-one really likes performance reviews. But giving your team members good, actionable feedback and setting clear direction with them is very important. In my team we changed how we did performance reviews.
Note: This is the last post in a series on performance management and review. It’s worth reading the other three first:
As I mentioned in the last article, we ran the new process for four checkins, i.e. one cycle and then sought feedback from the team. They told us that:
So we now had some feedback to work with. Overall the experiment had been a success and was worth continuing with, albeit with some small changes. So what did we change?
When we rolled out the initial version of the improved process we wanted to keep things simple. This meant having a small number of different themed sessions (the Atlassian process has six different themes – we had used four of them). One thing that was missing was a session where the team member could just discuss anything that they wanted. This session became the Check In.
It’s a general catch up with no agenda. As with every themed session the team member also discusses how they think they have performed and gives themselves a feedback score, and the manager then gives the team member feedback and a score themselves. Any differences are then discussed, just like in any other session.
Team members are also encouraged to put any important agenda items to discuss into the checkin form beforehand so that the manager has time to prepare.
The session is targeted at 30 minutes only, as usual.
The second themed session that we introduced was 360 Perspective. Feedback had shown that team members would appreciate getting feedback from not only their manager but also their peers. The company performance management process mandated this should happen once per year.
Feedback is important but most people do not like or feel comfortable giving feedback. There’s multiple reasons for this:
The 360 Perspective session gives the opportunity for the team member to collect feedback prior to the session, add that to the form, and then discuss with their manager during the session. Managers are of course free to also collect feedback for discussion as well, but all feedback requests should be open and visible to all rather than anonymous.
In the future we hope to make feedback gathering and discussion a team activity.
Our team members had also told us that they thought that some of the sessions were too similar. On further investigation this was because sessions that had similar themes (Love&Loathe and Removing Barriers for example) were too close together, resulting in similar topics being discussed in each. Since new themes were also being introduced then there was also the opportunity to change the timeline and space things out better to remove potential duplication and a perception that some or all of the process was not valuable enough.
The new timeline not only spreads things out better but it also aligns key activities such as 360 Perspective with the expectations of the yearly, company wide, performance management process. This enables both processes to effectively co-exist.
This was also a good opportunity to remind everyone of the need to make sessions short and punchy, therefore avoiding making the whole process too time consuming.
As well as introducing the new themes we also made changes to the form (get in touch if you want a copy). We added a clearer section for managers to leave feedback and the results of each session so that the form built up into a month by month record of achievement for each team member.
By doing so we enabled a very simple end of year discussion, as mandated by the companies yearly performance management process. A quick discussion to collate the month by month feedback, combined with feeding back the average of the monthly performance scores is all that is necessary. In order to set expectations as we go through the year then the form also now includes a predicted rating and graph of each team members progress.
So there’s no big performance review session that no-one looks forward to, no surprises for team member or manager at review time, and no concerns or fears about the outcome.
If you want to learn more about introducing a more regular and valuable performance feedback and review process then the links below are worth reading:
tl;dr No-one really likes performance reviews. But giving your team members good, actionable feedback and setting clear direction with them is very important. In my team we changed how we did performance reviews.
Note: This is the third post in a series on performance management and review. It’s worth reading the other two first:
In part two of the series I talked about how my team and I took the performance review and feedback system that is used at Atlassian and adapted it to suit our groups context. I talked about the themed ‘checkin’ sessions and how we got the whole group working to a common timeline for review and feedback, and the advantages that brought.
We what happened? How were the changes received and what was the feedback from the teams?
Once we were clear on our direction, we had agreed as a leadership team how we wanted the process to work and what themes we were going to use, then we prepared to sell our idea to the rest of the team. I strongly believe that one should not dictate changes that affect people’s career development or relationship with their manager, and so it was critical to us that the team members were bought into the ideas of the changes and our reasoning for proposing them.
We gathered the team together and explained the new process and how we felt it benefited them. I explained how I felt that the traditional process was sub-standard and could be improved. The key messages were this:
Feedback is better when it’s timely and so we want to start a process where that timely feedback enables higher quality discussions about you
As a group we agreed to run the process for one cycle and then review the results. If, after that, the teams were happy to continue then we would continue and if not then we would stop and revert back to the company-wide yearly cycle.
The issue with selling an idea to a group is that often, in private, people will express their reservations more freely. So it was key to ensure that managers then spent time with their team members and gave them the opportunity on a one-to-one basis to discuss the new process. This was also a good opportunity for managers to explain the process in more detail and seek additional buy-in.
The checkin sessions themselves are intended to be 30 minutes long in order to ensure that the process does not take too much time every month. It ensures that only the valuable things are discussed, and the sessions can be to the point and targeted at what matters. However, since this was a new process then we ensured that the first few checkin sessions ran to an hour so everyone could get the hang of it.
Since checkin sessions were short and punchy – although not literally 🙂 – then it was critical that everyone prepared for them. The checkin’s process works if the team member comes to the session having already prepared what they want to talk about. In order for them to be able to do that then we needed somewhere that they could document their thoughts.
Being an MVP then we did not want to spend much on supporting tooling (there is an excellent tool called Small Improvements which supports this sort of process) so instead we designed our own form. It’s simple and includes questions that the team member should answer in order to prepare for the session. The idea is that they fill in the relevant tab before each session, the manager can then review and prepare based upon the information they’ve entered, and then the checkin session itself can be focused on the discussion and actions from that discussion, rather than the actual ‘thinking’ time. It allows sessions to be targeted and valuable.
We designed our own form to support the process. If you’d like to see a copy then get in touch. We used the questions below to drive discussions: 
Another advantage of using the form was that each team member built up a record of their year, what they had done, and how they had performed. This meant that when we did need to provide yearly feedback into the main company process then it was simply a matter of extracting the information we already had in each form. It was also great to encourage team members to look back through their forms to see what they had achieved throughout the year.
By meeting with our team members every month for themed, targeted performance and career management discussions then it also meant that we had a great opportunity to give them quantitive feedback. Like a lot of companies, we use a four point scale and at the end of each year every employee receives a performance review score which has an impact on salary and promotion – standard stuff in most companies. Once per year with no indication in-between how they are performing relative to that four point scale.
This seemed unfair so we adapted the checkins process to also include giving the team member feedback each more on how they had performed against the scale and why. This helped solve multiple complaints against a yearly system:
However, merely getting a feedback score from the manager still presents a surprise and it was important that the manager was able to have a meaningful two-way discussion about performance. In order to drive this we asked each team member to give themselves a score, on the same scale, before the session. This enabled the manager to then understand how the team member felt they had performed, and it encouraged the team member to think about their achievements during that month. The discussion, held towards the end of the checkin session, could then be focused on any differences between the manager and team members interpretations of their performance.
The first rounds went smoothly. One thing we learnt pretty quickly was that it took time to adapt to the process and so running the first couple of checkins for each team member as hour long rather than 30 minutes was definitely necessary. There was also some prompting required of some team members in order to get the forms filled in prior to the checkin session rather than during the session but this was to be expected given that the process was different and new.
People were surprisingly happy to provide a feedback score for themselves and by asking them to do so, we were able to make more meaningful and example based discussions on how they had performed.
As we had promised, we ran the process for four checkins, i.e. one cycle and then sought feedback from the team. Broadly speaking it looked like this:
We now had some feedback to work with. Overall the experiment had been a success and was worth continuing with, albeit with some small changes. Overall we had:
In the last article in this series I’ll explain what we did in order to improve the process to suit our context even better, and some of the key learnings we got from running the process over a longer time period.
tl;dr No-one really likes performance reviews. But giving your team members good, actionable feedback and setting clear direction with them is very important. In my team we changed how we did performance reviews.
Note: This is the second post in a series on performance management and review. If you haven’t read the first one on Improving Performance Reviews then I recommend you take a look at that first before reading on.
As I mentioned in the previous article, a cycle with yearly performance reviews doesn’t work. Objectives become irrelevant or forgotten, the business and team landscape changes, and people simply don’t get comfortable being a part of, or good at, something that only happens once or twice a year. As a result the traditional performance reviews and objective setting cycles that a lot of companies use end up becoming de-motivating for both team members and managers and are just something “to get out of the way” each year before moving onto “real work”.
It doesn’t have to be like this.
Both me and my management team were becoming frustrated by being part of a performance management process with yearly performance reviews that we felt was not enabling us to get the best out of our teams. We wanted to change things. But, as part of a large company with pre-existing people processes, we did not have the mandate, nor the time, to initiate company wide change. So what we did was driven by a need to make both a positive change for our teams and also to still fit within the existing yearly cycle that the company uses. An attempt at getting the best of both worlds. And to fly a little under the radar while we proved the concept.
Let’s not forget, as Grace Hopper once said – “It’s easier to ask forgiveness than it is to get permission”.
So we made some incremental changes which we feel has had a positive effect on our team’ member’s career development, their motivation and our motivation too.
When it comes to anything involving people then it pays to seek advice from as many different people and sources as possible. We looked at how a number of different companies were doing their performance management, companies ranging from those that did no formal sessions, to those that did a lot. There was one that really stood out – Atlassian. What Atlassian had done with performance management seemed like something that would fit with our thoughts on the types of changes we wanted to make.
I won’t explain why the Atlassian model is good in too much detail, because they have done a great job of that themselves. I suggest you read their posts which explain much more.
In short, what they had done was take the traditional model, split it into bite sized chunks, distribute these throughout the year and enable timely performance feedback. Exactly what we were looking for.
Now, it’s very easy to read blog post after blog post about other companies cultures and how awesome they are. I’ve seen it argued that a key measure that investors use when deciding which start-ups to invest in is the company culture, and so companies blog copiously about their perfect culture. Even if they aren’t exactly the whole truth. It’s always wise to treat these article with a pinch of salt and find somewhere else that has actually adopted similar changes. Fortunately we found that REED, a large UK based recruitment site had taken the Atlassian model and were using it day-to-day.
So we contacted REED and spent some time with their technology leadership team discussing how they had implemented the Atlassian model and what their experiences were. After those discussions we felt confident that the Atlassian model, while it would require some adaptations to suit our context, was usable, workable and something worth trying.
Given that we needed to work within the company performance management cycle and policy then we were able to take some parts of the Atlassian model but not all. The model overall splits into four different areas:
Unfortunately we had no control over the payment of bonuses, and the performance evaluations (a.k.a a yearly performance ‘score’) needed to be fed back every year. Changing this just for my group was not possible and even if we had been able to do so, it would have presented a very confusing view to the team members who are also part of a wider technology team not using our new process. There was also the danger that if we started to evaluate our teams differently then that could have impacted how they were evaluated in comparison with their peers outside of the team, with potentially negative consequences. So we focused on implementing a system with bite sized chunks of feedback and review, together with ‘scoring’ using the same four level system that was implemented across the company.
The Atlassian model uses six different themed sessions called Checkins to drive performance and career development conversations. These are held monthly, targeted at taking about 30 minutes each and the discussions are led by the team member. Everyone has the same checkin at some point within the same month.
For our initial MVP of the process we decided to use four of the themes:
It was very important to explain the different checkin themes to the team, set expectations on what the team member needed to do to prepare and what the intended outcome was of each session. That way we could explain the value that could be gained from each session. We prepared cards that each team member could use to understand more.
It was also important to ensure that it was clear to everyone when discussions needed to take place. By ensuring that everyone in the group (managers included) had the same themed checkin discussion each month then, as a leadership team, we were able to meet at the end of the month and identify any common themes that had arisen from discussions. For example, was there something that was blocking a lot of people? Could we allocate some budget or additional focus to doing more team building, changing a process, buying more equipment, etc that would benefit the team as a whole? Were there some stakeholders that multiple team members were having issues with connecting with? What was making the team members happy and therefore we should be doing more of?
By having a common dataset at the end of each month we were able to have far more meaningful and valuable conversations about change than we had been able to have before.
We used the timeline below to ensure a common focus across the team.
In the next article in this series I’ll explain what happened. How did we roll out the new process to the team? How did we continue to evaluate performance in-line with our new monthly process and the companies expectations, and how did we ensure a common approach to preparing and recording the output of each of the checkin discussions? How was the new process received by the team?
tl;dr No-one really likes performance reviews. But giving your team members good, actionable feedback and setting clear direction with them is very important. Yearly performance reviews don’t encourage this to happen.
Note: This is the first part in a multipart series of posts on performance management. In my team I changed how we do performance management. Future posts explain what changed and what happened as a result. This post sets the scene.
It’s fair to say that the traditional way of doing performance reviews is exactly that, traditional. Many companies work on a yearly cycle, with managers setting their people some objectives at the beginning of each year then reviewing them at the end. It’s likely that it’s been that way for ever. Sometimes if you are lucky then they’ll also be a mid year review.
I have a problem with this way of managing performance. We try to teach our teams to think in the present, to inspect and adapt their ways of working and the feature sets of products themselves, regularly and iteratively. Yet when it comes to the people we do the opposite. It doesn’t make sense.
I’ve seen the following problems with the yearly review cycle in a number of companies that I’ve worked in. The same concerns and feedback every time.
Firstly there’s a huge gap between when someone is set some objectives and when those objectives are reviewed. Objectives get forgotten. A person’s goals and motivations change. The business landscape changes. You get to the end of the year, review the objectives and discover that none of the objectives that a person has are relevant anymore. The logical action when faced with this situation is to just ignore the objectives and review someone based upon feedback and your own personal viewpoint. Your team member gets the same performance score they did last year and then the whole cycle starts all over again.
In this situation you should think about the message that this is sending to your team member. You’re essentially saying “objectives aren’t really that important”. Don’t be surprised when you don’t get the buy-in next time objective setting comes around.
When companies are tied to yearly performance review cycles then early December and late January are the periods that managers hate. Believe me, it’s where you really get to be the bottleneck. There’ll be expectations from HR that you do all your reviews by a certain deadline. It’ll be the same deadline as all the other managers have. Everyone will be running around trying to do the same things. Free meeting rooms will be pounced on by the first person who sees free space in the calendar. Everywhere will be full of people in groups of two talking quietly.
Preparing for a performance review is extremely important and a manager can’t just rock up to one without having prepared. There’s a lot to be done. Feedback to be requested, notes to be collated, memory banks to be queried to remember what happened almost twelve month’s ago, feedback to be re-requested, notes to write, the review itself and subsequent follow-up. That’s just for one team member.
A yearly review cycle effectively takes the entire management population out of delivery work for two months a year. It creates bottlenecks. It’s one big performance management big bang. That’s not how we deliver software anymore.
It’s also disruptive for the team members. Suddenly everyone is being asked to provide feedback on everyone else, everyone is preparing for their own reviews at the same time and because those reviews only take place once a year then they take a long time to complete.
There is nothing more annoying than being told “well that thing you did 6 months ago – that wasn’t good”. You have no chance to change the situation and little chance to effectively learn from the feedback. The time will have past and the opportunity to change may well have gone as you’ve moved onto something new.
Yearly performance review cycles don’t of course preclude managers from giving regular feedback to their team members. But they do make it easier not to give that feedback, and not to seek it from others. They subtly encourage us to think that ‘proper’ feedback is only needed to be given once a year. That’s wrong.
When you do something regularly then it becomes easier. You learn how to do it, your brain becomes wired to do certain parts of the activity almost without thinking, and you lose your fear of something new. Mastering a new skill and gaining the confidence to do it well takes time and practice.
We don’t get to practice the art of performance reviews regularly in a yearly cycle. At best a manager may well have done about ten reviews a year for a couple of years at a company. Those reviews come round only once a year, by which time a lot of the skills are forgotten or take time to become natural again. You make mistakes, those mistakes de-motivate your team members and just as you feel like you’ve got your review mojo back, then it’s time to put it away again for another year.
This also applies to your team members. They get reviewed once per year. In fact it’s worse – they get fewer opportunities to get good at reviews than you do.
It’s human nature to fear change and to feel anxious and apprehensive about something that is new. A yearly performance cycle becomes something that neither manager nor team member looks forward to, precisely because it happens so infrequently that no-one get’s the chance to feel confident doing it.
When reviews are yearly then it you can find yourself trying to remember what both you and your team members were doing almost twelve months ago. Even with the best notes in the world, and the most fastidious team members, there will be points that are forgotten.
Feedback from other team members and stakeholders won’t focus on what was done in the past – when under pressure to provide feedback for multi people (which happens more under a yearly cycle) then people remember the recent past far better than something that happened months ago. And if they do remember something from months ago then it was probably an event they perceived as negative. Bad memories stick better than good ones. The feedback you get will come with an unintentional negative bias. Or it may not even be true at all.
I’m a strong believer is delivering software iteratively, seeking regular and timely feedback, and adapting as a result. In my career I’ve done this enough times to feel that this is the least risky way to deliver. We learn as we go along, and we change approach, feature set, timescales, etc when required.
One key metric I like for a team is lead time. How long does it take us, from the point at which we receive a request, to the point at which we deliver it? Enabling a suitably short lead time to enable the team to be nimble and adaptive is key to delivering valuable software. A yearly performance management cycle has a lead time of exactly that, one year. The opportunity to adapt is tiny.
I believe the traditional yearly performance review cycle does not work. It does not enable timely feedback, does not exploit our desire to work in the present, it’s time consuming and it’s demotivating for both team members and managers.
In my team we decided to do things differently. We changed how we do performance feedback and performance reviews. The next article in this series will tell you what we did, how we did it and what happened.
We had some great discussions at the last West London Lean Coffee session which was held in Carluccio’s in Westfield on 2nd March. Here’s a brief write-up of what we talked about.
We talked about how to go about finding a CTO. If, as a founder, you have a great idea but no clue about how to get the technology enablers completed in order to get to market then what should you do?
We discussed using specific CTO and founders meetups and websites to help with the search. It’s important to spend a lot of time choosing the right CTO (so many startups fail due to differences of opinion between the founders and early employees). Having a strict spec can be un-helpful and it’s as much about whether one can work with someone, than it is about their pure technical skillset.
There’s also the opportunity to consider part time CTO’s to help guide you. We also talked about whether having one right from the start is even required and that time would be better spent iterating over an idea, testing it through marketing or consumer research, before even thinking about how to partner with someone to built it.
What does a good MVP look like? How do you go about defining it?
We talked about whether it’s actually better to look at Minimum Pitchable Product first, vital for securing funding. We also discussed trialling ideas on customers, segmentation and why it’s important to consider that the customer base is not a base of you.
Revenue can be your best proof of an idea or a minimal pitchable product. You need to prove that you can deliver value.
In that respect I’d certainly recommend reading The 4 Hour Work Week by Tim Ferris which contains a lot of tips.
What should you look for when choosing an Agile Coach? What behaviours make great coaches? We came up with this list:
How can we ensure we are aligned to the needs and value gained from customers? We talked about gathering value as early as possible. But in order to do that one needs to understand what value means and this has to come from stakeholders. Identification and relationship building with those stakeholders becomes is so important.
How much should a team feedback progress during a sprint vs just getting their heads down and getting on with it?
Our discussion started by talking about the pros (stakeholder management primarily) and the cons (perceived lack of trust, reporting overhead) of providing visibility. We agreed that the key point was not to disrupt the team during the sprint and to that end, automated reporting solutions (within popular tools like JIRA, Trello, etc) were key. But on their own reports could be misunderstood and lack context so if teams do want to report during sprint then there is a human overhead to do that, perhaps falling to the Delivery Manager or Scrum Master.
The next West London Lean Coffee will be on March 30th in Carluccio’s in Westfield at 8:30am. Hope to see you there!
West London Lean Coffee – November. Here’s a write up of the event.
We had a group of 9 people and some great discussions.
We talked about experiences of Beyond Budgeting and how working incrementally can help finance teams support agile technology teams. We thought that this would work best in non listed companies, and the key point was enabling buy-in from finance teams to the approach. Wondering what Beyond Budgeting is – look at this post.
How can you convince a team to try scrum, or any other agile methodology? How can you demonstrate the savings that could be possible? We discussed how focusing on the outcome was important and how selling a change as a low risk experiment could help you get approval to try something new out. It’s well worth looking at the information that Government Digital Services make available for hints and tips – if it works in government then it must be do-able elsewhere, right? 🙂
Some great discussions about the differences between small and large companies and their cultures. We agreed that behaviour was very important and how the requirement for more structure comes as companies grow. There was a great example of sizes and one scales; making a business unit max 80 people, a squad no more than 12 and teams of 6-8. Once one reaches these limits then it’s most likely time to start thinking about an alternate organisational setup in order to keep a company able to effectively employ agile methodologies
It’s worth checking out Management 3.0 for more details on ways in which you can help build great teams.
We talked about how joining a new team is a challenge and how one might initiate change, despite being the new person on the team. The key point were to not focus on agile as such, look at the culture and pain points and lead by example. Use the opportunity of being new to ask simple questions and highlight what might appear obvious. And make sure that the team can see what the improvement could be by using some agile approaches.
It’s also worth establishing if you have a remit to change things and if so, then understand what the change appetite of the company is.
The next Lean Coffee is on December 15th, 8:30am in Carluccio’s Westfield, Shepherds Bush. Hope to see you there.
Last week saw the latest edition of West London Lean Coffee, slightly delayed from October into early November. We had a group of 8 people and some great discussions.
A detailed discussion about whether the agile principles are still valid and if they are not then does the manifesto need updating. Is the language right? Is it just a matter of applying general principles to the correct context?
It’s worth reading this article from Ben Linders on the same subject.
How can you transition teams from waterfall methodologies? We talked about the complexities when fixed deadlines are involved and how negotiation with Product Owners is key. We then discussed about the importance of focusing on outcomes and not outputs from a team and avoiding falling into a trap of merely doing mini waterfalls. Identifying where the value is and tying everything to measurable business goals can help. I’ve found a lot of what Johanna Rothman has written to be very useful in the past so it’s worth checking her website out.
Impact mapping is also great at ensuring that the team are focused on outcomes from the start.
We spoke about the difficulties of retaining employees when the contracting market is so strong and what could be done to help. Focusing on team culture is key and ensuring that there are strong, personal bonds between team members. Treating people like adults and helping them adapt to change, while protecting a team from a lot of outside influence can also help. The focus on autonomy, mastery and purpose in a role can mean that the money aspect becomes far less important.
It’s worth checking out Management 3.0 for more details on ways in which you can help build great teams.
We talked about whether it was best to have one large Kanban board that covered a number of different workstreams, or let teams have their own. It was agreed that team ownership of boards was the clear winner and something like a portfolio board could be used to bring the results together if needed. We then talked about how using a tool like JIRA could also help and could be used for reporting as much as tracking.
It’s worth checking out some of the presentations from LeanKit as a starter to learn more and this blog post about Portfolio Kanban.
What’s the best way to integrate UX and UI design into agile? Do you just have the designers work a sprint ahead? But what happens if there are problems with the designs?
We spoke about how putting regular checkpoints or design reviews into the process can help and getting the ‘QA’ aspects of the design process as early as possible can de-risk having design ahead of development.
The next Lean Coffee is on November 24th, 8:30am in Carluccio’s Westfield, Shepherds Bush. Hope to see you there.
West London lean coffee runs every month in Carluccios in Westfield Shepherds Bush. Here’s a brief writeup of this morning’s session.
The next session will be on 27th October. Hope to see you there.
How much are activities like 10% time and hackathons of benefit to the team and the business? What works for one team may not work for the others. We had some good discussion on context and why giving room for innovation is important.
Some great discussion on whether adopting agile and lean works for management teams, a.k.a. the scrum of scrum masters. The idea of quick, focused meetings, transparency and team involvement is important no matter whether it’s a team of developers and testers or a team of managers. Some great tips including ‘make the focus of meetings on how to improve’.
What happens when you join a company and you find out that they are not as agile as they implied during the interview? Should you try and change the company from within or cut your losses and move on. The questions that you ask in the interview are important and need to be detailed enough to ensure that you really get a feel for the company culture. We talked about how successful agile transformations are not technology focused and how working with HR and finance first can be the secret to a transformation that works and becomes embedded in company culture.
We talked about persona’s and how those seeking to validate product ideas can use them. There was some previous experience in the group with the use of persona’s in technology and software development, including testing, in order to understand the customer better. We discussed how segmentation is important but need to be detailed enough to be useful.