How to master maintenance – part 2

Disclaimer first: this post is not that relevant for companies that host their services in the cloud. If that is your case, you may as well skip this one and stay at the first post on this subject.

At very beginning of the product, PO must decide how often application should be  released on a yearly basis. This answer primarily depends on the market and business cycles which we want to address. Although release cycles don’t need to be exact, it is important to have good idea about their frequencies, since only based on this answer you can prepare good SLA, maintenance and development strategies. For everyone in the software business, two phases of product lifecycle are recognizable: push effect, the one in which we aggressively bring a new product on the market, and the second phase – pull effect, when customers start using our product followed by requests for improvements and bug fixes.

What I have often observed is that in the first phase, PO can be very aggressive towards R&D community, trying very hard to convince folks that quick and dirty solutions are needed to address a window of opportunity. This may as well be true, and rather than trying to get too smart in this post about it, I will just say, be careful, since there is never a time to come back and clean all the shit. If you cut the corners, note them down, and get prepared before next release comes out, otherwise price can be too high. If you mess too much in this phase, your second phase can be very short and stressful, and before you know it, you can as well close the shop. Therefore, it is important that you ask your PO to read this blog too, and unless she doesn’t have another job in the pocket – she should be on your side and stop asking crazy stuff every day.

Interestingly, pull phase is amplification of the first one, when it comes to pressure to R&D folks to do things, well, quick and dirty. Existing customers will start asking for improvements to PO, bugs will require fixing (according to SLA’s) while  competitors will bring new products that will require response from your side.

But there is at least one thing you should not wait at the beginning of the project. First requirement for every product must be capability to build and deploy your application without any human intervention. I know that it might sound silly, and I will come back to it in another post, but for the moment, please never ever forget this.

Once you know the release cycle, you need upfront to agree with sales and business people how many past releases you are going to support at any moment in time. Everything more than 4-5 is according to me – suicidal. If release cycles are very short, let’s say 3 months, I would expect that the end customer also wants new upgrades every year. If release cycle is 8-10 months, it is correct to assume that the warranty asked by the customer would be about 2 to 3 years. So, my rule of thumb is the following:  stay at 4-5 releases at any time, and once you agree on span of one release cycle, prepare SLA’s accordingly.
Once that is agreed, try to plan your maintenance activity upfront. It is very logical to assume that the latest release which is out is the most “problematic”. If nothing else, others are already longer in the field and already fixed couple of times. Longer in the field, less you need to be busy with them, and less severe issues you can expect over time. More over, you can easier follow SLA’s, since older releases will require less frequent correction time.

Finally, let me summarize the last two posts in:

Maintenance tips

  • Schedule maintenance loads upfront and communicate them to the rest of the organization and customer. It is important to inform customers as well, since this is going to relax them a little bit, telling them that there is a train that will come, if needed, to address their issues. That might as well fix next big problem:
  • Avoid making patches or “hot fixes”. Difference between maintenance loads and patches is that patch is not cumulative set of fixes. You have to have good automation and reputation in place to convince customers not to ask for patches. If that is unavoidable, correct warranty contract needs to be in place, since this is extremely costly thing to do.
  • You must have good automation in place and good set of regression tests. You must not only validate fixes for every maintenance load, you need to care about the rest of the product too, reputation is everything!
  • Depending on the release cycle, plan maintenance loads on a fix basis, for instance, if your release cycle is 8 months, plan one maintenance load every 30 to 45 days.
  • Heartbeat of the maintenance loads is different for different releases – it is gradually slowing for older releases. For instance, if the current release is maintained once a month, N-1 release should be maintained every two, and N-3 every three or four months.
  • Try not to overlap maintenance loads from different releases, so that the test team tests only one maintenance load at the time. This can become very important if you have scarce HW resources. This is what I call traffic shaping bug fixing and testing. Fix every day, test every day, one thing at the time.
  • For every issue that comes from the field, decide according to the SLA, where to fix it and let the same person fix the issue in all loads, including the current one that is still not out.
  • Issues are fixed by the same group that implement new features for the current release. Everyone gets few bugs to fix per week. If people start complaining that there is too much of that, you have another problem to solve first!! Remember quick and dirty story?
  • Create tests that verify all fixes, they must be part of the next test suite, and always ask yourself (and your test manager) why the issue was not found during development.
  • Always monitor total amount of time spend on this activity. Is should stay constant over time. If you succeed in that, you can have better planning in the future, and more importantly, you can add enough features in every release. Even better, no crazy escalation, crazy hours and freaky people around you (well, almost)

Posted in project management | Tagged , | Leave a comment

Maintenance revisited – part 1

Maintenance is a tricky subject, and before I continue, I would like to distinguish between applications that are truly in maintenance mode and the ones on which there is still ongoing development. Obviously, if the application is not “moving” any more, the best you can do is to outsource complete thing and let other guys being busy – providing you have automation tests in place, trained people and good maintenance contract.
Bigger dilemma comes when application gets first time deployed in the field and when bugs come back to the team (which is not necessarily a bad sign per se – it can be as well indication that people start using your application). How much of problems you have in the application depends on the quality, which depends on good design,  early testing and having right people to do refactoring.  There are plenty of books about “broken windows” and “Next gen” phenomena, when early releases are such a mess that you have to do it one more time – so you keep the old system alive and try to catch-up by delivering a new product. I hope you are not there, and if yes, I suggest you skip this blog and wish you good luck – you may as well read some other books first (“Clean Code” , “How to fight depression” or something similar).
In this blog post I will be talking about finding the right balance between making new things and solving past problems, keeping people motivated to work both on “new cool stuff” and bug fixes, and managing customer expectations. Of course if you are a lucky guy and you develop applications on the server side in the cloud, many of the issues that will be discussed here are less of a problem (deployment, bug fixes, merging issues etc).
Let’s start with people. As we all know, it is always much more fun to develop new features than to fix bugs. Creative people often think that the only part of creativity is to work on new things and if they get assigned to fix bugs, they might see this as a sign that you don’t appreciate their work. In my opinion, this is a primary reason why there is a common practice that novice on the floor gets to learn application by bug fixing. I think that this idea came first from guys that just hate bug fixing, and like in the army, made new guys to do some dirty stuff first, before they are allowed to work on some more rewarding activities. I find it so wrong on different levels. In some other places, you may see the opposite, where senior developers who are overwhelmed by doing bug fixes, get demotivated and finally run away from the project or the company. So, be careful how you address these issues, since mastering maintenance work is what makes or brakes your business in long run.
First, let me go back to creativity. I have all my life played handball and learned to respect sport stars. What people don’t see watching a game on TV is how much hard work and discipline is required to master any activity. Therefore, you need to establish a culture in which the bug fixing is part of normal activity of every developer – and more over, one of the means that makes them getting better at coding by learning from their own mistakes.
Very often I hear idea of having separate teams that are only busy with bug fixing, so that the first team is not slowed down – as they say, and as a result of that thinking, the maintenance task is given to another group. This is what then usually happens:
  • This makes merging fixes a nightmare
  • The code that the guy is fixing in one release might be already refactored and moved to another place in the next release. Even better, since people know that this will be the issue, developers are discouraged from refactoring.
  • In such project setup, the source control is also used as a damage control tool, so maintenance team very often has no rights to work on the current release – therefore bug never gets fixed in the next release.
  • The best guy to fix the code is the one who wrote it, since new person can easily introduce new bugs (or wrong behaviors) not knowing the complete context
  • It will make development guys less caring about the quality of code they write
  • It will drag your resources in training another group anyway
  • This doesn’t necessarily has to be a big effort

So, in my mind, every developer should get fair share of new features and bug fixes in every iteration. And this should be planned like any other activity in the project. I would recommend having fixed time allocation for this activity in every iteration. How much you need per iteration and per release first time is hard to know, and in order to for you to get good at this, I need to introduce some other aspects of the product lifecycles first: release cycle, maintenance strategy and customer SLA’s, since without it, this story would not be complete. More about that and how to effectively plan maintenance tasks in your project – so that you keep your customers and developers happy, you can read in my next blog post.

Posted in Agile|Agile, project management | Tagged , | Leave a comment

How to be effective at kick-offs

One of the reasons that agile folks hate to call kick-offs a meeting is because people just hate meetings. They are often done so badly that the first association that comes with that word is waste of time. One the other hand, I have often seen many kick-offs that are not any better than “so called” meetings. Whether you call it a name or not, doesn’t really matter. What matters is that people need to get organized, that work needs to be distributed and that complete team needs to get a full picture. Therefore, I am not shy to call them  meetings, as long as we can make them effective. And if you want to know how to be effective at that, there is no better place than listen to this podcastIf you ever want to be an effective manager, you should listen to what Marc and Mike have to say about different management subjects, but for the moment, let’s get back to our topic.

You can think of different meetings when it comes to agile development. As you can see from the list below, there are plenty of them, and you do wonder when the job gets done – so you better be good at it. Here we go:

  • stand up meetings
  • meetings that require split of work for the future (some call them scrum meetings or scrum of a scrum meetings if you have multi-site). Is there a scrum of a scrum of a scrum meeting?
  • meetings that require demonstration of the work (artifacts) that is done in the previous iteration
  • retrospectives (both after iterations and release)
  • release planning meetings (normally agile people kind of ignore this one – but yes it happens)

In this post I will tackle the third item (demonstration of the work done), since this is the one on which you will find the least in the literature – and may be by coincidence or not, this is the one with wich many teams strugle the most – especially if teams are distributed in different time zones. Preparation for the next iteration often happens on the same meeting – in case that projects are small in size, but for the sake of keeping things simple, I will skip that part. Finally, one important hint, avoid doing these meetings on Monday – since people have hard time on Monday remembering what they were doing the week before. In my opinion, the best day to start iteration is Tuesday.

What is the purpose of demonstration kick off?

  • Heartbeat of the project that keeps all sites in sync
  • Gives sense of direction
  • People have their 5 minutes of glory
  • PO can verify implemented stories
  • Test team/Doc team can follow what is happening (I know people will say that the test team should come up with BDD stuff and know up front all details of a demo, but that somehow doesn’t happen to me that often)
  • Have a working build after every iteration

And finally, here is how to do it:

  • Make one wiki page where you keep agenda’s of all iterations for this project
  • Make agenda upfront and send it one day in advance to the complete team with link to the wiki page (that points to agenda of the current iteration)
  • Every single person of the team should be on this meeting – regardless whether this is a multisite development or not. All communication tools should be available: phone bridge, share meeting tools (web-ex and similar) – and preferably this meeting should be held in video conference room.
  • For every item in the agenda include: Start time, Item, Owner and the Attachment (artifact) (see agenda template at the bottom of the page)
  • First item of this meeting is always project update, so that complete team gets full picture – and it is done by the scrum master. It should not last more than 5-10 minutes
  • Attachment is everything from ppt slides, picture, wiki page to animation or picture.
  • Artifact is teams definition of the accomplished task
  • Ask people to prepare demo’s and ask them to attach all their work in the wiki – prior to the demo
  • Demo is on the build server that has been installed by the test team 1 day in advance.
  • Build server includes only checked in code.
  • Demo – presentation of the artifact should not be longer than 20 minutes, on average not more than 10.
  • If presentation includes working software, person that has implemented it shows it on the live system. I have heard of the nice variant where a member of the test team gives a demo.
  • In case that something goes wrong during a demo – continue with attached animation so that you can get feedback from PO and the rest of a team. Best feedback always comes after people have seen the live demo, and even if real demo needs to be repeated in the next meeting, it is always good to continue with it.
  • When people start arguing too much about the demo (including PO) stop discussion and address in the meeting right after this one
  • Kick off meeting should not be longer than 2 hours

For people who for various reasons couldn’t be on that meeting, attachments and the agenda helps staying in touch with current development.

Example of the kick-off agenda in the wiki

We agree that an underlying cause of dyspnea could be confidently recognized within the most of sufferers (>75-percent within my website).
Posted in Agile|Agile, project management | Tagged , | Leave a comment

Project checklist – 7 questions you need to ask yourself first

Very often people discuss project/dev.  methodologies, type of contracts (fixed price vs. time and material), product release cycles and other aspects of project lifecycle while ignoring or forgetting to ask themselves some very important questions first.

So, let me go over my project checklist and default answers, keeping in mind that the only good answer that always applies is “it all depends

  1. Is this project done in small startup or big corporation? This might be more of a rhetorical question, just to get you prepared for different dynamics you might expect when it comes to getting budget for HW, IT support, support from stakeholders etc.. What might be “given” in one company can sound as a bridge too far in the other one. Be prepared before you start project to check all of these and if required – work on your networking.
  2. Is this project about building a product or is this one-off customer project (CDE)? Goals are not necessarily the same for both. If we talk about CDE projects, it is important to satisfy a customer who pays the bill (here we either go XP way or implement everything to the letter), while if you want to make a product that sells over years, I would argue that PO role is much more than just a customer facing person. That might as well answer the question in case you do outsourcing, whether you should be in favor of fixed price or time and material contracts.
  3. Is this project part of the bigger solution or not? You can afford to do agile project planning by selecting features from the backlog for the next iteration one iteration upfront only if you are the only customer of that project. Period. Here I am not making distinction between company that is the customer of that product, or the product that has only one customer. In case that your product is part of the bigger solution, you need to build a skeleton plan (see story maps and similar techniques) and revisit dependencies over the project lifecycle.  “Famous” Gantt charts can help you too – when it comes to drawing dependencies with other modules, products and expected milestones – which you need to communicate to outside world anyway. Be ready to add communication and planing overhead into your project. And to make it clear, I am not saying that in that case you should give up on agile development – just that you need to add real project management role to your scrum master role or ask someone else to do that part for you.
  4. Is this product going to be deployed in the cloud (server side on the web) or it is going to be installed at the customer premises? If your product is hosted on the web, maintenance cost is minimal and release cycles can be very short. If you are making B2B software that ships to customers behind firewall that expect fixes up to 3 years from the date the product is released, any release cycle shorter than 6 months is suicidal. Nevertheless, continuous integration and unit/automation testing should always take place, no excuse there.
  5. Is this product made for space program, military, medical institution, finance, large business or end consumers?Level of regulations, required documentation, tools that are used, coding languages, procedures, is something that you or your team can’t always decide on their own.
  6. Is this single or multi-site development? If this is your first multi-site project, grab books from Crag Larman or Alistair Cockburn that talk about it and read them twice. After that, be ready for some traveling.
  7. Is your team made of motivated and senior developers or not? If you have bunch of young motivated guys, you will succeed – in the next release, providing you are still around and people are still motivated after the first one. Take time to train people, be aware not to do too much micromanagement and keep the good spirit in the team. If you have bunch of non-motivated juniors – run away. If you have non-motivated seniors, you have to earn your money. And finally, if you have a great team, you should not worry, you will even have some time to read and write some boring blogs.
Posted in Agile|Agile, project management | Tagged | Leave a comment

Budgeting vs. agile

In my previous post I have shortly introduced some basic financial principles. It might look odd that I talked about business and markets in the space that should be reserved for agile posts, but I felt that one of the reasons why many agile transformations fail in big corporations is not well understood.  Failures to introduce agile are often associated with lousy managers, complexity of organizations, corporate culture etc. That is all fine, but I believe that the root cause is in another place – in the way corporations run their businesses. This is how normally business process works, and nothing looks that fancy at the first sight:

Investors that govern large corporations look to increase their investment on a yearly basis, and in process every business unit within the organization tries to get to similar grow figures. Since companies try to get more revenues from existing markets (as emerging markets never produce enough revenues at very beginning), majority of company resources are always locked to their existing customers. One of the effects of such dynamics is that big organizations are incapable of following disruptive markets (ref: book “Innovators Dilemma”).

But there is one more important problem, and it starts with budgeting. Let’s imagine for the moment that your part of organization has made 100 million last year and that new target for this year is 110 million. The first logical thing to do you might think would be to ask sales guys (who else can bring you another 10 million next year?) is which features or products this unit needs to develop in the coming year to get to the target. Based on their feedback, in top down fashion, budget will be distributed over different projects depending on the business needs. By the time that project manager got his budget (people, material etc.) promises to the customers have been already made – how otherwise would sales guy come with 10% higher revenue for the next year? So, famous triangle of the fixed cost, timeline and content is there already at very beginning of the fiscal year!

That is not complete story. Projects that generate less money over years will get fewer budgets, without actually paying too much attention whether they still have customers on that product – who can still request new features or bug fixes. In B2B environments customers can retaliate in unexpected places and in what I call management by escalation mode, such projects can start suddenly sucking resources from other projects.

Finally what is there for project managers? On one side there is a huge pressure to make the features with committed dates and given budget, and on the other hand uncertainty that comes from running any software project. Temptation to manage projects using waterfall is clear, as managers badly need to believe that complexity and chaos of running software project can be only be put under control by paper work and Gantt charts.

There is also another option you might think would work. Let’s imagine you want to do bottom up approach, or even better, put all folks in the same room: business guys, sales guys, project managers etc.. Dynamics that you can often see then is that project managers will start whining and asking always for more resources – which will be followed by challenges from higher management to remove all “fat” which will in the end produce very nice working atmosphere for the rest of a year.

Not surprisingly, most of the books and blogs which introduce agile practices use in the examples smaller groups and single products. For many garage like companies agile brings discipline and focus to already flexible and motivated environment.

In larger established organization, dynamics can be quite different and breaking existing culture which is required to adopt agile is much harder than people might think. Very often, the problem is already there at beginning of the year, at the time that sales guys meet executives.

I always find asking the right questions more important than finding magic solutions. In my next blog post, I will add few more questions you may want to ask yourself, before you walk in the room with your agile slides.

Posted in Agile|Agile, project management | Tagged , | Leave a comment

Finance for dummies and why it should matter to you

The reason I want you to go through pain of reading this blog is because I believe that agile community is missing something when it comes to the budgeting and how the business gets funded. That very often makes agile getting into collision course with higher management, but before I go further (that will be in my next blog), sorry you need to read this one first. What I learned by reading about finance is that math was not the problem, but the language that these guys use. It’s that fancy English that you hear and then your eyeballs start rolling and next second you are lost.

So, let’s start first with some simple definitions and formulas:

Revenue (R): Income for a given period.

Cost of sales (C): Manufacturing cost, or retailing cost or something like that

Gross profit (G) = Revenue – Cost of sales

Operating expenses (OE): So called overhead of the business – pay checks, water and electricity bill, rent for the office and any other administration required for running the business.

Operating profit (OP) = Cost of sales – Operating expenses

Finance expenses (FE): Interest cost of debt (like you take a loan from the bank…)

Taxation expense (TE): On every income you need to pay the tax

Net profit (P): Operating profit – Finance expenses – Taxation expense: profit or loss. Profit is either used to reinvest in the business or it gets distributed to the shareholders via dividends.

Mark up: G/C [%] (percentage of direct cost, premium added to direct cost)

Margin (m): G/R [%] (profit as percentage of sales price)

(Here is the funny thing, you may wonder how tweeter makes money – well they don’t, but this is something else. Higher the ratio between the value of the share and the actual profit share generates, higher the growth prospects investors see in the company. In case of tweeter (or facebook), private investors gave the money to the owner in return to the part of the company – indirectly telling the market how much they believe the value of the company is – once it is listed on the stock market. That also explains why sometimes good profit figures of the company still can bring the shares down – since the share is all about the belief in future earnings)

Ok, so let’s do the quick check with one example just that you get some feeling for numbers:

If you work in a corporation that sells 10 million units for price of 1 euro per unit, and your cost of sales is 8 million with operating cost of 1 million, the gross profit would be 2 million, mark-up 25% and margin 20% and finally the net profit would be .5 million.

Ok, here is the formula of the net profit impact (R1/R2) at time T1 and T2 (ignoring TE, and FE for simplicity), where N is the volume, and S the price per unit and m is the margin (hope got this one right):

R1/R2 = ((N1 * S1  – (C1+O1)*(1-m1)) * (1-m2))/ ((N2 * S2  – (C2+O2)*(1-m2)) * (1-m1)).

So, let’s assume for the moment that C, O are not changing and m is very low and volumes N very high (which is more or less true for high tech companies):

R1/R2 (C,O) is approx N1/N2 * (1-m2)/(1-m1)

What happens if another company enters the same market and brings the price down to 90 cents?

Your gross profit goes down from 2 to 1 million, your mark-up down to 12.5% and margin to 10%. If you want to sustain the same revenue of 0.5 million, you would probably need to sell now 20 million units of the same product instead of 10m.  Smaller the margin, more volume you have to produce, in order to sustain the same net profit. How are you going to do that if other guys have just cut the price? Well you can decrease it further and then you need even a bigger volume. You got the picture? Or you can just stay cool and hope your product is of a better quality. Then you better be sure that customer thinks the same – so this is why companies talk “customer first”.

Another option is to cut the cost of sales (if that is a high number), in companies that means squeezing your suppliers. If that doesn’t work, well you need to cut the operational cost – which can mean less travel, sometimes lay offs, moving to low cost sites or something like that.

So congratulations, this was your first lesson.

Things that can vary in this formula is cost of sales (which depends on whether you produce goods or not, whether you have dedicated sales channels etc.), whether the cost of sales increases with volume or not (in software that can vary from the cloud services where you need huge farms that are big original investment but can scale well or minor cost if you just download applications), operational cost, different tax regimes, and whether you reinvest or distribute profit to share holders. Each of these variations can produce new effects and that is the reason why all these finance books are thick, but remember, underlying principle is really simple.

Next to things mentioned above, very important is the concept of cash flow, ROI and stuff like that. If you really got intrigued by this blog, I suggest you read that too, it might help you next time understand quarterly results of your company.

In my next blog I will explain how budgeting process often collides with the basic principle of agile/project management and why we should consider different project management techniques for different parts of the organizations.

Posted in project management | Tagged | Leave a comment

Agile and outsourcing, how to make it work

When I was asked first time to start outsourcing, I really had no stomach, nor desire to prove being a big manager by traveling around, asking for reports every single day, sweating in the night from stress and frustration, and blaming all other folks for my problems … There are plenty of horror stories about outsourcing business, and you can probably find the one you like the most on the web and tell it in the bar – but that is not me, I hate whining.
The very reason why I started agile development was to prove that outsourcing model was not working and that dozen people that are talented and motivated can be more productive than hundred people on the other side of the ocean. And now the funny thing, not only that I was asked to start off-shore, but I had to prove to myself that I had been wrong – isn’t that a great challenge?  At first sight, idea of having off-site agile team, and more over from the outsourcing company sounded as a mission impossible – and this is when I first thought of the “plumber’s dilemma“:
Imagine you have a water leak in the bathroom. You call a plumber; he comes and sees that your problem is trivial. If he repairs it quickly and asks for the bill that includes his time to come and leave your place, you will be rather annoyed by the price you had to pay (and probably felt dull at the same time since you failed to do it yourself). If he stays a little bit longer, you would probably not mind paying exactly the same price, thinking that the problem was not that easy to solve. Here is a dilemma that plumber has: it he stays at your place for too long, he will not be able to visit another customer, on the other hand if he stays for a shorter period at your place, he would probably not be able to get a good price and keep the existing customer happy. That is probably the reason that most of the repairs take about 1-2 hours. Not less, not more, unless you really have a big problem or a louzy plumber. What would be great is if you were able to tell him how much you think the value of the repair was, and let him do the job as fast as he can.
In order to achieve this, two things need to happen. First, you need to build the trust between two parties. Secondly, it is essential for both parties to understand business environment in which they both operate.
Although this is not exactly the same problem as you have it in the outsourcing business, and dynamics between the customer and outsourcing partner depends on other aspects such as whether the project is on time and material or fixed price contract, in the end of a day I find it convenient to think of it in the context of “plumber’s dilemma”. That also might explain better why in the previous blog I started with Taleb’s concept of scalable vs. non scalable businesses when introducing this topic.
When I wanted to build the agile off-shore team, I knew that outsourcing partner would feel that this was something that was not fitting their business model (here I talk about 2003-4, things might have change recently) and that lack of will and expertise in agile would fail the project very soon.
So, here is what I did, step by step, you can take it is a recipe and try (but please no shortcuts)

7 Steps: How to create off-shore agile group

  1. Bring 2-3 subcontractors on site for longer period, before you start any off-site activity. Make sure that these guys are excellent. They must be good coders, speak fluent English and have good soft skills. (First two guys that we got on the floor were next week on the flight back to the place of origin. Somehow our partner thought that we were not that serious. To be honest, we also forgot to interview them. Next two guys passed very long interview with 3-4 of our best coders before coming.)
  2. Embed subcontractors in the team; treat them with all respect like any other team member. They would learn better about the product, get to know European culture (we are not shy to say that something sucks when it does) and learn agile. In some cultures, where high respect for authority is expressed in both their customs and their language this can be a challenge. More about this problem you can find in this great blog post
  3. After some period, create the off-site group and bring the first subcontractors back. By now, they should be your ambassadors that will be responsible for creating agile group on another site. At the same time, start building relations with the business partner. Before this phase, you are not that important to them as they only see you burning two of their good resources… Now is the time to go back to them and tell them a big picture – the game you want to play.
  4. Interview every single person that will be part of that team.  This is a tricky one for the outsourcing company, but first time you need to insist on that.
  5. Prepare time and material contract for the off-site team and avoid discussions on metrics. Have one contact person with whom you will be discussing all financial and other aspects of the project. You should connect to this person at least once a month for follow up (this has nothing to do with scrum master or agile, don’t mix these two).
  6. Make hardware and software environment to be exactly the same on all sites and promote accountability and responsibility on all sites – there should be no second class citizens!
  7. Continue with rotation, always having 2 new members from the off-site group at your place – 6 months rotation cycle.
Finally, as every fairy tail that people are proud to put in their blogs, we have built a great product that has become a huge commercial success. During this journey we have created two fantastic agile teams, and I’ve got to know some great people. It was learning experience for all of us. Few years later I used the same approach to start a new test team inside the company in Chennai – and again, it really worked well. The best part of the story is seeing people working together and treating each other with respect.
So, I was proven wrong – agile and outsourcing can work.
Posted in blog, project management | Tagged , , | Leave a comment

Software outsourcing dilemma

For people who have read “World is Flat” it looks obvious that in the world of internet and crowd sourcing, starting software business in the so called “low cost” countries is a logical step forward. Since intelligence, expertise and ambition in people is not bound by race or political border, there should be no reason to believe that there is anything tricky about it. More over, as waterfall has let us believe, good upfront analysis, detailed documentation, proper planning, quality control and right process (CCMI, 6 sigma and similar) should secure our projects from failure. So far so good, and in the end of a day, this philosophy is what has made the call centers in India a great success.

In order to get to the problem, let me start with another book: “Black Swan”. In this book, Taleb not only talked about – well obviously black swans and how much he hates Gaussian and sees fractals all over the place, but he also explained very important concept of scalable and non-scalable jobs:

{next paragraph from novelist Karen Hancock blog}

Non-scalable professions are defined as those with a built-in cap on how much one can earn in pursuing them. A dentist’s recompense is directly related to the number of people he can see in a day, and that number is limited. A watch repairman’s income is likewise related to the number of watches he can repair in a day. Both examples require the worker to be physically present to perform the services they provide. Obviously this category includes all “regular” jobs that pay hourly or salaried wages. When you agree to the hourly rate or the salary, you are in essence capping the amount of income you will receive. Revenue depends on your continuous efforts in the job. This kind of work is largely predictable and, according to Taleb, not Black- Swan driven. They belong to a place he calls “Mediocristan.”

Scalable professions, on the other hand, are those which have no such cap, where you do the same amount of work for one person as you do for one million. Like, say, writing a novel. (grin) Other professions in this category would be entrepreneurial activities, scientific research, venture capitalists, stock traders, etc. The quality of your decisions is more important then the continuity of your efforts. These sorts of professions belong in the land of “Extremistan.”

“A scalable profession,” says Taleb, “is good only if you succeed.”

{end of paragraph}

So, you may wonder what these thing has to do with outsourcing in software business? Here is the funny thing, software business is by definition scalable business while outsourcing business is NOT!

On one hand outsourcing companies are looking to make money by having as many as possible people on the project, while people who owned the project are not only interested in the cost of the project (hopefully), but as well as in potential revenue that they can generate from their customers.

In general, there are two types of software projects, the ones in which the end customer is company that did the outsourcing (retail, governmental organization, banking industry)  – and they are called CDE’s (customer driven projects), and projects in which the end product is a software that the customer resells to the other party. Although it makes sense to go for fixed prices contracts in case of CDE’s, if you want to succeed in the scalable business – you need to be the best in the market, and next to good product strategy and good marketing, you also need to have great software developers.

Most of the big outsourcing companies in India create so called triangle model. At the top would be 1-5% of developers with 5-10 years of experience and they are paid rather well (actually these days their salaries are comparable with salaries in western countries). They are followed by up to 10% of less experienced developers followed by about 90% of junior developers. Salaries at the bottom of the pyramid are sometimes order of magnitude less than of the ones at the top. What customer of the outsourcing company would charge you is the average salary per head. So, one thing is very important to remember, the primary incentive of outsourcing company in this model is to add as many as possible developers to your project, since this is the only way they make money. Another very important feature of this model is that this model breaks if the best developers in outsourcing company work only on one project. As companies in India start feeling the pressure from countries like Vietnam, where costs are even lower, they would probably need to find a new outsourcing model in the future. In my opinion, one of directions that Indian outsourcing companies can take is to work on quality and go up in the food chain, which will eventually bring the prices up and have them compete with smaller agile groups in Europe and US.

Just check what Alistair Cockburn has to say about agile contracts on this link to see what is the dilemma that every subcontracting company has when it comes to software projects (and BTW if you have time read all his books and blogs, guy is just awesome).

In my next blog post, I will talk about my experience with Wipro – our outsourcing partner, and how we started probably the first outsourcing agile group back in 2003. This hard work turned into a great success for both of us and it is something that we are all proud of.

Posted in Agile|Agile, blog, project management, Uncategorized|Ostalo | Tagged , | Leave a comment

How we got screwed in the first place?

The waterfall model was invented in 1970.
The founding document of the waterfall model, created by Winston W. Royce, included two figures: one of the model itself and a second illustrating the major problems inherent in the model, or the reasons not to use the waterfall model.
Winston’s waterfall method tried to address” Cone of Uncertainty” problem by fixing functionality upfront and got it all wrong – and then he mentioned that in the same article, second page: “The  required design changes are  likely  to  be so disruptive  that  the software  requirements upon which  the design  is based  and which  provides the  rationale for  everything are  violated.  Either  the  requirements must  be modified, or  a substantial change  in  the design  is  required.  In effect the development process has returned  to  the origin and one can expect up  to  a  100-percent overrun  in  schedule  and/or  costs”.

Now something completely different?
(next paragraph from Wikipedia)
Henry Gantt was born in 1878.  In 1887, he  joined Frederick W. Taylor in applying scientific management principles to their work at Midvale Steel and Bethlehem Steel company. In his later career as a management consultant, following the invention of the Gantt chart, he also designed the ‘task and bonus’ system of wage payment and additional measurement methods for work efficiency and productivity.
Gantt designed his charts so that foremen or other supervisors could quickly know whether production was on schedule, ahead of schedule, or behind schedule. He describes two types of balances:
  • the “man’s record”, which shows what each worker should do and did do
  • the “daily balance of work”, which shows the amount of work to be done and the amount that is done.
Gantt charts became extremely popular within waterfall community, as they truly believed that you can solve software engineering problems using 19th Century methodology designed for blue colors workers.
So, how we got screwed?
Gantt charts and waterfall eventually created “some” problems:
  • SW development seen as blue color work, that lead to
  • “Caste development hierarchy”: requirements, system architect, sw. architects, coders, testers, which eventually lead to
  • Moving testers and coders to off shore (since nothing can go wrong), which lead to
  • More management overhead and more paper work, which lead to
  • Less willingness to change any requirement, which lead to
  • SW development crisis

In my next blog post, I will shortly explain India’s “triangle” business model, and why this model typically leads to big trouble. I will then cover how I approach the same issue (about 6 years ago), working hard with our outsourcing partner – which has lead to the long lasting collaboration and great commercial success of our product.

Posted in Agile|Agile, blog, project management | Tagged | Leave a comment

How to manage agile transformation (and manage expectations)

As mentioned in the previous post, most of the agile transformations these days are “top-down”. According to Standish Group “Chaos Reports” we still have more project failures than successful projects. One of (many reasons) for this you can find in my previous blog post (how we got screwed in the first place), but there are many reasons for the failures, and to be frank plenty of books written about that.. As Tolstoy wrote once “Happy families are all alike; every unhappy family is unhappy in its own way.”
So, here we have unhappy stakeholders, and the first thing they have in mind by going agile is to get all their problems fixed. As your task is to get it done, be careful at the beginning, since before you know it, you can be dragged into endless meetings, mea culpa sessions and get nice list of issues that people expect you to clean up for them. That is reason why people prefer to have consultant for that job, first they are well paid to deal with all that mess, secondly they are seen as “deux ex machina”, someone that can with no fear say and execute on his plans (what most of the people inside company would do anyway but afraid to openly say), and finally if the guy is really good and have support from the high management – he can eventually make it. So, don’t get me wrong, good consultants with charisma can make it happen.
In order to succeed in any transformation, it is essential to have strong support from stakeholders. Therefore, after educating them on what agile actually is (you can find plenty of good books around), you should first split the transformation in 5 different segments:
  1. Management practices – Improve communication, efficiency and transparency (visibility, inspection and adaptation)
  2. Engineering practices – Improve quality of our products (early testing, continuous integration etc.)
  3. Tools – Implement the right tools that enable us to be effective in both engineering and management practices
  4. Process – “formalize” agile process across the organization.
  5. Project specific issues – (parking lot for things that need to be addressed per each project)
The usual transformation trap is that people start talking and mixing all things at once. Operational folks are very often process freaks and when they talk about process they somehow talk tools and when we start talking tools we start talking IBM/HP …. Stop it, stop it, this is endless !!!!
You need to go back and split the problem, and remind all folks that on each segment there will be separate meeting and that for different issues, you might need to consult different people.
Posted in Agile|Agile, blog, project management, Uncategorized|Ostalo | Tagged , | Leave a comment