The advantage of Scrum in evaluating 'new stuff'

One of the greatest problem in Software industry is the rapid change in Technologies and Tools, a change so rapid that your knowledge become stale or obsolete before you have the time to fully master your new toys. In this scenario the major problem is how to evaluate some new “stuff”, while not losing money and, most important, how to understand if the new “stuff” is really better than the old one so it worth continue spending time on it and not moving on other newer “stuff”.

In traditional long term planning approach, like waterfall, this type of evaluation is really hard to obtain. You have several options, but no one is really good. Suppose you have a six month project, and you heard of some new “stuff” that seems promising, how you should handle this new “stuff”?

Waterfall or traditional approach

Gain a complete knowledge of the “stuff” before starting the project : With this approach you assign some tasks to resources for learning the new “stuff”. While people are doing Requirement Analysis, some resources starts learning and when it is time to outline the architecture of the software, they should decide if the new “stuff” should be used in the project. The major drawback of this approach, is that you hadno real experience of how this new Stuff will behave in your specific project with your real requirements, the decision will be made with incomplete information and the risk is discovering in the middle of the project, that the new “Stuff” actually is worst than the previous one.

Learn as you go, planning for a little delay in the project due to the introduction of the new “stuff” : with this approach you actually believe that the new “stuff” is useful, probably you got recommendations from other teams. Armed with this knowledge you decide to introduce it in your project while accommodating a little delay in development phase due to the time needed by developers to learn the new “stuff”. This is a risky path, because what happens if in the middle of the project something went wrong with the new stuff? How much delay you can expect and most important, how you can justify the delay to the customer? If at the end of the project the team will tell you that the new “stuff” is not good you probably wasted a great amount of time.

Use the new stuff in little part of the project, not a critical one, to evaluate it: This is the most conservative approach, you design your product to use the new “stuff” in a limited and not critical part. This will give to the development team the ability to learn it on a real Project, but if the new “stuff” proven to be bad for the team, risks are mitigated. The drawback is that you are evaluating the new stuff in an unimportant area. If everything went good no one can assure you that it will works for the critical part of the software.

All these approaches suffers of several problems, but the most dangerous is: **after the project is finished, (usually with delay in schedule) it is difficult if not impossible to answer the question: the introduction of the new “stuff” helped the team in the project? **Some team member will answer Yes, some other No, because after such a long time and in projects that quite are late on scheduling, it is nearly impossible evaluate the new “stuff” in isolation and it is easy to blame the new “stuff” as the root cause  Ex: “we are late, but we introduced XXX and YYY so the estimation was incorrect due to missing knowledge of these new tools”.

Scrum to the rescue

If you manage your project with Scrum the situation is really different. First of all you usually** introduce the new “stuff” because there is some evidence that it can be useful to solve a User Story of the current Sprint (or one that probably will be done in couple of sprint)**. Maybe the customer asked for some advanced search functionalities, with OR AND and advanced syntax and the team knows that there are some tools based on Lucene (Es Elastic Search) that can tremendously helps the team in implement the User Story. If you start evaluating some new “stuff” on a real User Story you have two great advantages: you start using it where you really need it and you start using on a limited amount of the project. If the new stuff is really Wrong, at least some user stories will slip in the next Sprint, this minimize the risk.

Another advantage of Scrum is Sprint Retrospective; when the team answer couple of  questions: What went well and What could be improved *.*Scrum process gives you the opportunity and the time to discuss on the new “stuff” as soon as it is is used to accomplish real Useful Work, giving you honest and useful feedback. After a new “stuff” is introduced, at the end of the first sprint the team probably still not mastered it, but they can probably know if it worth spending more time or if it was a waste of time. Sprint after sprint the knowledge of the new “stuff” improves and the team can refine the judgment. In each sprint you can extend the use of the new “Stuff” in other areas of the project if the team think that it can help implementing User Stories. This will permits to use the new “stuff” where you really need it and introduce it gradually in your team. The key part is that the evaluation is based on how the new “stuff” helped the team to implement User Stories and satisfy the customer.

In a rapid evolving industry, like software development, using Scrum is a really good solution to constantly verify new technologies in your team, with little risks, but with real world feedback at the same time.

If you do not know what Scrum is, or you want to refine knowledge on it I suggest you to read the guide at http://www.scrum.org as well reading some introductory book Es: Software In 30 Days.

Gian Maria.