It has been over a month since the last time, but last weekend we got back together with our class to learn and discuss about project management. On Saturday we checked out each other's Master's Thesis presentations, but in this blog post I'm going to focus on Friday when we were privileged to be lectured by Wolfgang Steffens, a lean and agile coach working currently at
Nokia Siemens Networks.
We were told beforehand that Wolfgang has a provocative way of giving speeches and he said it also himself that some of the things might not be as black and white as he says, but he wanted to shake us up a little bit, take us away from the routines we are used to and give us some food for thought.
Well, Wolfgang's approach to agile methods was very direct :) Solid opinions like "in Scrum there are no project managers", "middle management is not needed" and "never do multitasking" are few examples that I was rolling around in my head during and after the lecture. Mission accomplished! Though I don't completely agree about everything he said, it lead me to do a lot of thinking afterwards.
I'm not even going to try to summarize everything we went through, but I'll write about the things that I felt had the most impact on me. First topic is about estimates and how I totally agree with Wolfgang on this one.
By definition estimates are wrong
This is something I learned the hard way in our own product development. When I started at Humap almost six years ago, agile was making its way into our product development. Back then I considered estimations being one of the hardest things. Initially we tried out two week sprints and for each sprint we (our development team) planned quite much all Monday. Out of 10 working days we were using 1 day, 10% of our working time, just to plan our sprint. Though sometimes planning didn't take all day, try sitting in a meeting for 4-6 hours planning complex schemes and then try to concentrate on a demanding programming or architectural design issue, it just doesn't work very well. Later on we tried solving our issues with wrong medication and we moved to 4 week sprints, then planning really took the whole day.
So what made our planning so slow? The fact that we tried to achieve something impossible, we tried to split our sprint into fine grained hour level tasks. What makes it even harder is that our work at Humap is very innovative and somewhat unstable in a positive way. We are flexible and one of our strengths is that we can adapt to changes very quickly. That system we were using back then was not supporting this flexibility very well. We realized quite quickly that estimates didn't correlate very well with reality, that's why they are called estimates. We started letting go of precise hour based estimations and started first using granularity of days, then the modified Fibonacci sequence of days (the series was something like 0, 1, 2, 3, 5, 8, 13, 20, 30, 50 or 100 days). This was already good, but little did we know how much there still was to improve.
After estimating days we moved to story points, but we colored our units a bit. I can't remember the exact units we had, but they were something like mouse, rabbit, horse, whale and planet. At this point we had come a long way from those wearing all day long meetings where we tried to foresee how many hours a single task would take though we were talking about such details of certain projects that we hadn't even properly started planning. Nobody really knew whether it takes 2 or 4 hours to modify commenting AJAX based show/hide functionality, but we knew that it was a rabbit compared to a planet size feature of creating a complete layout editor for our system. After few sprints we started seeing some patterns how many mouses, rabbits or whales we can nail in a single sprint.
Things started to roll quite well, but the variety in our burn down success got us thinking what is still going wrong in our processes. This leads to the second point in the lecture that I want to highlight as a title.
Stop doing iterations
We noticed that during two weeks, our sprint plans might change from top to bottom. Someone nails a sweet deal and its priority jumps to the top, we notice a nasty bug that takes quite a bit of time to fix, customer support tends to consume us in spikes or we just come up with such a great idea that we want to do some prototyping as soon as possible even if it would mean leaving some earlier planned tasks out of the sprint. Don't get me wrong, changes were almost always good, but our system just wasn't supporting that very well. Looking at an unfinished burn down chart at the end of the sprint and figuring out "what went wrong" didn't feel very motivating, but we just didn't realize that we were almost always doing the right things that supported our business strategies.
I can't remember the exact day when we decided to stop using Scrum and therefore stopped using iterations, but it sure has been working for us ever since. By that time we had never heard of
Kanban, actually I heard it for the first time just a couple months ago. Nevertheless, our current system is much closer to Kanban than it is to Scrum, but I want to be careful when using those names as we are not using any particular method in our procedures.
GTD has certainly affected our ways of working, but I haven't read the book so my knowledge relies on the discussions I've had with my colleagues. Some might consider this as
Scrumbut, a term that also popped up during the lecture, but nevertheless we have a system that is working quite well for us. I wrote about our project management in
my earlier post so I'm not going to repeat myself here, instead I'm moving on to the second last point I want to highlight from the lecture.
Traditional project management triangle is insufficient
Traditional project management triangle consist of time, scope and budget. In this traditional graph, one side of the triangle cannot change without affecting the others. If your budget cannot change but you need to get the job done faster, you need to take something away from the scope of the project, if you don't cut the scope then time cannot change and so on.
But then we encounter real world. Customer cannot put more money to the project, all the features in the scope of the project are vital and deadline cannot slide because the customer needs results by the time they are having some important organizational meeting, development days etc. On top of all this we know that this project is important to our business and would work as a good reference in our marketing so we cannot just say no to the project. Having more resources is also a no can do, because we are dealing with such complex core level development issues that it would take months to lead a new developer into being able to work with this project.
This has lead into
refined version of the triangle and quality/performance has been added as a constraint. This allows some "magic" to be done and make the impossible happen. We take shortcuts, quickly copy-paste code from one place to another without designing proper architecture, write code that is hard to test, leave out unit tests completely and do not think of all the consequences of our actions. Now this is not completely unacceptable, we just need to be aware that this leads into
design debt that needs to be paid later on. If you just go on and on taking more and more design debt, it eventually leads into completely messed up source code that is impossible to maintain or modify.
We face these situations in Humap too, but we try to take as little shortcuts as possible and replace them with innovations. In the triangle it means not to cut from quality, but increase performance. Increasing performance doesn't mean typing your source code twice as fast ending up with sore fingers and brain totaled from trying to think triple fast "because we are in such a rush". No, trying to hurry up usually leads to making mistakes and slowing up the process even more. Sometimes that little extra pressure might just lead into inventing some brilliant ideas how to solve issues by intelligently utilizing something existing, new ways of working, new technologies and some innovations in such way to the goal can be reached faster without quality loss or sometimes even with better quality than what was originally planned. Nobody's perfect, you can't always come up with pearls that solve all your problems, but it sure feels good when you get it right :)
This post is getting long enough already so it's time to check out the last one.
Never do multitasking
There was a very good example about multitasking from project management point of view. Imagine you have one week sprints and you need to complete four tasks, each estimated to take one week. In the beginning of first sprint you start to work on all those tasks and they all are progressing steadily at same pace. After three weeks, you have completed 75% of all four tasks, but what have you actually finished? Nothing.
What if you had started doing just one task and move on to doing next task once the on going task is finished? You would have finished three of the four tasks. Consider this from risk management point of view. It's not that hard to see that doing one thing at the time is the way to go.
Another, more technical example. When I first heard of
Serial ATA, I though that how could it be faster than Paraller ATA? Same ideology applies. While PATA can move multiple bits side by side, bits arrive to the other end of the cable in bit different times so they have to be synchronized with separate logic. Sending data in serial reduces overhead and data transfer rate can be much higher so it becomes faster than "multitasking".
As said, this was not all we went through during the lecture and Wolfgang had good examples about Lean methods. But now it's time to close this one up and leave some space for future blogging too ;)
