How to Outsource Scrum Projects by VA - HTML preview

PLEASE NOTE: This is an HTML preview only and some elements such as links or page numbers may be incorrect.
Download the book in PDF, ePub, Kindle for a complete version.

3

Why Serum?

The immanent characteristic of software is that it's open to constant development. Years ago, programmers noticed that traditional methods of making software were less efficient than expected. Then some of the developers started to find more effective frameworks to what they did everyday. Nobody wanted to waste time and  money.

On the other hand, a popular approach to outsourcing is still the Waterfall: highly structured physical environments in which after-the-fact changes are prohibitively costly. It is a sequential design process in which progress is seen as flowing through the phases of Conception, Initiation, Analysis, Design, Construction, Testing, Production/Implementation and Maintenance. Once it's done - it's done. Changing or shifting things during the period of making the software brings consequences - longer time of making the software, longer exposure to stress produced over the process of change. In Scrum it's possible to make changes on-the-fly and mandatory to cooperate.

img3.png

By Peter Kemp / Paul Smith (Adapted from Paul Smith's work at Wikipedia).

A key principle in Scrum is its recognition that customers can change their minds about what they want and  need. This allows to recognise the requirements late and  cleverly respond to emerging business changes without budget overruns.5

Scrum adopts an empirical approach: a problem cannot be fully understood and  defined, therefore the focus should be on delivering quickly and responding to changes.

Scrum fulfills the Manifesto for Agile Software Development6, which says:

'We are uncovering better ways of developing software by doing it and helping others do it'.

Through this work, we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Following this come 12 Principles of Agile Software Development7

1.    The highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2.  Welcome changing requirements, even late in development. Agile processes harness change for the customers' competitive advantage.

3.  Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4.  Business people and  developers must work together daily throughout the project.

5.  Build projects around motivated individuals. Give them the environment and  support they need, and  trust them to get the job done.

6.  The most efficient and  effective method of conveying information to and  within a development team is face-to-face conversation.

7.  Working software is the primary measure of progress.

8.  Agile processes promote sustainable development. The sponsors, developers, and  users should be able to maintain a constant pace indefinitely.

9.  Continuous attention to technical excellence and  good design enhances agility.

10. Simplicity-the art of maximising the amount of work not done-is essential.

11.  The best architectures, requirements, and  designs emerge from self-organising teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and  adjusts its behaviour accordingly.

How does Serum work?

Software development processes should be built around the three pillars of Scrum method: Transparency, Inspection, and  Adaptation.

Scrum Team is focused on understanding the Partner's vision and expectations at first. Customer and  Provider become partners in development. Throughout the project, the team is flexible for changes. They use iterative approach, where the Partner gets 'increments' of his or her product in less than 30 days that are called Sprints. Developer takes care of the Partners' investment by avoiding the 'big design up front' and 'technical debts' traps.

img4.png

The Scrum Process, source: http://en.wikipedia.org/

Building complex products for Partners is an inherently difficult task. Scrum provides a framework that allows teams to deal with this difficulty. This process is very simple, however difficult to master, especially for young development teams. The process is governed by the three main roles of Scrum Team: Product Owner, Scrum Master, and  Development Team. Product Owner takes care of the business value of the product as well as helps in communication with the Partner. Scrum Master provides the right pipeline for communication between all the developers, Product Owner, and  the Partner, and  makes sure the process supports Transparency, Inspection, and  Adaptation. And there goes the Development Team: in Scrum it's a self-organised team, which delivers a working product every Sprint. The progress of work of the Development Team is transparent and visible to all product's stakeholders.

The main advantage of iterative approach is that the Partner receives a working, and  therefore valuable product, every Sprint. In Waterfall, a part of the system can be delivered during the project, but these parts are not designed to give business value before the project is finished:

img5.png

Waterfall Process, credits: XSolve

In Scrum, Product Owner is responsible for prioritising requirements in Product Backlog for the Partner to receive a (business) valuable working product every Sprint:

img6.png

Scrum Process, credits: XSolve

Serum vs Serum-but

Scrum is easy to learn, but difficult to master. And Scrum is the most wanted method in the modern software development. These reasons make some developers unable to deliver Scrum Teams, even if they want to prove they can. Sometimes the Partner can hear software companies saying: 'Yes, we work in Scrum, but we found  that only parts work for us   '. This might be the first signal that such development company didn't master Scrum. Serum-but isn't Serum and might be dangerous because it puts Scrum Team off the balance and  often results in Development being not predictable and  not accountable at all. How to check if a given developer really mastered Scrum? Ask for a number of successfully finished projects in Scrum; ask for certificates, ask for experience with Scrum, check their company blog. Ask them how their organisation supports their teams and  develops them. Ask them if they have Scrum Coaches.

One of the most powerful questions might be asking them what they think about