Why We Love Scrum (And You Should, Too!)

22
Jan 18
scrum

Why We Love Scrum (And You Should, Too!)

Having developed IT solutions for dozens of companies from all around the world, we have had to do with both traditional and agile methodologies. Over the years we have come to the conclusion that there is no better way of understanding customer’s needs and translating them into software than with a little help of… a whiteboard and a pad of sticky notes.

As surprising as it sounds it is the only requirement necessary to start working in Scrum. And not even a definite one. The essence of Scrum is intangible. It is rather a set of values, rules and roles than a strict procedure to follow or a tool to use. This is probably the first reason why we have liked it so much. It gives us room for creativeness, unconventional solutions and freedom of expressing our perspective. All that works perfectly in favor of solving complex problems, prioritizing tasks and delegating them to individual members of the team.

Agile and Scrum – is it any different?

scrum agile

At the beginning, it might get a little confusing. Not to delve too far into the theory, Agile refers to a set of methods and practices based on the values and principles expressed in the Agile Manifesto, which includes things like collaboration, self-organization, and cross-functionality of teams. Scrum to say the least is one of the many frameworks that fall into the category of agile development. As Ken Schwaber and Jeff Sutherland explain in the Scrum Guide: “it consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage. The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them”.

Why we prefer this particular way is mostly because it can be easily adjusted to the requirements of our client. This way no matter what your field of expertise is, what kind of business process needs to be tamed by the software – we will be able to help you.

scrum agile

If you still do not quite get the difference, try comparing… a diet and a recipe. A recipe for a particular dish needs to correspond with your diet. Otherwise, you will never see results! A diet is something “bigger” which determines what kind of recipe you are going to choose from the cookbook. Same with software development. Or any other project for that matter. There is no Scrum if you do not follow Agile Manifesto. Or at least you cannot say you have been following “doctor’s orders”.

 

 

 

Scrum is people

You really do not need much to begin working in Scrum. If there is a team of people willing to try, you are good to go!

scrumStart from assigning jobs. The actual tools you are going to use (the famous whiteboard for example) are not as important as getting the roles right.

First of all, the Scrum project requires a Product Owner. This is the person who represents user’s best interest and has the authority to say what goes into the final product. She or he stays in charge of an artifact typical for Scrum called Backlog. Product Owner not only approves the list of tasks and requirements but also prioritizes everything on it. The question a Product Owner needs to answer the most is: Is it a “Must Have” or a “Nice to Have” feature?

 

Every group requires a leader, someone who will discipline the rest. Without it there is a fair risk of procrastinating, trumping up or losing the motivation. Having that in mind, another very important role “to cast” is the role of a Scrum Master – the person who helps the team move along with the job. But being a leader means so much more than just bossing people around. In Scrum, the leader is also a servant. Not even the Scrum Master has the power to tell the Development Team how to turn Product Backlog into an Increment of a potentially releasable functionality!

Speaking of, a Development Team is a group of people responsible for delivering shippable product increments every Sprint (which is the goal!). The team needs to be self-organizing and cross-functional. It means that they independently decide how to proceed with the job and hold the competencies necessary to do so; without depending on others who are not a part of the team.

In our world of software development, the members of the Scrum Team are mostly programmers. Sometimes also sales representatives or business analysts. Regardless of what is their position in the company though, Scrum never recognizes titles other than a Developer. In the Development Team, everyone is equal and have the same right to speak up at any time.

Additionally, Scrum recognizes 5 rules of how the people involved should cooperate. Everything in order to organize the job and properly allocate responsibilities to the members of the team.

  1. Commitment: Team members individually commit to achieving their team goals, each and every Sprint.
  2. Courage: Team members know they have the courage to work through conflict and challenges together so that they can do the right thing.
  3. Focus: Team members focus exclusively on their team goals and the Sprint Backlog; there should be no work done other than through their Backlog.
  4. Openness: Team members and their stakeholders agree to be transparent about their work and any challenges they face.
  5. Respect: Team members respect each other to be technically capable and to work with good intent.

 

About the artifacts

– explaining all that weird stuff we have mentioned (and some more)

scrum

While talking about the roles, we have failed not to use some other cryptic terms. Therefore, we owe you some explanation.

First of all – Product Backlog. It is an ordered list of everything that is needed in the product or simply the only source of requirements and changes to be made. It contains a description of features, functions, requirements, enhancements, and necessary fixes. Important sidenote: it is never complete! It evolves constantly, as the product and the environment change.

 

Sprint. We have used that referring to a single iteration, a period of time (usually 2 weeks) in which the Development Team is obliged to introduce a finished Increment to the project.

The Increment is the sum of all the tasks completed during a single Sprint. It must be in useable condition and meet the definition of “Done.” It is up to the Development Team and the Product Owner to decide how that definition sounds like. What we say at eVolpe Software House is that it just means a working piece of software, 100% ready to be introduced to our client.

(But we have not explained everything about the Sprint yet!)

A Sprint consists of a couple of smaller parts. It is full 10 working days after all. Those elements are the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective. Now, let’s quickly go through them.

The Sprint Planning is a meeting being held in order to answer two following questions:

  1. What can we deliver in the upcoming Sprint?

  2. How will we achieve that?

 

The Daily Scrum (or Stand-Up) is an about 15-minutes-long meeting held to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one.

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog (if needed). During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that, attendees collaborate on the next things that could be done to optimize project’s value.

The Sprint Retrospective is an opportunity for the Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

3 Pillars of Scrum (and the whiteboard, at last)

scrumCongratulations, you have made it to the end of this article and here it is your price! We are finally going to speak on the whiteboard!

An important principle of Scrum is the idea of Transparency. It means that all the Developers should be aware of what everyone else is working on and what the Team is trying to accomplish. In order to assure that, we are using a professional software – called Redmine – along with a little more conventional tool.

Making things clear and visible on a whiteboard is really helping us run the projects properly. It also boosts our creativity. Being able to comprehend the whole process with just one look is definitely making things easier for many of us.

Another pillar of the framework is the rule of frequent Inspection. It helps to detect undesirable variances. It should not eclipse the bigger picture or get in the way of the work though.  The idea is to keep the track of the progress and react if anything goes wrong for some reason.

The third big pillar of Scrum is called Adaptation. If an inspector notices something unusual the adjustment must be made as soon as possible to minimize further damage.

The three pillars together assure the success of the project and make everyone’s job so much easier.


Because there is so much more to say about Scrum than what we were able to fit in a single blog post, we invite you to check our other publications.

Here we speak about Product Discovery – one of the first steps to a successful IT project: https://evolpe.software/product-discovery/.

Here you will find information about the specifics of Agile Software Development in Poland: https://evolpe.software/it-software-development-poland/.

Finally, if you are interested in having your software developed in Scrum, give us a call!

 


11
Dec 17

Discover your product, easy.

The thing with designing a software is that in most cases the idea of how should it look like is quite vague. As a person responsible for the project you were probably asked to deliver a brief description of its purpose.  But do you really know what to write? Most likely you will not be the only user of this system. How should you know what all the groups of interest actually need? And what is possible to achieve?

What is Product Discovery?

Product Discovery is a service that any consulting firm or software house should offer. It helps to understand what kind of an IT solution will be most suitable and correspondent with the specific requirements of your organization. But first, let’s see if you have actually recognized them all and if everything you might imagine truly applies. The best way to do it is to hold a workshop and invite representatives of each department to take part in it. With the help of a professional Business Analyst (designated by the software house), you will easily create the concept of your future product.

8 stages of Product Discovery workshop

And how does such a workshop look like? Well, it depends on an organization. In general, it is possible to distinguish 8 stages of so-called Product Discovery. Not all of them may apply to your specific organization but let’s go through them and find out your options.

1. The Horizon

product discovery

At this stage, you are going to look at a wider perspective of the whole process. First, you will get familiar with the agenda of this very meeting. You will also learn the nomenclature and all the definitions that are going to be necessary along the way. Next, you will hear about the methodologies in software development, and possibly get the idea of which one to choose. Finally, you might actually see the horizon – an overall idea of the product. But that is only stage one.  We are just getting started.

2. Recognition of the main business process

product discovery

You need to remember that the software itself is no remedy for any performance issues if it does not correspond with what you actually do at your company. Having that in mind, a very important part of the Product Discovery is its second stage. During this take of the workshop you will identify all the steps of your key business procedures. It is going to help to correctly design the system in the long term. The last thing you want is that your brand new application becomes the next bottleneck in your organization, right?

3. Determination of the general goals

product discovery

After you have recognized all the stages of your business process, it is important to gather them all and come up with just a few objectives. Those goals you set during the stage #3 of Product Discovery should stay with you throughout the whole time of software development. Each part of the system needs to be consistent with what is the general direction of the project.  This approach guarantees the success of the IT endeavor and makes every little functionality work in favor of your business.

4. Basic system demonstration

Is the software you think you need actually the best option?

product discovery

In some cases, the team involved in the project already has an idea about which type of existing software could be adjusted – if Open Source – to work with the specific requirements of the company. If so, it is the best moment to do a quick demonstration of such solution. This way you will be able to compare your business process with the capabilities of a certain product. It might be that it is exactly what you are looking for or… not at all. Having this knowledge at such an early stage of the project is going to save you a lot of time and money.

5. IT environment study

product discovery

A very important factor for any software development project is to be aware of all the other systems around it. There is a lot of potential in creating a well-communicated platform of many IT solutions. This way you will avoid repeating the information that already exists in your organization. In order to recognize what you already have and how it should correlate with the new piece of software, it is useful to do a simple outline showing the necessary integrations.

6. System beneficiaries recognition

product discovery

At the beginning of the article, we have made a prediction that you are not going to be the only user of the future software… At this point of Product Discovery workshop you should finally think of who is going to actually work with it. Before you make a judgment of what the software has to do, find out who will be using it and… ask them what they really need!

7. Value Proposition

based on a diagram that shows representatives of each department and their “Jobs, Pains and Gains

product discovery

The Value Proposition stage should lead you to a conclusion about more specific functionalities of the software. At this point, you should ask the future key users what kind of tasks (“Jobs”) they are facing during their work hours. Of some, you might just not be aware. After that, it is important to compare the results with the so-called “Pains”. It means shifting the attention onto all the things that are slowing down the progress in certain departments. Finally, think about what there is to do to fix all the problems along the way. The knowledge about challenges in your organization will help to design a comprehensive solution customized to your specific needs.

8. Comparison of the business process and the software idea

product discovery

The last stage of Product Discovery means a comparison of your business process with the more comprehensible idea of the software. The most important question to ask at this point is: How this case could look like in the system? This is when the concept of what needs to be done comes to life. This is when you discover your product! This is also when you can start the pre-implementation analysis and begin the development with the use of the chosen methodology and the help of a preferable software house.

What should you expect from the software house?

Of course, you are not going to be alone with all this work! 8 stages are quite a lot and you need someone to moderate the whole thing. The smartest way is to ask the software house to designate a professional Business Analyst to guide you through the process. Such person is going to be experienced and well-equipped to take on the responsibility of handling the meeting correctly.

Only thanks to such support you will fully benefit from the workshop! Their job is to make sure that one and all understand what is being discussed and that everyone is using the same nomenclature. It happens in some organizations that some terms mean different things in other departments. It might look like something obvious but it is crucial to the success of the Product Discovery that all the parties are on the same page, at all times! This is also how you will find out how competent your possible business partner actually is. If they have all the necessary qualifications, they will also offer a reliable support later on. This feeling of a mutual trust will be essential during the actual software development. And if something is going to be really clear about Product Discovery it is not only your big idea for the software but also the fact if the company you teamed up with is up for the job.


26
Jun 17
freelancer-software-house

Freelancer or Software House – what to choose?

Before choosing the right option it is essential to identify the difference between freelancing and software house services.

The concept of freelancing relates to a single person handling software development typically from the shelter of their household. The person usually works for an IT company and is using some extra hours on projects for individual investors. It’s a popular method to earn some additional money and gain experience while pursuing smaller projects.

A software house is a larger organization that deals with dedicated, customized IT solutions for business clients. It does what a freelancer could do but on a bigger scale. Software house projects are normally more advanced than those contracted with a freelancer.

What are the advantages and disadvantages of hiring a freelancer?

The main reason to hire a freelancer would be the financial one. It’s definitely much cheaper to have just one person work on a project. Other perk of giving the task to a freelancer is a pretty good chance we will be dealing with someone who has a great knowledge of the software. As mentioned above, many of freelancers out there work for professional teams as well.  Having all that in mind, we have to be also aware that the whole process will probably be more time-consuming and the result could not be enough if we’d expect a fully customized software. It’s simply not possible to quickly deliver well-developed and complex software if only one person is working on it (after hours)… Overall, leaving an IT project in hands of an individual developer is quite risky because every sickness, trip or other reason for taking an off day means suspension of the whole procedure with no one to take over!

How a software house could save the day?

The biggest advantage of a software house is… the continuity! The lack of it if dealing with freelancers sends more demanding customers right to companies such as eVolpe Software House. Having an organized team handle the job is much safer and efficient. As a client you can expect that even if one of the team members gets some time off, your project is being pursued without any disruptions.  A software house operates accordingly to high standards of project planning so you can be certain everything will be right on track even if someone skipped work that day. You could also await warranty or additional support (even after the software was implemented).

The only disadvantage you could find is probably the price. But that’s only if you are looking at it in terms of what’s objectively cheaper. Obviously, you will pay less for hiring a freelancer. But you will also receive less professional customer service. So those are only apparent savings. In the end, if you’re looking for an experienced, organized and well-equipped unit to deliver a customized software on time – the answer can be only software house!

How about an example to understand it better?

One of the most common examples while explaining IT development is the analogy to a construction project.

Let’s imagine you are building a house for yourself and your family. Even if the single construction worker you hired doesn’t deliver on time, nothing serious will happen. Well, you will probably have to stay at your parent’s house for a little longer (and no one would like that) but no tragedy yet.

Now, let’s say you are responsible for delivering a stadium before soccer world championships.  The pressure increases, right? The deadline is serious, your bosses are watching you, the whole COUNTRY (!) is watching you… For such investment you will definitely need an experienced, reliable partner who can assure you of the high level of proficiency and who will take the responsibility off your shoulders.

In conclusion…

When the project is small and there’s no pressure to finish it fast – hire a freelancer.

When your project is rather big and the time factor is important for you – hire a software house.