Scrum has been the unquestionable IT king for quite a while now. Many companies boast about this methodology and its multiple benefits as more and more projects are carried out with its use. Is Scrum here to stay, or is it just a fad? We’ve invited Michal Stochmal, Senior Product Manager at Comarch, to share his thoughts with us.
I think we should start by explaining briefly what Scrum is, don’t you think?
In the simplest terms, Scrum is a tool which allows you to carry out a project in dynamic conditions of the ever changing market. It can be defined as a project management framework. Just like programmers use frameworks to work with a code, Scrum is used by the whole team to work with a project.
What’s the deal with Scrum and Agile? In various job ads you can see these two terms being used interchangeably. Yet, aren’t they two different tools?
Scrum is one of the tools that helps meet the requirements of a swift approach to software production, i.e. Agile. Organizations often use other tools for efficient project management which are in some way entwined with Scrum.
IMHO, the fact that both terms: Scrum and Agile, tend to be used interchangeably in job ads is not a mistake but a hint for the applicant about how important this approach to project management is for companies. Scrum is so flexible that it works in a different way in every organization, making it impossible to compare job offers from two different companies based only on this parameter. The use of the term “Agile” should be understand as a general approach to project management, rather than a specific set of tools.
Your team has been using Scrum for quite some time now. What has changed since you introduced this solution?
In the past, the waterfall approach used to dominate web projects. It required us to collect client’s requirements and then move to the - rather long - software development phase. During that phase the client had no access to the product being developed. It wasn’t until the team decided that all the requirements had been met, that the software was handed to the client for his evaluation. As you can easily guess, this approach left plenty of room for potential disappointment. Clients aren’t always very knowledgeable about programming and they often can’t imagine how something is going to work (especially in case of “virtual” products). They lack the experience and the technical knowledge to define their expectation with sufficient precision. When faced with the finished solution, they would often shake their head. “This is not how I thought it would work” used to be a common mantra back in the waterfall times.
When working in Scrum, the client is present and can see the project progress at all time. After every sprint he can see the results and evaluate them in real time. When there is a need to change the project scope - we can do it way before the project is finished. From the point of view of the team, working in Scrum gives them the certainty that the functionalities they are developing are exactly what the client needs and wants, which helps avoid throwing days worth effort in the garbage just because “the client business needs changed 6 months ago”.
I imagine the Scrum Master plays a very important role in the team and he/she faces many challenges. What mistakes should a rookie SM avoid?
The biggest mistake, in my opinion, is to be rigid. Trying to always do things by the book doesn’t work in real life. The same rule applies to Scrum. I can’t think of one single example of all Scrum theoretical rules having been successfully used in practice. Every organization and every team is different, which is why you should always adapt the rules to the real conditions. Remember, theory draws an image of a perfect world where all the rules in their original form will make both the client and the team happy. Unfortunately real life often proves it wrong.
You’ve mentioned client’s participation in the project and easier requirement modification. What is the role of feedback in this process?
Scrum is all about feedback. When delivering a new element after every sprint, the team naturally expects to receive feedback. It is the only way they can react swiftly to dynamic changes. Feedback also helps to prevent programmers from getting frustrated, which is the worst thing that could happen to them.
Regular and frequent feedback as well as the possibility to modify the project scope and direction while still under development, allows to avoid situations when, after 2 years of hard work we release a product that is unfit to the market needs and useless. How frustrating is that!
What you are describing is a group feedback. Does Scrum allow for individual feedback as well?
In a Scrum team all feedback is a group feedback by default. The team regulates itself internally. If someone does something worth recognition - the whole team is praised. In case of negative feedback things can get a little more complicated and it all depends on how each member of the team takes criticism.
Group meetings are a perfect opportunity both for negative and positive feedback. There are situations, however, where negative feedback becomes more constructive, when delivered individually. Criticising someone’s work in front of the whole team can easily turn into mobbing.
When you look from the side, it looks like the feedback you get in the IT is quite different from what it is in other industries. What makes it so special?
In my opinion, feedback in the IT is completely different than in other industries. Why? First of all: what we produce is extremely intangible. Second of all: how we produce it is completely incomprehensible to the client. Let’s take a chair, for example. If you order a chair, you know it will take a while before it is ready. Wood needs to be collected, the pieces need to be cut, assembled and finally varnished. It is also perfectly clear to you that the supplier won’t be able to turn the chair into a couch, just because you’ve changed your mind.
In our case, every year we are forced to turn thousands of “chairs” into “couches”, just because clients think it is perfectly doable. “It’s such a slight change, it shouldn't take you long”. I guess this is the essential difference between our industry and others.
How well do programmers deal with criticism? They are said to be lone wolves, but what does it look like in real life? Is it true or is it more of a urban myth?
From my experience I can talk about two types of criticism. The first one is the criticism you get from within your own team. Usually nobody makes fuss over it knowing that it is well-intended and constructive and it is supposed to benefit the whole team. Most of programmers take it without major drama.
The “external” criticism coming from your superior or your client is a completely different story. It always feels unfair and harmful. Programmers tend to accept it reluctantly, but I don’t think it has anything to do with them being solo players. Even team players don’t take it easily.
Why is that?
Because every programmer who is committed to their work will stick to the previously agreed requirements. When they deliver a finished product they are convinced that it is of the highest quality. As long as it works, of course. When a programmer knows he didn’t do everything according to the specification, he is more inclined to accept criticism.
At the end of the day, the one who gives your product the final evaluation is the client, who isn’t always that good at explaining what he wants. And when he starts criticising your work because it is not exactly the way he imagined it to be, your natural reaction is to reject this criticism as unfair.
You’ve spoken a lot about criticism and praise in a Scrum team. We generally tend to evaluate the overall product, but there is also those “tiny elements” that compose it. How important is - in this context - the use of Code Review for a programmer’s daily work?
What’s most relevant about it, in my opinion, is the comfort of knowing that there is another pair of eyes that will look over your code and perhaps find something that you’ve missed. Of course this kind of double checking increases costs, which is why managers avoid it sometimes, but in my opinion it is worth every penny. Code Review helps you to make sure that the finished product is of the highest quality and at the same time it allows developers to polish their skills. Every time you get your code back with a “to fix” note is a valuable lesson and helps you avoid similar mistakes in the future. It should never be considered an offence to your abilities.
Let’s go back to Scrum for a minute. It has gained a lot of popularity in the recent years. Where does this trend from Scrum come from?
In simple terms, it has to do with how comfortable it is for engineers to use it and how much control it gives to the client. With the Waterfall approach the client would present their requirements and then wait for months to see the results. In Scrum on the other hand, the client is in permanent contact with the engineering team and - in case of any questions or doubts - can address them immediately. The same thing happens the other way round: if there is something the team is not 100% clear about, they contact the client right away.
As you can see, this model of work gives both parties a sense of responsibility for the project and once it is finished, they both feel equally satisfied.
It sounds like a perfect solution. Is there any other methodology that could replace it?
Certainly! There are plenty of tools out there that you can use. Remember: Scrum isn’t for all types of projects. Trying to push it in where it doesn’t fit is a huge mistake. The first question you always need to ask yourself is: ”Does it make sense to use Scrum here?”. If it does, go for it. But when it doesn’t, use a different tool that will better fit your needs. There are times where simple Waterfall can suit you just fine.