So we were doing great, everyone was happy and we were delivering on time on budget and on scope. Except it wasn’t exactly how things really looked like.
First two projects were late. Not much but still. It was expected since these were our first estimates in the team and at that time we decided not to do anything about that yet. Slips were reasonably small, which was a good sign when we talk about our developers’ estimation skills. Nothing to be worried about.
Another issue however appeared to be a real pain in the ass. One of applications got stuck somewhere in the middle of first iteration of tests. It looked like there was always something more important to do. Everyone was doing high-priority things and the application wasn’t touched even with a stick. There was no mechanism which would add an incentive to finish things and not leave even less-important tasks for later.
We also had a problem with our Product Owner. The guy was trying to catch many parallel threads and organize team’s work but unfortunately he was pushing in a bit too many new things. At the same time he was losing some of nice ideas on the way. Before some of them could be implemented guy was coming back from another meeting with a client bringing new, better and higher-priority tasks and the old ones were fading into oblivion. For those of you who can’t wait to ask who this crappy Product Owner was the answer is: yes, it was me.
A general conclusion was we need some more organization not at project level but at team level. Something which would help us finishing things and limit chaos generated by rapidly changing business environment. Specific of our team was we were doing a number of very small projects simultaneously so coordinating these projects was crucial to avoid falling into chaos.
We were about to do first process improvements…
Read the whole story.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
7 comments… add one
My Question(s):
What has Kanban provided that you think XP, Crystal or any other approach would not have OR would have? I'm not 100% sold Kanban is a fully thought out PM/SDLC approach.
Meade,
I don't know Crystal so I can't say. XP IS NOT a project management methodology. XP tells a lot about software development but almost nothing about project management. Scrum does. However I rejected Scrum for being too strict for our situation.
We are too small and know each other too well to set up specific practices which enable communication or cooperation. That just happens. If I worked with people I didn't know I would probably choose something more formalized. But in this specific situation all methods I used in the past were too formalized to what I needed (Scrum included).
There's basically one thing which Kanban provides which isn't so easily achievable with other standard methods. It is huge freedom when it comes to set up priorities on "what's next" while forcing you to finish what you have started. To give you more details – we start development of new feature every 3-4 days. This means I can effectively change priorities almost twice a week and it happened so a couple of times I was throwing away virtually everything from todo short list and putting there completely different tasks.
This doesn't happen in other methods I know. Even in Scrum you have at least 2-week frozen in iteration before you can start new features.
Of course you can craft methodology just for you which incorporates this and that's exactly what we have started with. The problem was we weren't forced to finish tasks which we had started.
Having said all of that I don't really care whether Kanban can be considered as a fully though PM methodology (it definitely isn't SDLC approach) as far as it works for me.
And thanks for these questions. A food for thought.
Your comment 'We are too small and know each other too well to set up specific practices which enable communication or cooperation.' – do you think that there is a risk in being to familiar and that the lack of known practices could be an issue when the pressure is turned on and 'stuff' happens? I'm thinking (and seen) where familiarity is good in the good times, but when 'stuff' happens you have no real practice/process to fall back on and help sort things out.
Meade,
First, you can't say we have no real process here. Actually a range of options isn't limited just to named methodologies. We had process even before we have started thinking about Kanban. It was very light-weight too since for this specific team even Scrum is too heavy (this is my personal opinion).
Another thing is what will happen when problems come. We can discuss what typically teams do when problems happen and it's rarely following the process, but this is subject for separate thread. When we talk about my current team I know how we will act when stuff happens. Actually I've seen these people in action when stuff happened. This is one of main reasons why I chose them.
In Scrum you are frozen for sprint length. Despite of that you can always have “abnormal sprint termination”. Or make sprints shorter :) My goal is not to promote scrum here, but add some corrections :)
Simonas,
True, but you tend to have fixed-length iterations since you use the data from them to measure velocity etc.
Of course you can make sprints shorter – 1-day-long or even shorter. The question is whether it is better to make iterations shorter and shorter or to resign from them at all.
I think Kanban teams rarely do have iterations is not without a reason. There are just some kinds of work, maintenance being the most common example, which aren’t easily time-boxed.
That’s the reason why we don’t use Scrum for maintenance or other tasks which cannot be estimated (with few exceptions).
We could discuss about cons and pros of iterations, but I guess, its just the matter of applying right process in time. Currently I find it beneficial for my team as it encourage communication and self improvement (retrospective) and , well other Scrum things :) I guess its all about team maturity. I am looking forward my team tries Kanban for full project.