…. and there were a few problems.

This is a quick summary of a clients I went to and what I did in the very short-term, just the first few weeks to start to improve the way that people were working and thinking, its also a cautionary tale of what can happen if you don’t follow through.

The first and probably the biggest issue was that people were trying to be magicians and manage invisible work. No one had a clue what work the team had on or what anybody was doing at any point in time including the team themselves.

There was a lack of work coordination leading to the guys on the team frequently duplicating work, you can imagine the conversations, “Oh so you were doing that too, it would have been nice if I’d have known”.

This lack of coordination meant that team didn’t feel like a team, they were a set of individuals with the label “team”.

This feeling was reinforced by the manner in which they were being fed work, one piece at a time by their manager, in a piecemeal fashion. An additional issue here was that their manager was a senior tech and was estimating work for them based on the managers knowledge and experience not the teams. The team had little or no say in what work they were getting and the timelines they were being held accountable for, they had to a large extent no autonomy or say around how their work was being allocated.

As there was no common shared understanding of what each other was doing, it also quite frequently meant that when somebody was off work and whatever piece of work they were doing suddenly became this weeks most important item, nobody could pick this up so they had to start again from scratch.

The team also had their own little pet projects that no-one was aware of, they were simply working around the what they were being given and concentrating on what they thought was important.

There was no QA / Test function and  the team were delivering work straight into live,  without even the most rudimentary of checks being carried out.

The impression of management was that the team was not delivering what they should have being doing, so quite simply it was the teams fault which demonstrated a lack of ownership of the issues by the managers

As you can guess this wasn’t the most motivated of teams and sadly this is not an unusual set of circumstances.

So what did we do.

  1. Make the work visible; Work was being held in emails, spreadsheets, on pseudo scrum cards on a desk and in people’s heads. In short just about anywhere it is possible to hold work without it being visible. So we pulled all of the work into Jira at his point not really caring how its was written down, we just wanted to make it visible.
  2. Start daily coordination meetings: We started a simple daily coordination or standup meeting so people could start to discuss the work that they were doing, this was done around a Jira Kanban board. Kanban tells us that we should model the actual work process being used and not some idealised or fake “this is what we do honestly” version, it doesn’t help us where there simply is no process other than do stuff being followed. So I created a very simple process to start with, acknowledging that this would be wrong ( it was) and that as it was the teams process it would have to be changed but by them.
  3. Introduce basic quality checks: At this point having a separate QA person was not really possible due to recruiting constraints, however introducing a very simple peer review step carried out at the test step above, this also drove common understanding and facilitated learning and a sense of mastery. We used a simple definition of done and popped up a checklist at the place that the team marked things as done, yes its a checklist and the risk is that we over simplify things, but I find that they can be useful in early stages to get momentum going, you just need to know when to stop using them.
  4. Start weekly planning sessions: Getting the team to discuss what was coming next for the coming week, in collaboration with the manager and the managers, manager drove out coordination issues between the managers, who were not on the same page from a  what was being done and completed perspective. The conversation went “what do you mean that hasn’t been done yet”, this allowed the team to be involved with what was being done and more importantly why, it also empowered them to challenge the decisions being made, in short they got some autonomy and started to understand their role or purpose in things.
  5. Focus on Value: It was clear that nobody was really acting as a product owner, with a clear understanding of value. It was also clear that what was value would be a conversation for a later date, but immediately we needed one person to make decisions about what was coming next and why and not multiple people as was happening, this was the managers manager and they became our product owner.
  6. Backlog: We needed a single backlog view of the work on hand, this was divided into:
    1. Un-ordered backlog: This is a list of stuff, its ideas about what could come next, it has not had too much effort put into it as probably two-thirds will never get looked at, so the product owner is free to play around with this as they see fit.
    2. Coming Next: Work agreed at the planing session, so its had a bit more effort put in to understand what the items are and p[provide a very high level guesstimate . However until it’s pulled into the development system the product owner can change these items, but at the same time being aware that some time has been spent looking at these items so there will be wasted time if they are change.
    3. In flight: This was work that the team had committed to at a weekly planning session and had started work on, whilst it is still possible to change these obviously the waste goes up the more time we have spent on the item so it should only be stopped in extreme circumstances
  7. Push back on interruptions and focus on whats at hand: It turns out that the team were being helpful, some more helpful than others and this was well unhelpful. What we really needed the team to do was to focus on the work being pushed to them through the product owner and not spending hours off chasing faeries or squirrels.

I really do believe that you have to start with building the team, people are the most important part of the process and Autonomy, Mastery and Purpose are the keys to making really, sustained change happen. So  everything that I do is aimed towards empowering teams to take charge of their own work practices and ultimately their own destiny

The next action was really not to do very much, we had acted, added some process and policies so next we analysed the results of what we have done and then we responded as we started to see patterns developing and things stabilising to improve things further.

I wanted what we had started put in place to really embed, so that the guys could do this without me and I knew that my time with them was short so I didn’t want to pile too much on their plates. After about 6 weeks I was moved on, sadly, we will have to see if what we did together took hold.

Update: Sept 2016 – I learnt that unfortunately, much of what we did reverted back, which is quite a sickening thought and I feel really sad for the guys.

update : Nov 2016 –  After a couple of months working the old way again the team and manager have decided that there was a better way to do things and a new coach is starting soon to work with them. I’ve spoken to him and we are very aligned on what to do, so here’s hoping it all goes well