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.
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:
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.
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.
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.
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.
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
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.
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.
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.
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.