Don't go chasing waterfalls
I used to really like being a Project Manager, I mean really like it. The order, the structure, the process. I would talk to people about 'how things got done in an organised manner' until their eyes glazed over. You see, I cut my project management teeth with local and central government. Yes! I was an advocate / practitioner of Prince 2 and the waterfall methodology. Now don't get me wrong, I am not saying its not the right approach. Its just not the right approach for me. I thought it was, but then something happened.
I discovered/was introduced to a new way and soon realised that the light at the end of the tunnel was not the headlight of a fast approaching, document heavy, process driven train. There was an alternative. So I mothballed the gant charts and Microsoft Project, archived the 30 page requirements and specification docs and confined the 'sign off by committee' trackers to the basement. I packed my things in a hanky on a stick and went on my merry way.
My leap into the Scrum unknown opened my eyes to a more flexible way of working, but with some limitations. Oh Yes, you still have to do certain manifesto ceremonies. Sprint planning, estimating (be-it story pointing or time-boxing) end of sprint retrospectives, end of sprint demos and daily scrums. All of which are valuable in their own right, but a little overkill, don't you think?
That aside, I still really really liked being a Project Manager. It opened up my creative side, it was not all about spreadsheets, and trackers, highlight reports and phone book sized documents. It was writing and drawing on walls, post it notes and sharpies, collaboration and teamwork, trusting and enabling. I noticed the teams were more open and honest. They worked together to find solutions and listened to their peers. My role changed from telling to coaching, from reporting to showing and from excessive planning, to agreed prioritisation. I was in my element and really really enjoyed my job.
Then I joined Red-Badger Consulting and pretty much everything turned on its head. Firstly I was introduced to Kanban (similar to Scrum, but without doing the sprints). Secondly, there is no right or wrong way and nothing is set in stone. Thirdly, and probably more importantly, I was/am given thinking time, a luxury that us Project Mangers seldom get. I had to un-learn what I had learnt and un-think what I had previously thunk!
I had never used Kanban before, and to be honest was a little worried that I had no experience with this particular methodology. But I needn't have concerned myself. At Red Badger Consulting we are encouraged to think differently, encouraged to do what we think is right, encouraged to continuously improve and generally encouraged.
Kanban is our preferred approach, however, how we tweak and change it is totally the team's shout. Oh yes, its a team thing, a collaboration not a dictatorship, at times even the COO hasn't got all the answers! (although he mostly does, ask his opinion or advice and he will give it, it's your call if you use it)
Here at the badger sett we use a mix of Kanban, common sense and flexibility to enable us to meet client's expectations and deliver in a sensible way. Each team is empowered to make relevant changes to their processes, which makes such obvious, but often overlooked, sense, as each client is different and has specific drivers and goals.
In my team we have made some radical changes, not to be non conformist, just simply because its what works better for us. Flexible, agile, collaborative and forward thinking:
We don't do estimating - we see no value of finger in the air guesstimates - we do the work and collect the metrics. Real data on real events giving real lead times.
We use littles law - what we have to do + what we are already doing / what we ship in a given timeframe (daily in our case) We ask the team to put a date on the card when it leaves the todo column and a date when it is shipped. IN and OUT. This gives us our estimated lead time and highlights tickets that have been in play for excessive amounts of time. We use this data to learn and understand what happened and how to avoid it happening or to ensure it continues happening. We also track blockers and impediments, as this has an impact on our lead times
Now, before you ask, yes I do have a spreadsheet, its a huge one too. (I am, after all a Project Manager) but I don't bore the team with it. I take out what is useful for them, like average WIP, how long it should take to do the todo and overall metrics for the entire backlog and the occasional cumulative flow. I capture data daily, how many tickets are in each line. Todo, W.I.P, Shipped. Now I have estimate lead times, useful for when you want to advise your clients on how long something might take and why,
No more finger in the air guesstimating. Remember, real data, from real events, giving real lead times.
We don't do retrospectives at a set time or set day - we do retrospective when it makes sense to - we did do retro every Tuesday at 16:30, but when that reminder popped up on the screens, it was met with an audible groan from the team. So we ditched it. Now we collect thoughts and topics, when we have three or more, we do retro. The team control the topics, unless there is a crisis, then we focus on that and do a retro around that specific item. We also do it quick sharp and to the point, nobody has a chance to get bored and switch off. But in all honesty, we talk to each other constantly, so we tweak little and often.
We don't do massive planning sessions - we plan retrospectively. When we have enough todo, we focus on that. When the todo starts emptying out, we plan the next things that will be pulled from the backlog. We focus on the job in hand, we don’t waste time planning for something that might not make the cut.
We have continuous, one piece flow. - the team focuses on the the board from todo, discovery, UXD, dev, test and shipped. Nothing goes backwards, we have exit criteria for each swim-line. If a bug is found, the ticket stays where it is and a fix is worked on. Continuous flow, everything moves from left to right, nothing jumps back and nothing falls off the board. Once a ticket passes todo, it is tracked to the end, every time.
We include Bugs and Issues in the flow - it's still work, right? still needs to get done, so why separate it out, why not prioritise it along with the other things to do. Site goes bang, we all jump on it, slight irritating non customer facing issue we could live with, we prioritise it and get on with other things. (unless the client or the team think it should be sorted as soon as) But it's all work, some is big, some small, but work nonetheless.
We include UX and Design in the flow - again, work is work right? we are all the same team, right? why segment it? well we don't. If it has UX or design elements they get done in the flow and we measure the throughput along with everything else.
We pair program - the designers work closely with the developers to do the designs within the app, saving time, effort and iterations. The developers pair with developers, they share knowledge and skills. They collaborate and review, the produce quality assured code with little to no technical debt
We collaborate, communicate, celebrate and encourage, through all stages of the process.
I am fortunate to be involved in some of the most innovative, creative, technical, ground breaking and award winning projects with Red Badger. I love using Kanban. I love being able to work with a team of awesome individuals from different specialist areas. I love the 'lets try it and see' approach. I love the challenge and the change.
Since Joining Red Badger, I really really love being a Project Manager. which proves that working for the right company and the right group of people can have a profound impact on how you feel about your job.
Thanks for reading to the end, I take my hat off to you. If you want to see how we do it here, come and have a chat. We love a cuppa and a biscuit.
visit us at http://red-badger.com/
Cheers
Phil Brooks
