Stay in Control

Mastering the art of project management (in 3 “easy” steps)

by Ivan Paramonau - April 21st, 2010

I, for one, truly believe that anyone can be great project managemer. But, as Russian saying has it, – one isn’t born as hero, one becomes a hero. Yes, I mean, it takes a bit of mastering. Well, ok,  it takes _quite_ a bit of mastering. So let me tell you my own path so far.

Step 1: Project management as snow shoveling during the blizzard

I have this odd habit of metaphorizing everything. For extended period of time in my career, I was thinking about managing projects as of snow shoveling during the snow storm:

  • You knew it was to start, but it took you by surprise anyway. And it is fun shoveling the first 10 minutes only.
  • You keep shoveling and shoveling, and it doesn’t seem to end any time soon
  • The worst part is that you can not really see anything around. Not only the snow falling is taking you down, but also – you are always busy, FTW!
  • For just a bit, the snowstorm would stop, and you feel – this is it. But na-a-a-y, it starts all over.

Very depressive stage. You are feeling like you are that hero, which nobody gives kudos to.

State of the mind: why the hell would anyone want to be a project manager!

Step 2: Keep the balls in the air

Juggling many balls aren’t easy. But doable. And definitely much more controllable than shoveling during the snow:

  • You know which ball comes next, and with a little touch you go to the next one
  • You are not that stressed out, and your people are therefore not that stressed out either
  • The little drawback is that you don’t have much time to think ahead and prepare yourself. The attention span is too short, and thus you are risking of loosing one of the balls, which will cascade to overall collapse of the system

State of the mind: look what I can do

Step 3: Pushing a swing

This is my current stage, and thus the latest so far.

I think of management as of pushing a swing:

  • You know when to push. If it is too early, too late or too often, you are wasting your energy at the very least. You screw it all up if you get that much lucky.
  • Provided a spare time, you may start thinking strategically, rather then controlling every tiny bit. You are no star and no control freak – just a natural team member, just as you are supposed to be
  • As project manager, your main task is to facilitate the process. To set up framework and atmosphere, where all team members are as productive as they can be. Which often time means they are in a pleasant settings with not that many distractions.
  • The best achievement of the project manager is a project, where team members & customers come to him first, should they discover any impediments. With snow shoveling you are doing hell lot by yourself and others just don’t have enough overview to notice any vulnerabilities. With balls juggling, all you do is resolving the issues. Which means you don’t do anything to prevent then.

What stage are you in? What’s gonna be next one?

Why we all suck at estimates

by Ivan Paramonau - March 26th, 2010

All right, let’s face it – we all suck at estimates.

It is human nature to be overly optimistic. Like the last time I thought it would only take me couple hours to do taxes, or all the times I get to drop my kid off to the day care and am constantly being 10 mins late (why do I even keep believing I can feed him a breakfast in under 15 mins?!!). Well, we’ve all been there – one time you are late 15 mins to the meeting, next time you make corrections for traffic on your way – and arrive 15 mins earlier?

When it comes to software engineering, the things become even worse. Not only do we deal with natural optimism, but we work with much more unpredictable substance than just a traffic.

However, let’s stop writing everything off on our optimism. This is something we have all accepted and moved on. Let’s see what is next.

There are some well-known productivity issues to be addressed:

  • Minimize waste
  • Stay focused

Nothing new here. So, let me throw another one:

Know where you stand

Seriously, risk management was never cancelled. Yes, we do it Scrum way, where they are called impediments. But we never said we don’t do it at all. I sense that the 3rd question got omitted from our daily scrums, namely “what is holding up?” part. The impediments discovered needs to be carefully tracked. I am not opening up a discussion on risk mitigation strategies quite yet. Let us first start tracking risks and knowing where we stand first.

Let me share a secret with you: there is a special ticket type in your project’s repo for tracking risks. Well, it is called “risk”. And its purpose is (surprise-surprise) to aggregate risks. The risks are included into burndown charts, you can write the time off on risks, etc. etc. So again, just let’s keep record of all risks discovered during planning and daily scrums.

Not having this info does not allow for any analysis, which in itself is even worse than just sucking at estimating. Let’s change it, shall we?

Tags: , ,

Lean Software Development 4

by Pavel Kartautsau - December 20th, 2009

Scrum is fast and controllable, but sometimes such a speed is not enough…

As you know, until the software or set of requirements has been deployed to the production environment it passes several stages:
1. Analysis
2. Development
3. Testing, bug-fixing and integration
4. Deployment to production

It could take some time to analyze set of requirements, develop, test and deploy them to production. After that the product owner
can’t really be sure that the feature gives the same business value as it was originally planned.

Even in scrum with the very short sprints, like 1 week it still gives the concerns about the benefits…

Although, scrum is focused on delivering the highest priority business value as defined by the product owner, sometimes the
deliveries every sprint time is not enough. The world is changing very fast, so you need go live with your ideas as fast as possible.

What if (Let’s put several assumptions to your application)

1. Your system is already running on production.
2. You prefer to see feature by feature on production rather than having a weekly demo with all the features planned to be developed in the sprint. Generally, as soon as the feature is ready, you would like to see it on production.
May be after you see the feature on production you’ll come up with some more ideas that have much more business value than the user stories in your current sprint backlog.
3. Your developers are very talented and professional. You are sure that they will deliver at least 80% of your story. The last 20% – bugs and misunderstandings.
4. The business value of those 20% is 1-3% of the whole user story.
5. The value of the bug or mistake that your team can do is insignificant. If your team has deployed something to production that works only for 80% – that is fine for you.
6. You are sure that deploying new feature will not break down your system. The most terrible – it can lead you to some usability issues on your back-end which can be easily fixed withing one day.
7. Even if the feature has been deployed with several bugs, the business value it brings to your system is more than the price of the bug.
8. So, you are not afraid of deploying your functionality to production.
9. You care more about the delivery than about the complexity. You are sure that your team will always do their best to deliver your user story as fast as possible with the maximum possible quality. So you don’t care how precise did the team put the complexity. Anyway the story has been delivered as fast as possible (You will need the complexity only for making measures, to make your process even faster).

Than you probably can get more benefits from the approach called lean software development.

Examples of the systems which can be under those assumptions:
1. Web site with a backed, 3-5 workers working with the backed
2. eCommerce systems with not more than 50 requests/operator.
etc.

How to accomplish that? You can start from the most important things:

1. Stop working in parallel. If you have several features to be developed, let your developers on all the features together.
If your developers are good enough, than the development of the 3 features (even if is very small, like 5-6 man-hours) with 3 people when they work altogether on feature 1,2,3 sequentially, should be almost the same as if every developer will work on his own task.
But the benefit of seeing the feature live as soon as it ready is enormous, instead of seeing 3 feature together in some weeks. As soon as the feature is on production it starts to help you in earning money, which you can you for developing new feature. So you don’t need to have a big budget for your project.
2. Make your user stories as short as possible – (try to make them not more that 16 man-hours).
3. Install the continuous deployment process

You can get a very interesting explanation here: Reduce lead time

Tags:

Be prepared. Think ahead.

by Ivan Paramonau - December 11th, 2009

46259350_6c1bfce60c_m

This is the attempt to define the difference between ‘What to do’ and ‘How to do’. I am putting my Product Owner’s hat to try to tackle it and step back from the implementation issues.

Be prepared

The lessons I keep learning from almost every project is ‘Be prepared’. It means that, in most cases, the velocity of a development team is the function of the level of ambiguity they are dealing with. The more vague requirements and directions you give, the less time is spent effectively on getting things done.

This is the sort of a contradiction with ideal Scrum process and the reality. Agile approaches assume teams be cross-functional, empowered to make a decision. While this is great in theory and is absolutely necessary in for better teamwork, it does have it complications in the real-life. Especially when it comes to the ‘real-life’ of startups and outsourcing in general.

The main complication is the availability of resources. The limited amount of financial resources results in only limited availability of human resources. And here we go, – the teams are not that cross-functional any longer.

So, be prepared: teams cannot make all of the decisions, regardless of the level of detail. You need to stay behind the wheel to be prepared to give the directions, eliminate ambiguities and drive ‘how to implement’ discussion.

Think ahead

Not to slow down the velocity you need to think ahead. You can only do it when you stay informed on what’s going on the project. Get to know the team members better, analyze how they are making (and avoid making) the decisions, see what’s in the backlog so you would be able to steer before you hit the sandbank.

If your team is missing usability expert – be the one. If team does not have aesthetics guy, make your own vision clear in details. By thinking ahead of what issues may arise, you eliminate the need to mitigate the impact of the risks down the road.

This said: think ahead and be quick in crossing the bridge between ‘what to do’ and ‘how to do’. You are the key team member. Make yourself available to close the gaps and make the team truly cross-functional.

Stay calm

Staying calm does not relate to the topic of this post, but I could not resist to put it here. It gives the ‘captain’ metaphor a bit of completeness.

So, stay calm. There is nothing worse than erratic captain. Remember: you are always the last who gets to leave the ship :)

Pig & Chicken: “How to contribute without being over committed?” OR “Oh, poor middleman!”

by Ivan Paramonau - November 10th, 2009

The well-known The Chicken and The Pig story is used with reference to Scrum more often than with reference of anything else, I believe. Despite its wide perception of just being a silly story, the metaphor makes lots of sense in various aspects of software development. As Michael Vizdos mentioned, you can’t be Pig & Chicken by the same time.

The problem is even more vivid in outsourcing. As a middleman, you are committed before your clients; yet you certainly do not want to become the control freak. But how do you keep all the balls in the air? Juggling team motivation, statuses, priorities, risks, technical choices, client’s expectations etc. etc. isn’t piece of cake. Drop one of the balls – and you are likely to witness the domino effect on the others.

Your commitments before clients make your self-determination easy: you likely cannot afford to be just a contributor on the project.

My (gained through multiple failures) approach – don’t let others be _just_ contributing. Let people juggle with you. Let them see all of the balls in the air. Let them commit – this is what any one of us needs to be happy about his job anyway. In other words, make sure you don’t have Chickens in your core team (remember – you can’t be both: you are either totally involved as Pig or _just_ watching as Chicken).

In most cases, you would achieve this by losing some of the control over project. In this case you risk becoming contributor yourself. It’s a double-edged sword (but I guess you’ve understood the complexity by now).

There is no silver bullet on how to stay in control without being a control freak. If it was a rule of thumb to segregate “What to do” and “How to do” questions, it would have been much easier: you just focus on what to do and have others commit by allowing them to making decisions on how to do it.

clock-gears

However, there is one thing that would help you out. This thing is to remember the platitude fact that “all people are different”. We all come from a different background and with a varying comfort level for the commitment. Your goal as the Scrum master would be to make the overall commitment level grow, by growing the commitment of each individual. As the commitment grows – you just share some of your balls in the air with others. You iterate as long as it is needed to get the following picture in the project team:

Hey, if you see me being control freak at times – pls, pock me into the case and we will discuss. I probably have my reasons (such as, say, considering you under-committed) – but worth a discussion anyway. Thanks!

Tags:

© 2008-2010 Itteco Software Corp. All rights reserved.