How to start with Agile Scrum?
Agile Scrum may sound nice in theory, but how can you transform a traditional way of working to Scrum?
For starters, you have to accept that Scrum will most likely not fit nicely in your existing organization. There will always be reasons not to start and not everybody will welcome this change. That’s why you need just enough backup from stakeholders to get this thing going. Make some pragmatic agreements on possible concerns like governance, budget and security, but don’t try to cover everything. Start with your new way of working and learn! Change will only happen when you move, not by standing still and thinking about it. Things will go wrong, but that is not necessarily bad. If you learn from mistakes, you will get better and better.
If you are adopting Agile, you should be agile in your way of working.
Setting up a Scrum team
Hopefully you already have a team that just can’t wait to start working with Scrum. But before you start make sure you stick to a few simple rules:
The team size should not be more than ten people and everybody in the team should add value to the end product.
People who are only interested or want to be informed should not be included. Try to make the team as independent as possible. The most essential contributors to the end product should definitely be in because you don’t want to be dependant on other parties.
Scope
Although I think in the end you can use Scrum for any product, it would be wise to start with something relatively simple. A front-end application is usually easier to start with than a back-end application. It really helps if you can demo clear results every 2-3 weeks. Don’t start with outsourced applications, or distributed teams if you don’t have to.
Coaching
You may have a very enthusiastic team, and they may have read a lot about Scrum. Still it would be wise to assign a Scrum coach to the team. Preferably this should be somebody with a lot of scrum experience and possibly a LEAN background.
Scrum is difficult to master because you have to change behaviour of people.
A Scrum coach can help you to reflect on your approach and can assist you with all kinds of dilemma’s you will encounter in your Agile journey. Meanwhile try to train your own Scrum coaches. You will need them once you start to scale this thing up.
Mission
So what exactly is it the team will try to achieve? Take some time to clearly define this. A mission helps the team to make the right decisions and stay on track. It also avoids misuse of the team by adding all kinds of additional tasks that don’t really belong there.
Scrum team roles
To be successful with your scrum team you need a really good Product Owner.
I think you should never underestimate the importance of this. A skilled Product Owner will keep the team focussed on delivering software that adds business value. In order to do that the PO must manage the interests of all the stakeholders while keeping clear goals in mind. Trying to please everybody can lead to a constant change of direction and eventually disappointing results. The PO should be skilled and knowledgeable and must have full authority to manage the product backlog. Being PO will take a significant amount of time and cannot always be combined with the current tasks of the person who takes up the PO role.
The Development Team can assign somebody from the team to be the Scrum Master. Scrum Masters are not project leaders, so be careful to assign former project leaders in this role. The Scrum Master should be a coach and facilitator, helping the team with impediments and scrum events.
Scrum events
Next the Scrum events must be planned. The team must decide what the sprint duration will be. Try to keep this as short as possible (2-3 weeks). Coming from Waterfall people will have a natural tendency to make sprints quite long, because they are afraid they can’t deliver anything in such a short period of time. But this is something they have to learn.
Defining small slices of work is one of the key challenges of Scrum.
Also decide when you will have your Sprint planning, Daily Scrum, Sprint Review and Sprint Retrospective. Plan these periodically for a longer period, always on the same time and day.
Scrum Artifacts
The Product Owner and the Development Team can work to together to compile a Product Backlog. The ordering of the Product Backlog is very important. Do not waste any time on trying to make a full description of every item you can think of. Only the most important ones matter. The rest can be kept vague. The Product Backlog must evolve in time. This is fundamentally different from the Waterfall approach.
The Sprint Backlog includes all the backlog items the Development Team selects for a sprint, plus a plan to for delivering the Product Increment and realizing the Sprint Goal.
Read more on this topic here.