One year after...

one day I became Scrum Master

One year ago, in november, one of my colleague, who was Scrum Master in one of the projects we're working on, decided to move to other city. He need to also change the job, because there was no possibility to work from another city all the time.
So my boss came to me and asked me a simple question - do you want to became a Scrum Master of this project?

What could I say? :)

decision wasn't so easy

Ok, decision wasn't so easy. To be honest, I was "little bit" scared.

Why?

This project was old, there was lot of legacy code, there was no test, no documentation, introduce new features, fixing a bugs, improving existing functionality was really painful and took too long time.
In our company everyone was joking, that programmers are moved there as a punishment. Not too optimistic, isn't it?

So why I decided to move there? Because I really love challenges and turn this project into something maintainable, was great opportunity to verify my skills, knowledge and to learn new stuff.

what were my goals

Before I moved to this project, I had few conversations with my boss, to discuss things, that I thought was necessary for the project.
What was that?

First of all I told him that we need to create unit test for everything (of course whenever it makes sense). No excuse, that test are just waste of time, no dropping test, because of running time.

Second thing was design and documentation.
Why design and documentation in scrum? Because I tried this already in different project and this approach brought value (on the other hand, I really don't see anything wrong in combination agile with design and documentation).
Thanks to this we avoided discussion about wrong design during the code review, because it was done before implementation was started. It was easier to change something.
And it was much more easier for new programmer to start working and understand bussiness logic of the application.

Last thing was about refactoring.
I knew that it won't be possible to close project for few month and refactor places, where it was needed, but I told, that refactoring need to be continous in our developement process. We cannot wait until something will broke or customer will send us request with new bug. No, we need to do small refactorings whenever we notice, that is possible.

what happend after one year?

Recently I've done summary of last year. Does the goals was achieved? If yes, if it really brought benefits?
What are the conclusions?

After one year, we tripled amount of our tests. Whole new code is covered and many of old code also. We got real acceptance tests. What are the benefits?
We decrease amount of bugs, so we can spend more time on new functionality:)

We have good documentation, which is usefull for new developers. There is simplified introduction to business logic and there're diagrams for each bigger modul and functionality. We also have short tutorials for most of them. What are the benefits?
We're not spending so much time to explain new programmers what we're doing and how it works, because there are documents with those information. It's easy to use any modul, because even if it is complex, we always can read tutorial or/and look at diagrams:)

And last, but not least - refactoring. Right now we are refactoring our code all the time, whenever we will notice, that something can be done better. We are not waiting until we will touch it once again, we just doing it when this is fresh and we all know what is going on inside. What are the benefits?
It's much more easier to work with code, to maintain it, to develop new features. Whole design is really flexible, beucase we're still improving it.

But all of these benefits which I have mentioned are visible only for the team, but what are benefits for our customers?

• Less bug, what I already mentioned in the previous paragraph.
• We're releasing once per six-seven weeks and it's faster than was before.
• We are introducing more big functionalities.
• In each release we're introducing small improvements in GUI, in performance, in usability.

There was only one situation which had impact on our plans. And it wasn't unexpected, it was something that we were prepared on.


In short sentence - we are doing more things, with better quality and in shorter time.


Can't wait next year:)