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 ;)
Project Management Studies 14th and 15th of October
on Sunday, October 16, 2011
Last Friday two lecturers, Mark Halmagiu and Heikki-Pekka Noronen, talked to us about distributed software development and team management and evolution.
Mark used MeeGo development as an example how things can go wrong in distributed software development. MeeGo was an excellent example as development teams are span all over the world in Finland, France, UK, Eastern Europe, Far East and USA. Mark said that they had only little or no overlap at all in working hours between some teams across the world. This creates a real challenge in planning work distribution. If workload is poorly split between teams who are working in completely different timezones, the other team might have to wait a complete day before receiving any information from the other team. These kind of dependencies can really stall development. Therefore it's important to split work into such packages which development is not (at least not much) bind to each other.
Another challenge was cultural differences. Cultural differences might sound obvious, but the Mark's examples were eye opening. For example, in China people didn't listen to you if you didn't have a fancy title. It seemed like they were listening, but afterwards people asked for confirmation from someone else who had more impressive title. There were also major differences in self-initiativeness between different cultures. Mark said that sometimes it required really specific instructions to get a team in Eastern Europe to start doing some tests, but once they got started, they produced results like clockwork. So even if it's clear that teams around the world have cultural differences, these examples reminded me that the problems that may arise can be quite surprising.
In Mark's presentation there were also good examples that should be considered in all projects, not just in distributed software projects. Good goals are essential to any project. They should be clearly described, achievable with reasonable time frame, lead the project to right direction, not change too often and goals should never conflict with each other. It's easy to see how project can go wrong if one or more of these goal principles fail.
Good communication is essential in order to project to be able to succeed. In the presentation, Mark told us about good examples how not to handle communication. The development teams were communicating quite well with each other, but there was some political interference in development. Far too often messages came somewhere higher from the hierarchy and teams had to change their priorities and start doing something else without any reasonable explanation why priorities changed. This effectively removes the feel of control and ownership from developers. Even in such cases where all the information cannot be told, instead of silence it would be better to deliver a message like "we are changing things for such reasons we cannot tell you, but we assure you this is important".
I think good communication is the key to success in many other areas too, not just in project management. How and what information we exchange (or decide not to exchange) with each other is extremely important for shared knowledge and understanding. Not exchanging information can also be important. Generating information waste can be so overwhelming that all working hours are used to read emails that have no real meaning for you.
I once saw a good graph describing the most usual problem in software development communication. Generally sales people are skilled communicators in customer's language whereas developers are experts in tech talk, but both parties tend to face issues when communicating in the opposite end of the graph. There's probably no need for sales to speak fluent tech and developers don't probably have to be as fluent customer communicators as sales people. The crucial point in this graph is the gap between customer and tech talk. A good software project needs someone being able to communicate fluently in this gap. Exchanging information between developers and sales people in such way that both parties get shared understanding is essential for the outcome of the project.
Heikki-Pekka's presentation was about team management and evolution. We discussed about self organizing teams, high performance teams, building and evolution of teams and how to manage different kinds of teams.
Later on after the presentation I realized how good situation we have at Humap. Our development team members have not changed in couple years, we all know each other well and each of us has shared understanding of each developers skills. This way we have been able to constantly polish our cooperation and at the moment our team works at extremely good performance. It was very good to hear about different kinds of problems in team building, evolution and management. It made me appreciate my current situation at Humap even more than I already did.
Mark used MeeGo development as an example how things can go wrong in distributed software development. MeeGo was an excellent example as development teams are span all over the world in Finland, France, UK, Eastern Europe, Far East and USA. Mark said that they had only little or no overlap at all in working hours between some teams across the world. This creates a real challenge in planning work distribution. If workload is poorly split between teams who are working in completely different timezones, the other team might have to wait a complete day before receiving any information from the other team. These kind of dependencies can really stall development. Therefore it's important to split work into such packages which development is not (at least not much) bind to each other.
Another challenge was cultural differences. Cultural differences might sound obvious, but the Mark's examples were eye opening. For example, in China people didn't listen to you if you didn't have a fancy title. It seemed like they were listening, but afterwards people asked for confirmation from someone else who had more impressive title. There were also major differences in self-initiativeness between different cultures. Mark said that sometimes it required really specific instructions to get a team in Eastern Europe to start doing some tests, but once they got started, they produced results like clockwork. So even if it's clear that teams around the world have cultural differences, these examples reminded me that the problems that may arise can be quite surprising.
In Mark's presentation there were also good examples that should be considered in all projects, not just in distributed software projects. Good goals are essential to any project. They should be clearly described, achievable with reasonable time frame, lead the project to right direction, not change too often and goals should never conflict with each other. It's easy to see how project can go wrong if one or more of these goal principles fail.
Good communication is essential in order to project to be able to succeed. In the presentation, Mark told us about good examples how not to handle communication. The development teams were communicating quite well with each other, but there was some political interference in development. Far too often messages came somewhere higher from the hierarchy and teams had to change their priorities and start doing something else without any reasonable explanation why priorities changed. This effectively removes the feel of control and ownership from developers. Even in such cases where all the information cannot be told, instead of silence it would be better to deliver a message like "we are changing things for such reasons we cannot tell you, but we assure you this is important".
I think good communication is the key to success in many other areas too, not just in project management. How and what information we exchange (or decide not to exchange) with each other is extremely important for shared knowledge and understanding. Not exchanging information can also be important. Generating information waste can be so overwhelming that all working hours are used to read emails that have no real meaning for you.
I once saw a good graph describing the most usual problem in software development communication. Generally sales people are skilled communicators in customer's language whereas developers are experts in tech talk, but both parties tend to face issues when communicating in the opposite end of the graph. There's probably no need for sales to speak fluent tech and developers don't probably have to be as fluent customer communicators as sales people. The crucial point in this graph is the gap between customer and tech talk. A good software project needs someone being able to communicate fluently in this gap. Exchanging information between developers and sales people in such way that both parties get shared understanding is essential for the outcome of the project.
Heikki-Pekka's presentation was about team management and evolution. We discussed about self organizing teams, high performance teams, building and evolution of teams and how to manage different kinds of teams.
Later on after the presentation I realized how good situation we have at Humap. Our development team members have not changed in couple years, we all know each other well and each of us has shared understanding of each developers skills. This way we have been able to constantly polish our cooperation and at the moment our team works at extremely good performance. It was very good to hear about different kinds of problems in team building, evolution and management. It made me appreciate my current situation at Humap even more than I already did.
Project Management Studies 23th and 24th of September
on Sunday, September 25, 2011
First two contact study days of Project Management course were interesting. Even though I have been involved in project management through my work at Humap and I have been studying it before, I learned how little I actually know about the subject in detail. First I want to share little bit how we are managing our software projects at Humap.
In Humap I have participated in managing projects among with other software developers and sales team members for roughly five years now. Our approach to project management is a result of lots of practical discussions and we have tried to remove all unnecessary parts from our project plans. We have had all kinds of iterations of our project management tool, but the current version in our intra is quite lightweight and has only few inputs.
Usually when we create a new project, we input only priority, roles (responsible, lead and project members) and start writing specifications for the project. If we know strict deadlines, then we also input end date and possibly start date too, but this is optional step. If there are no deadlines, we just do projects in prioritized order. Quite often we don't input explicit information about the project size, but usually we do input rought budget estimation to give us some picture whether we are talking about "rabbit" or "planet" size project. Because of the small size of people involved this has been working surprisingly well for us and us programmers have been able to do less worktime estimations and concentrate our focus more to implemention.
If needed, the project can be split into subprojects and for each subproject we input even less information. For subprojects we define a person who is responsible and write down some specifications for the subproject. In both project and potential subprojects we can have discussions via comments about who does what when, are there any issues to be solved or is there anything else we need to discuss about the project or subproject. Actually our subprojects contain such minimum amount of information that they could be seen more as tasks rather than subprojects.
Usually worktime is tracked only if the project isn't fixed price and in some rare occations when we want to know how profitable a project really was. Quite often in fixed budget projects we can skip this step too as we usually know quite accurately what needs to be done and how much time it's going to take. This way we are again able maximize our time used in implemention.
This model has been going back and forth between current light version and micro managing projects and tasks and using a lot of time to specifications, planning and reporting. I've learned along the way that project management can very well be adjusted according to such variables as project size, schedule and budget, amount of people working with the project, their background and expertise in required technologies.
What I realized during the first two days of Project Management course studies was that in Humap we have been privileged to work in such environment that enables us to skip parts that are commonly part of PMP. This is probably why so many terms and concepts, such as WBS, scope, change and communications management were completely new to me.
Learning about project management in detail has naturally been possible earlier too, but I didn't know what I don't know so I didn't have any need to learn more. What we are doing in Humap works for us. But now knowing how much there is to learn about project management and understanding that in bigger projects and in bigger organizations our PM model in Humap would probably not work very well, makes me want to learn more. Luckily now via this course we have a good list of resources where to start looking so it's easy to get started. In addition, through the oncoming lectures and dialogue with fellow students I'm sure I'll get quite quickly deeper into the theories and best practises in project management.
I'm really looking forward for the next contact studies in Project Management course. Until then I'll dig into the given resources and get into IPMA self assesment and planning my studies with MS Project. This is fun step too as I haven't used MS Project in many years and back then I used it only for couple of days for testing purposes. During Saturday's studies we already got into testing MS Project a bit. The first impression was bit chaotic and I felt bit lost, but once we got into few main features and basic usage, MS Project started feeling more and more natural. Once getting into few tricks such as defining dependencies using syntax like 4SS+3d (task starts three days after task 4) or defining work via 4eh (elapsed hours) the power of MS Project started to unveil. The amount of features does make MS Project bit heavy though, but I guess for defining comprehensive and detailed PM plans many of those features are really needed.
In Humap I have participated in managing projects among with other software developers and sales team members for roughly five years now. Our approach to project management is a result of lots of practical discussions and we have tried to remove all unnecessary parts from our project plans. We have had all kinds of iterations of our project management tool, but the current version in our intra is quite lightweight and has only few inputs.
Usually when we create a new project, we input only priority, roles (responsible, lead and project members) and start writing specifications for the project. If we know strict deadlines, then we also input end date and possibly start date too, but this is optional step. If there are no deadlines, we just do projects in prioritized order. Quite often we don't input explicit information about the project size, but usually we do input rought budget estimation to give us some picture whether we are talking about "rabbit" or "planet" size project. Because of the small size of people involved this has been working surprisingly well for us and us programmers have been able to do less worktime estimations and concentrate our focus more to implemention.
If needed, the project can be split into subprojects and for each subproject we input even less information. For subprojects we define a person who is responsible and write down some specifications for the subproject. In both project and potential subprojects we can have discussions via comments about who does what when, are there any issues to be solved or is there anything else we need to discuss about the project or subproject. Actually our subprojects contain such minimum amount of information that they could be seen more as tasks rather than subprojects.
Usually worktime is tracked only if the project isn't fixed price and in some rare occations when we want to know how profitable a project really was. Quite often in fixed budget projects we can skip this step too as we usually know quite accurately what needs to be done and how much time it's going to take. This way we are again able maximize our time used in implemention.
This model has been going back and forth between current light version and micro managing projects and tasks and using a lot of time to specifications, planning and reporting. I've learned along the way that project management can very well be adjusted according to such variables as project size, schedule and budget, amount of people working with the project, their background and expertise in required technologies.
What I realized during the first two days of Project Management course studies was that in Humap we have been privileged to work in such environment that enables us to skip parts that are commonly part of PMP. This is probably why so many terms and concepts, such as WBS, scope, change and communications management were completely new to me.
Learning about project management in detail has naturally been possible earlier too, but I didn't know what I don't know so I didn't have any need to learn more. What we are doing in Humap works for us. But now knowing how much there is to learn about project management and understanding that in bigger projects and in bigger organizations our PM model in Humap would probably not work very well, makes me want to learn more. Luckily now via this course we have a good list of resources where to start looking so it's easy to get started. In addition, through the oncoming lectures and dialogue with fellow students I'm sure I'll get quite quickly deeper into the theories and best practises in project management.
I'm really looking forward for the next contact studies in Project Management course. Until then I'll dig into the given resources and get into IPMA self assesment and planning my studies with MS Project. This is fun step too as I haven't used MS Project in many years and back then I used it only for couple of days for testing purposes. During Saturday's studies we already got into testing MS Project a bit. The first impression was bit chaotic and I felt bit lost, but once we got into few main features and basic usage, MS Project started feeling more and more natural. Once getting into few tricks such as defining dependencies using syntax like 4SS+3d (task starts three days after task 4) or defining work via 4eh (elapsed hours) the power of MS Project started to unveil. The amount of features does make MS Project bit heavy though, but I guess for defining comprehensive and detailed PM plans many of those features are really needed.
Back to school
Autumn is here and for me it means that my studies at JAMK University of Applied Sciences continue. I graduated as Bachelor from Degree Programme in Media Engineering by the end of 2006. Now I started studies in Degree Programme in Information Technology and my goal is to graduate as Master of Engineering in 2013.
I will write my Project Management course learning diaries here in this blog. You can follow them via tag project-management.
I will write my Project Management course learning diaries here in this blog. You can follow them via tag project-management.
Subscribe to:
Posts (Atom)
I'm a software designer and developer currently working at Humap Software. In this blog I'll write randomly about software development and phenomenons related around the subject.
