Mission Control

Recent Posts

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?

What it takes be an Ittecan. 3

by Pavel Kartautsau - April 17th, 2010

Some of you might not know, but here at Itteco we do our work applying Project machine principles. In theory, project machine is a certain structure of people, communication methods and collaboration between team members, who are ready to solve project tasks and problems in a stand-alone mode and on their own, without nagging control of the manager.

Project machine is not a methodology, like agile or SCRUM, it doesn’t cover the risk management process, requirements gathering, bug-fixing, analysis, QA, defining complexity or priorities. Project machine is rather an organizational layer on top of any methodology.

Manager has a significantly different role in the project machine approach. He is not a lead developer – he is the person responsible for continuous process flow with no glitches and stops.

Project machine defines and shapes team members, who should possess certain qualities:

self-contained developers, who are apt in flying solo;
talkative and sociable team workers;
result oriented and motivated individuals;
perpetually polishing their skills and learning something new;
possessing the same sharing passion.

Tags: itteco, member, organization, process, qualities, skill, team, work, workflow

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: Agile, risk management, SCRUM

MS: Make it useful 5

by Ivan Paramonau - March 21st, 2010

So we have this blog, Mission Control. But we have no clearly defined mission, I guess. Let’s fix it.

I was recently asked about our Mission Statement, and even though I believe those are useless, it made me start thinking. And I figured I need to pull the series of posts about our mission. Just so to make sure everyone is on the same page. It is the first priority for a manager to make sure that no ambiguities squeezed in. So let’s get started.

Archimedes Lever/Wikipedia

Part 1: Make it useful

I have (successfully) delivered dozens of projects in my career. Actually, it is over 100, perhaps. Thing is, that out of them, I vividly remember about 10. That’s the point. Yep, only 10%.

I do not mean that the projects were not worth remembering, or that we did not do anything cool on it. I trust we did. Of course, technology evolves and these days what we done 8-10 years ago many would find not that cool. But this will always be the case with technologies…

Yes, for the matter of fact, in great deal of these projects I participated in senior roles and did not dive deep into details. But that does not make any difference for the remembering things.

What does matter is the fact, that on all projects that I do remember, I had witnessed the great follow-up on after-launch.

Simply saying, I saw people making use of the software that we developed. Either it was big-ass payment app that processed mlns of dollars, or it was the smaller simulation program that helped with cancer fighting in the UK, or completely tiny mobile app for the advertising game. So, size isn’t relevant. Technology isn’t that relevant (especially that it changes so fast). In all the cases, I knew that what we just did this was important cause it was useful for people.

Again, I am not saying that the rest of the projects that I do not remember that vividly were useless. I believe, most of them were pretty useful. It is just that we as developers did not get to have any feedback after delivery. We aim to change that.

So here comes the first point for the mission statement:

We are here to make useful applications that people will remember.

It’s ok that not all of the products last as long as the Ford Mustang on the picture above. Reality changes and we may not all get lucky to develop such masterpieces. It should be useful for the time being. And of course, we try to develop timeless pieces of software…. But that’s the point of the next post. Stay tuned. And pls, participate in discussion in comments.

How to write good emails 2

by Pavel Kartautsau - February 26th, 2010

I’d like to share with you a good practice about how to write emails and do not spend a lot of time for this task.

The most important is that you need to understand what action you would like to have from the recipient;
Try to summarize all his potential questions and write shortly one paragraph explanation for every potential question;
Extract from every paragraph the principal or main idea and put it as a paragraph title. Try to make you titles attractive to the reader (look at the banners on every news web site. On some of them you really want to click to get the info). People start reading from the titles. According to the titles they can “rank” you message for them (whether it is important and interesting for them);
Put the small picture if it is possible. For some people a small sketch can say more than big sentences (specially if your recipient doesn’t speak good foreign language);
Try to put in the subject the action you would like to have from the reader;
Use simple words

Itteco corporate culture requires:

That every email has to be answered withing 24 hours.
If you can’t resolve the problem written in the email, please something like you are working on that problem now and you’ll try to get the answer tomorrow or next week so that the senders understand that you didn’t ignore him…

Q: What shall you do if you have a lot of email?

A: You need to filter them… What is the criteria?
I always answer to the emails of my manager, email that are addressed directly to me and my team in that order. Only after that the emails where I’m in CC if it is necessary.

Hints:

if you prepare a report, divide it to two parts: summary and details;
if you received an email and you think that the sender is stupid and doesn’t understand you at all, your blood pressure if going up and you want to write everything you think about this man right now, don’t do that! Wait 1 hour, think about practice of how to write emails, and then write it;
if you received an email from your boss where he is pressing you down without any reason (as you think), don’t try to shield you via replying immediately, don’t do that! Wait 1 hour, think about practice of how to write emails, and then write it.

Please also read about how to inspire action with your writing here AIDA: Attention-Interest-Desire-Action

Please comment this post adding your email writing practices.

“Done” = “I am proud of it” 2

by Ivan Paramonau - January 27th, 2010

‘’Done means DONE” is the fundamental assumption of all agile software development methods. Agile does not address the need for re-work or repair orders, assuming it is close to 0.

I believe, Definition of Done (DoD) is one of the greatest challenges for agile teams and one of the most often reasons agile teams fail.

There are multiple checklists available for “Done”, for example here or here. Checklists are great as they formalize the requirements for the coding practices qualities. Yet, it still does not necessarily lead to avoidance of failure.

What we therefore assumed as DoD has been “Done means Shippable”. Well, it does not disambiguate the DoD much. Moreover, in my experience, it does not necessarily lead to the amazing products being developed either.

This said, I would like to change the DoD to “Done means I am Proud of It”.

I believe it would work great for both product owners, scrum masters and team members’ motivation as well as will bring much superior results than quality expectation of “done means shippable”.

We also would need to put a checklist together for coding practices, but it would need to develop this main theme.

What do you think?

Tags: DoD, done

Product Owner has to stay focused and think ahead (confession of failure)

by Ivan Paramonau - January 7th, 2010

Ok, it’s time I put my product owner hat on and confess. Confess in recent failure.

So we have just finished the sprint of our community site project. The scope was to develop the groups functionality and expand it to projects and teams.

The base group functionality should include forums, administration of groups and all the rest standard features. The biggest business value I saw was in the extensions of the base functionality to cover needs of the projects and teams.

Well, I must tell we did not quite thought it through on how we would integrate those extensions with the other project and team functions we already have.

We planned the backlog for the sprint and just jumped into it, leaving some ambiguities to be addressed at the end of the sprint.

The sprint was planned for 3 weeks. It was perfectly executed by the team based on Scrum, with several intermediate demos to me as the product owner. It was all good to the point where the ambiguities popped up. By that time, we already have figured a better approach for the implementation of projects functionality. We realized it is better addressed by other modules of Itteco platform, which is another sub-project of ours.

As the result, we dropped the groups extensions, leaving the base functionality. As the most business value was concentrated in extensions, the business value of the 3 weeks sprint dropped down to zero, even though the functionality is shippable.

Nice, eh? So, here is my take on what would need to be done to mitigate it:

Think ahead. Once you did – think again. The better you define the stories for your sprints, the better the results will be. This is especially true if there several teams working on your product. You have to integrate the effort. Scrum of scrums should help enormously. We have to start doing it.
The higher the uncertainty, the shorter the sprints should be. In our case, we are rolling back to weekly sprints.
As per Scrum, the team has to be left alone once the sprint backlog is defined. If you have high level of uncertainty, it may be wise to abandon Scrum and refuge other agile methods such as lean/XP. This way, the lead time is shorter, which allows for better flexibility.

The main lesson learned: stay focused. The ambiguities squeezed into the sprint as the attention was put on other matters, which happens all the time in startup life.

#leanstartup intro

by Ivan Paramonau - January 7th, 2010

The Lean Startup concept by Eric Ries is taking off and getting some serious traction.

I first stumbled upon it a year ago or so, and found many of the principles very useful for most startups I worked with ever after, including our own.

Here is some great intro into the concept:

2009 11 09 The Lean Startup Oulu Edition

View more presentations from Eric Ries.

More #leanstartup resources are available at the end of this post here. I highly encourage our customers and engineers to dive into it, as the concept relates to both business and technical aspects of being a startup.

Tags: leanstartup

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: lean

Stay Lean 2: minimize waste, shorten lead time

by Ivan Paramonau - December 18th, 2009

A while ago, I put up a praise for staying lean. This week, I stumbled about surprisingly clear guidelines on how to transform to being lean in 12 steps by Stephan Schmidt (Grab the eBook now, it won’t last, I assume).

Among the must-have and priority steps for us, I would take the following:

Increase quality (which for me is an equivalent of re-defining the criteria of what ‘Done’ means)
Stop working in parallel
Continuous deployment
We have worked on “No single point of failure or bottleneck” lately, yet it still needs a bit of effort

Generally, it is all about minimizing the waste to get the shorter lead times. While pure lean management is not perfect for all of the outsourcing projects, the engineering practices is what needs to be inherited.

We will try to achieve the ultimate goal of continuous deployment on Itteco’s in-house projects. It would really be an awesome accomplishment. So, we’ll try, and you may try with us.
Start minimizing the re-work, which still accounts for most of the waste in our projects. Then go into automation of the deployments to staging servers. Itteco’s project repositories are built to enforce the deployment automation from the day one, and you could check with our Ruby/Rails guys how they are doing it. There is also a good deal of deployment related posts at the Rocket Science blog. Once this is done, we’ll work on the unit/integration tests coverage and minimizing the QA cycle.

Continuous deployment, here we go!