Scrum game

Imagine that everything business schools, consultants and coaches, professional managers and entrepreneurs told us is a complete lie! All of us, men of business, are trapped inside a certain circle that leads us nowhere.

Dead end.

End of the ride.

Period.

We’ve all heard a lot about how the right people щn the team are like greased gears in a mechanism of a Swiss Watch. If they all spin together, – each of them will succeed and, as a result – your business itself will be on the winner’s side.

More importantly: We tend to believe this, and so do our employees. We have been trained for this ever since kindergarten. There is no “I” in team, right?

The bitter truth

Here’s some food for thought: The world is selling us team spirit. And, as with any other great deal, it comes in a variety of flavors. Think of team management and business models like they are a part of something bigger. A large market, to be precise.

Any market tends to grow; it evolves, creates new deals and offers. It takes lots more effort just to keep the buyer interested. Surely, all such offers deliver a certain degree of convenience and improvements to the old ways. But are they really better in ten cases out of ten?

I mean that even in IT, one of the world’s most advanced and rapidly growing industries, we’ve had the same approach (Waterfall) towards management and project flow for quite a while. And it led to success, did it not?

It’s all about new trends. Or is it?

The number of IT companies that are not applying agile development in their workflow is close to a pretty round zero. And even those businesses, which are not currently applying Scrum, are considering doing so in the nearest future.

But does this happen because Agile development, and Scrum in particular is a great solution? Is it one of the modern world’s most breathtaking quality improvements? Or is it simply brilliantly marketed?

To make the answer a bit simpler: Is your business considering the adaptation of Scrum because it is sure to improve the flow of your projects? Or are you shifting to Scrum just because everyone else did so already?

Are silver bullets cheaper than dirt?

What is the only thing that’s completely intolerable in the IT industry? Silver bullets. The belief that every single issue out there can be addressed, and resolved with, but one trick, solution, technology or methodology.

Every project is unique. And each of them requires a personalized approach. This is the golden rule of great software development.

You wouldn’t go to an ophthalmologist when you have a sore throat, right? Despite whatever the model of operations that particular hospital has. When you experience pain – you want it to stop, or for someone to stop it. Yet, you will not trust just anybody.

Why do you think your software projects are different?

No size fits all

No size fits all

We are not saying Scrum is bad. I would never say such a terrible thing. It is, in fact, loved by millions. And, for an entire series of great reasons!

All we are saying is that you must know Scrum, before utilizing it in your business. You must know how it works and what to expect. And, more importantly, you must be sure whether you actually require using it for RDD (Real-Deal-Development)!

True power of Scrum

This article will clearly answer all of the above questions. However, it all comes with terms. We’ll start from the beginning. What is Scrum?

Our story dates back to 2001. Seventeen brave and passionate men gathered in Wasatch Mountains, Utah, to explore and create something new. We have the Agile Manifesto now, as a direct result of their efforts.

The Manifesto went viral pretty soon. And thus, Scrum was born as a vital part of this new Agile framework. Here’s what all the fuss is about:

  • Individuals over processes and interactions over tools: Scrum is entirely built around teams. People deliver business value by achieving shared goals. However, despite what we may have known or have been taught – goals are the secondary value in Scrum. Effective interaction is the priority. Interactions ensure success, or (if poorly managed) emphasizes absolute, destructive failure.

    This flow of things has a certain script when business gets real and it’s time for action: A Scrum team usually works as follows:

    1. Team analyzes requirements and creates the vision of how the project should flow;
    2. Work is being done (that’s not the end, merely the beginning);
    3. The next stage is the identification of possible issues and blockers that have risen along the way;
    4. The team resolves all difficulties within the scope;
    5. Issues that are outside the scope or concerns that were previously uncontrollable are being resolved.
  • Software that works over descriptive documentation: Scrum goes in sprints. They usually last for a week or two. And, most importantly, each of them ends up with a finished product. It doesn’t matter what you do during the sprint as long as you end up with a ready-to-go product. The product may not include all functional elements it has to (in terms of business value), but it has to be of shippable quality.
  • Responding over following: There is no single plan when a Scrum team is in the field. This framework is significantly better at resolving issues that have already appeared.

To make a long story short – you must have a vision, make it reality, and, only then will you analyze what’s wrong with it and apply fixes.

Sounds neat, right? You’ll only work with solid facts, resolve actual issues rather than theoretical ones and so on and so forth. A dream come true, isn’t it?

There is but one question that remains: Who is responsible for everything? It all sounds great in theory and all, but who is in charge, really? If thing go south, and fast, how will you play the blame-game card?

All you’ve wanted to know about roles in a Scrum team

Product managers, team leads and other business executives we are used to are not a part of Scrum. They are simply not required in such an environment. Any Scrum team is divided into three primary elements, three roles that really matter:

  1. Product Owner. This is the person who is primarily responsible for the success or failure of the product under development. Product owners are responsible for setting up standards and priorities of functionality. Product owners are the ones making key decisions regarding the product, and they literally decide on behalf of the entire team. PO’s maintain the backlog during the project flow, they are the bridge in communication between developers and other stakeholders, and they ensure end-user expectations (business value) are met, etc. Additionally PO’s are in charge of the budget and ROI as well as they arebeing the ones making decisions regarding quality. This means they decide, whether the product is ready to see the world or not.
  2. Scrum Master. This here is the mister fix-it-all. The person responsible for dealing with every slight issue the team faces. The fun part – he doesn’t even need to completely understand all of the requirements. His job is to react when something is broken, and to ensure it is fixed. However, these are far from all the responsibilities of a decent Scrum Master. Primarily, the person in this role is a guide to the team. He creates a trustworthy environment, he emphasizes and encourages creativity, he is in charge of all ongoing discussions, and he ensures his teammates are willing to share and are a part of the process.
  3. Scrum Dev Team. This is everybody responsible for actual development of the product. Scrum teams usually consist of developers, QA engineers, business analysts, etc. All of these people work together and simultaneously. Each has a set of tasks that have to be accomplished by the end of a particular sprint. Here’s an interesting detail: Members of the team identify the complexity of assigned tasks (each member does so with respect to only the tasks that are assigned to them personally) and they also estimate the amount of time and effort that will be required. The team reports about project status to their Scrum Master on a daily basis. They provide product owners with demos of accomplished work with respect to sprint reviews.

What does this mean in terms of actual business? You get flexibility. You operate with a solution that’s already delivered and ready for shipment. During the entire project flow.

This means that you, in theory, are operating with actual qualitative and quantitative data instead of presumptions and theory. You can show your app to a test group, gather feedback and entirely change your requirements based on their feedback. And this is done in the most painless manner possible.

Sounds great, doesn’t it? That’s why Scrum sells. That’s why it is the trend today.

Underwater stones

Underwater stones of rising glory

The situation here resembles the one Apple has with their iPhones. Are they world’s best smartphones? No. Are they the hardcore bestsellers? Definitely.

This happens because iPhones are great. They aren’t best in terms of numerous particular elements. Android-powered devices, for example, are far more flexible and customizable. Something as small as that also counts. Badly, in some cases.

iPhones are great as an entire piece as they combine quality with usability. They basically support you with everything you might need and are a great life improvement. But they are slightly less customizable than their competitors. They are slightly more expensive. Thy have a smaller app market. And in the end, all these tiny little issues matter. Especially when combined.

After all, it’s your project we are talking about. You are investing hard-earned dollars and are surely expecting a decent revenue, right? Otherwise, what’s the point?

Does it mean that Scrum is bad for you? No, it definitely does not. It’s just that is should be used when it fits the most, not just as a default framework.

You have to be 100% positive that the game’s worth the bet. Scrum, has requirements, you know. Violating them will absolutely demolish your project into tiny, worthless, shattered pieces. All that while playing along might become burdensome, troublesome and even unnecessary for your current task. Are you really in? Does your project REALLY need Scrum?

Hold on, before you answer the previous question consider the following challenges you will be facing:

  • There are no half-measures. Scrum does not mix with Waterfall or any other model, despite your desires. If you are in it – you’re either in it for good, or you are toast. You can’t just add elements like traditional meetings or documentation like plans combined (or even worse – instead) with the log. It will never work.
  • You have to work with professionals. Lack of training and experience demolishes Scrum-based projects. There is a lot of pressure on every single team member. They have precise tasks and exact deadlines. They have to be motivated and self-organized. Not something you would task a rookie, who still can’t chew gum and walk at the same time, right?
  • You will be forced to invest in automation testing. You work in sprints. They are fast. You either test it all quickly or you won’t have the chance to test everything at all. As simple as that.
  • You have to provide your team with a decent physical environment. A Scrum team has to work in one room, away from possible irritating factors, etc. People have little time. They can’t afford distractions. Every minute of their time is money falling out of your pocket.
  • Solid discipline is a necessity. Daily Scrum stand-up meetings aren’t everything a Scrum team must do. People must have a precise, clear definition of “what needs to be done.” And they need to do it. They must follow a certain script. Day, after day, after day.

That’s quite a lot of effort for something people claim is a glorious magical wand of software development. However it is entirely worth it. If your project requires Scrum, that is.

How does one know he’s in need of Scrum?

Here is a little handy checklist for you. If you answer “Yes” to all of the questions below – feel free to hop on the crazy Scrum-train ride.

  1. Does your project rely heavily on feedback?
  2. Perhaps you are uncertain about several elements and believe they will be changing during development?
  3. You do not have a clear vision of what you are building (as in the case when you know what users want from you but are not too certain about the best ways of delivering exactly that)?
  4. Each of your mistakes comes with an insanely high cost?
  5. You are about to get all-in into a severely complex project, but lack in actual experience (the all-startup problem)?

But will it still be hard to succeed even when the Scrum-based project requires Scrum?

It certainly will, but isn’t everything we do in the IT world insanely complex? Luckily outsourcing exists and is there for you. You can get fully equipped, trained and experienced professionals who are already properly placed and willing to start working whenever necessary. With less expense involved. That does sound like the deal of the century, doesn’t it?

However, if outsourcing is not your way and is entirely out of the question – we still have several tips for you to implement in-house. As it was already mentioned, there are no silver bullets in IT. Yet we, at QArea, have managed to develop a certain flow of activities that improve our Scrum teams.

The thing is, we love keeping all of our clients 100% satisfied. This has led to the creation of several improvements in our Scrum teams. The result – improved collaboration and communication, better delivery and astonishing quality of our solutions.

Sounds too good to take place in our reality? Well, to tell you the truth, we have cheated a little bit. We have 14 years of experience in software design, development and QA. Our experts know how software can work and how it should work. We’ve faced bugs. We’ve fixed them. Many are being repeated in one way or another during many development cycles.

That’s our trick number 1. We know what we do. It allows us to deal with numerous issues related to lack of planning and documentation. Yes, we develop within sprints and, accordingly, we use the backlog. But we also know how to write code in the best possible manner. We know how to avoid pits filled with venomous snakes. You can achieve the same in your project after hiring premium-class experts.

Trick number 2: Focus and precision. Our teams are simultaneously focused on but one or two challenges. This keeps their head clear and their results have proven to be much more than simply “outstanding” this way.

Trick number 3. Openness is the same for everyone. In a Scrum team, if you are involved in a project – you communicate and collaborate on the same level as any other team member. We all have the same rights.

Trick number 4. Continuous Integration. This is a lifesaver! This way we skip tons of rework, all materials are gathered in one place and customers can easily check on our progress at any time. Win-win for everybody.

Trick number 5. We love your job! And we are passionate about it. This is something that can’t be bought or achieved, only earned. Probably the biggest thing we, at QArea, are proud of.

So, are you up for the challenge of Scrum now? If you hesitate – please feel free to contact our managers for additional support and guidance.