Although I’m fairly young I have already found myself in several projects that tried to do scrum and some that did. I say tried and did because there is a real difference. Scrum is not just some method you use to do projects. It’s actually just a framework build upon the philosophy of agile software development. This is where most people go wrong. They do the framework but do not embrace the ideals behind it.
In this way only the process is changed and not the way they think about what they are doing. Without really breaking through to the core it will not be possible to get all the benefits of the ideas behind the method.
How is scrum not just a method?
First you have to understand that scrum can be separated into two parts; the framework and the philosophy.
The framework is fairly straight forward. It states that your project should be done in set’s of time boxes where a predetermined amount of work is done. These are called sprints. One has three human entities; the product owner, the scrum master and the team. the product owner acts on behalf of the client(s) and determines together with the scrum master and the team what needs to be done. The team does the work on the product, they self organize to meet the wishes of the product owner. The scrum master facilitates in the process and helps to get everybody in the rest of the organization up-to-speed with the scrum process the project is working with. As assets there is the product backlog that contains things the product owner would like the team to build. There is also the sprint backlog that holds items that will be done during a sprint. The sprint backlog gets it’s items from the product backlog and the product backlog gets filled by the product owner.
I could tell you more in detail how it works but these are the essentials. More on wikipedia.
The philosophy is something that can be seen as the bases of the framework. So, the sprints, team, owner, scrum master and backlogs are all there because there is an all saying idea behind it. Scum has some ground principles that is has taken from the agile manifesto:
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
That is, while there is value in the items on the right, we value the items on the left more.
Scrum itself adds to these values by adding; Commitment, Focus, Openness, Respect and Courage to the game. In essence what the philosophy is talking about is very sane and most people will agree with you on it.
But how does that change your life?
Changing your life!
I’ve had people come up to me and say: “I have a 30 page project plan and could you please tell me what you think of it.”. My response is: “No, I will not look at your document that tells me nothing. Tell me in 30 seconds what your project is about, starting now”. In that 30 seconds I would receive more information about the project then me reading the 30 page report.
We have come to a point in evolution where a 30 to 60 page report is normal. Plans and specifications are written in a way that will get you stuck half way into the project because you need to change some detail. This is where scrum will change your life. You will need to learn to let go, learn that change is good and that even if you plan you will never exactly arrive at the spot where you were planning to go.
Have the courage to let go and commit yourself to focus on creating openness and respect in what you do.
Be truly agile!
Scrum can change your life in many ways but the first one is really easy. Be truly agile! Expect your project to change half way. Expect not knowing the outcome of a project and the exact path you will need to walk to get there. And expect mostly that you will need to be a conductor of change instead of resisting it.
Being agile is not just a simple thing. It will show parts of you and the organization surrounding you that are not functioning well. And, you will have to deal with it. Although this might not be an easy task it will in the end improve throughput and quality of what you are doing.
It’s like chopping wood, easy!
One of the things scrum is build upon is to create deliverable software. To do this manageable the sprint was invented. Chop your stuff into manageable piece that you can manage handle and deliver. In my line of work that is even more important. Segmented code is easier to maintain and allows you to avoid duplication. I also found that this goes great with test driven development. Test are cleaner and better when they only cover one piece of functionality instead of a large chink. So, creating a modular, testable and maintainable product actually should come more naturally when working with scrum. There are also a ton of books on how to segment your product into pieces and plan for their completion.
although segmenting might not always sounds as such a good idea… it is in many cases. We face large tasks that we need to do. Planning these tasks is almost always very difficult and mostly we are very wrong in our estimation of them. If we make the chunks smaller the estimations become easier. It also reduces over and under-estimation consequences as the planning can move with the delivery of the smaller parts allowing for better prediction of the future.
Less is more!
this is the big controversial one. I mentioned this before, the example with the 30 page project plan… Scrum takes a different route. A project justification is created together with a rough product backlog. These server as the business end of your documentation. Quality is also something that is part of your business but should be owned by the team who are creating the product. They will discuss the quality needs of the product, the values they want to enforce to create a product with a good quality.
Out of that 30 page project plan the basic paperwork is condensed to just the necessities. Justification, plan and quality are all condensed in a few separate documents and tools that are actually in constant use. This compared to that 30 page project plan that will be consulted a couple of times during the project.
This does require all the noses to point in the same direction. People that know what is going on and the will stand for what they do. This requires people to be more then just a programmer, designer, tester or any other specialist that you might need for a project. The team must act as a unit of multidisciplinary people who work together on a common goal.
Allow yourself to fail
I already covered this subject more then a year ago in my post about “why failing IS an option”.
One of the thing in the current society we tend to forget is that we are allowed to fail. Our drive to perfection mostly asks us to do thing right every time we do it. This while allowing yourself to fail once in a while will actually allow you to grow more then without the failures. Did the Wright brothers build a working aircraft in one go? No! They failed time and time again to allow them to succeed.
Scrum facilitates failing by creating the sprints. Small deliveries make for less of a fuck-up when something goes wrong. This allows a team to fail occasionally and lets them discover what the problems are. So the next time the get into a similar situation the team will know what to do. Learning from the past mistakes.
All seems to be good and well within the land of scrum. Although this might be true most of the time and when done right the benefits are even greater. There are some pit falls that you might come across, problems that will need to deal with and impediments that you will need to remove.
Scrum challenges you to think about things that you would normally would not have to deal with straight away. Like who really owns the product and can say something about it. This instead of someone that is just put there to carry out orders and deal with the politics. The connection to the client needs to be as short and clean as possible. Scrum does not allow for a “patch” to be applied, the issue needs to be solved and this might cause some issues on its own.
Because of this sometimes “brutal” nature of Scrum you will need to think about things you might rather not. If this is negative is up to you, deal with the problem. You also run the risk to improve yourself in the process ;-).
Have the courage to let go and commit yourself to focus on creating openness and respect in what you do. Teach yourself to change when you need to, prepare for change by segmenting your work and to only do that that is required to get it done without creating extra baggage.