Skip to content

How to start migrating your Software Development Methodology to SCRUM? This post is not a complete guide but just suggests what I think are the four most important elements you have to start by. I’ve seen plenty of Scrum migration tries failing or worst surviving some way which never reached the original goal; to see that it is enough to participate to a daily stand up (or daily Scrum meeting) to see that it is not working

Just read this blog and get inspired. Well, probably you will discover that applying it is a Revolution. Yes, it is!

Scrum is a really good tool for “debugging” the development process, I would say the whole company, so put in mind that if “All” the Company is not supporting it, then it will be really hard. But don’t be frustrated: you’ll be able to better identify and understand why goals are not met and escalate those blockers.

There are lots of well known best practices about Scrum (artefacts, meetings, team composition, Backlog, User Stories, Sprint length, retrospectives, …) for sure it is not a good idea to revolutionize current asset in order to start with an “ideal” Scrum setup: the most important thing is the people! They have to work Agile and run Scrum!

My suggestion is to start with a few things at a time, first of all with the Product Backlog;

1. The Product Backlog: for sure something similar to a requirement list/product roadmap. A feature list exists in any company but usually is much more a wish list than a place where to gather and organize requirements to be transformed in working code. Pick up this wish list and transform into a backlog. At the beginning it would be more than enough to just introduce the concept of “Importance” and sort from more important to less important; JIRA Scrum board (and similar tools too) is really nice as it hides the “Importance” value (that most probably will be implemented as an additional column in some spreadsheet like file…) by simply ordering entries using drag and drop. The most important thing to ask Management or the Product Owner (PO)Bitbar Testing and Testdroid Scrum if there is one is to Prioritise (order) the backlog according with the most immediate needs; it is crucial that the entries in the top of the backlog are not shifting every day, here my dear SCRUM facilitator you have to conduct a battle in order to obtain this, your sword now is no so powerful but you can always say that it is strange to work in a Company where it is not really clear what should be done and that you can put 100$ on the fact that the worst car company in the world probably knows that a car to run needs at least wheels, engine and a steer. At the beginning, there will be a lot of stuff to be estimated than I recommend to use Story Points (SP), or banana points or as you want to call them. It is important that is a relative measure. The simplest way to estimate entries in backlog is playing the planning poker. If you have already estimations you can:

– Ignore them if they are not made from the team that will implement the things

– Assume that 1 MD = 1 SP and round them to the Fibonacci like sequence. Then start to think only in SP, this measurement unit “Evolves” with the team, but remember use planning poker and comparative approach for future estimations!

2. Sprint #1: the concept of Sprint must be introduced. It is difficult to immediately agree with management to have a decent duration for it ( 2 weeks? ) so you can accept to have one month length or more it is not relevant now our goal is to put in place an iterative delivery cycle and define the content the team will commit to deliver in first Sprint. If you have estimation done in MD/MH (than converted to SP 🙂 ) use that as a base, if not try to guess. Right now is not important how many story points you put in your Sprint it is much more important that you agree with management that those items you pick up will not change for the duration of the whole Sprint (this will facilitate the migration to shorter Sprint in mgmt head 🙂 )

3. Retrospective: it is mandatory You have to organize a Retrospective, you can merge at first time with the Sprint Review event, it is mandatory that PO will be there. Here is the moment for debugging the Sprint, here is the moment for implementing other pieces of the SCRUM tools, here is the place for discovering that has no sense to spend time on estimating things that one minute ago where at the top and suddenly at Sprint Planning where not so relevant, here is the place to discover that there is no time to test all the stuff we did, here is the place to discover that crappy code without tests is a pain to change … here is the place where the Scrum Master can help the team and the Company to migrate to Scrum with success.

4. Velocity: once the first sprint is gone you’ll make some change than finish a second Sprint and a third, then you can start to look at the Velocity, it’s just an estimation of how many Story points the team can deliver in one Sprint, put on a chart results of each Sprint and try to increase, but much more to “stabilize” it, but remember only Stories 100% Done can be counted … you see migration to SCRUM will require several months in the most optimistic of the case. The most important is “Inspect and Adapt” in few words make the retro work, make it find all blockers, all risks, all destabilization issues. The goal of the Scrum Master is (from a business perspective) provide to the PO the best Velocity as possible!

I’ve intentionally not noticed many of the other elements typically present in the Scrum-like the daily stand up, the demo, how the team should be composed… those are tools or practices that the Scrum Master can use in order to keep the 4 wheels of the Scrum rolling!

In one of my last working experiences, I was extremely surprised by how applying just these few points have automatically induced changes in management, for example, we have now just one PO, two weeks Sprints in a monthly release cycle, backlog top starting to have a good shape, and also … a lot of things that still need a fix.

But the most important is that everyone feels that things start to run in the right direction, while we are starting to look for velocity.


Article author