Get best of the week

Can Scrum be used in outsourcing?

The question is very controversial, and I personally did not find a simple and obvious answer to it, although I have been looking for it for a long time and am still looking for it (I still believe that I will find a way to use the pure essence of scrum and nothing else on the outsourcing project). Nevertheless, the framework itself provides a lot of nishtyaks, whose benefits are difficult to deny, if not impossible. And yet, in the question by which the article is entitled, a real problem is read between the lines. Allow to voice.

Problem


Scrum is an agile framework; it involves agile development. Agile development requires flexible deadlines and a similar budget. Outsourcing development, in turn, in 95% of cases (except for dead-end) involves tight deadlines and a tight budget. Conditionally: “make me a corporate portal in 3 months, the budget is 3 million. I’m paying you for the result. ” And the customer is right, he wants to see the result. And the manager must lead the team to this result. But here's how to do it using scrum?

This framework assumes uncertainty in both timing and budget. That is, already at the initial stage of the project, the scrum itself tells you: “Wait, I can’t come here, there are clear deadlines and a real budget, you need to look for a critical path, plan everything ahead of time, look for something waterfall.”

Solution to the problem


Step 1. Start with something waterfall to sell your services.


From childhood, my dad taught me: "There is no black and white, look everywhere for the pros and cons." Yes, waterfall is outdated, yes it is not very suitable for agile development, but it gives understanding and allows you to calculate the critical path taking into account all the risks. Most likely, the critical path will be inaccurate and even a pessimistic assessment will be very optimistic (if you understand what I mean), but this step will give an approximate understanding of the amount of work for you and your customer.



You will have to spend a lot of time evaluating the project with the developers. For discussion of features. And this is a time that is a pity to spend, because the features will still have to be reevaluated later, but so far without it, nowhere else: otherwise the project will not be sold and the hound of outsourced development will not break the chain, in pursuit of the next bone - there will be no bone.

!

Step 2. Hooray! We took the project, we begin work on scrum (in its image and likeness)


The project is taken. It seems that all the deadlines are there. The task is clear, well, drove to do. Alert! Do not be so quick. Most likely many things have changed since the time you evaluated the project for the first time. Could, for example, appear design or flew new Wishlist from the customer.

I have a suggestion. Try scrum. From the backlog of the product, select the sprint backlog, groom. Plan your sprint carefully and see how the team handles it. Do daily scrams in the format “What the developer did yesterday / What he does today”. And retro at the end of the sprint, to summarize the successes of each and the successes of the team as a whole. You will quickly notice how the KPI of each developer grows from sprint to sprint, how the number of returns from QA decreases and how the product backlog decreases.



PS Do not rush to refuse new customer wishes. Maybe they make sense and they can be painlessly added to the product backlog instead of some other functionality that turned out to be no longer needed by your customer’s business (and accordingly the customer himself).

Step 2.1 Introduce the product owner to the project


More often than not, outsourcing companies have only one project manager. Without dividing into scrum masters and product owners, but this is not such a big problem as it seems at first glance.

For example, I have a cool tester on the project, to whom I delegated 90% of the responsibilities of the product owner (the remaining 10% is what comes from the customer, and I already pass it on to my colleague). Besides the fact that he is engaged in testing (and he does it perfectly), he also maintains and replenishes the backlog, writes a dock, builds flow and entity tables: he does a great job (not to the detriment of his core), for which I simply don’t have time, due to employment on other projects.

In this approach, there is another huge plus. For an experienced tester (and only this can be entrusted with product ownership) this is a great chance not to get bored and have fun with new tasks + to feel your worth. Do not forget to show confidence in the members of your team, at least because this is how you increase your authority as well.

PS Now I work on such a model not on all my projects. Somewhere, a scrum is simply not needed, because it complicates. These are mainly small projects for a period of one month or less.

Step 2.2 Convert clock rating to story points


Not the most important step, you can work without it, but more difficult. The fact is that when you evaluate the task in hours, the clock is different for everyone, it takes 6 hours for someone to create a domain entity (conditional task), someone has 7, someone has 8. In story points everyone will have the same = 8.

According to story points, it will be more convenient to calculate the KPI of each developer, compile a performance review, and track the success of the project, in general.

Arrange with developers for 8 (mb 5 for June) story points per day, plan based on this and look at how tasks are closed and the project is being implemented.

If a developer suddenly closes 8 story points in 4 hours (5 story points, according to the Fibonacci numbers), do not load him / her with new handles. Appreciate your agreement, respect his / her work. Part of his / her remaining “free” time will still be spent on studying the next feature, and preparing for tomorrow, and part on self-development, or even leisure. Good leisure also motivates working well.

Step 3. Work Cool


Do not do everything as written in scrum guides or in any other pm-standardizers. Make decisions flexibly, and build on the situation. Carefully select the tools offered by different frameworks and do not hesitate to try a new one.

No need to work on waterfall or scrum to manage projects successfully. Need to work cool. That's all.

Conclusion


Scrum can be used, and it will be very useful: an excellent framework that offers a bunch of cool tools in order to be constantly up to date, develop yourself and provide the basis for team growth, monitor the progress of the project and consider KPI members of your team.

Nevertheless, scrum is not a panacea, and to say, for example, to the customer that we initially do not know how much the project will get to you and how much time it will take in terms of outsourced development is most likely to fail. It’s all the same without waterfall elements.

Feel free to combine the frameworks and use the tools that you and your team like, even if they are not supposed to be scrum. Make it work conveniently, because this is the main goal of each framework. And how to call him is up to you.

PS I have it HMS - genetically modified scrum.

More articles:


All Articles