I hope that my words will shed some light on reasons why so many companies around us struggle and fail to succeed and maybe it will help some of you in your effort to become agile.
Scrum is one of the iterative agile software development methodologies. These days people often use it as a buzz word which solves all their problems. ”If it doesn’t work, let’s do it agile!”
Well, there are a lot of definitions on agile and scrum out there:
And, there is also a lot of people running around from scrum fundamentalists to skeptics, creating a lot of noise and mystery about it. Companies spend piles of money on agile transformations, but not always with positive results. So, why is agile so simple to understand, but extremely difficult to master? Let me dig into it and explain why and how we started with the agile transformation, what did not go well and where we are now…
While reading my first book about agile, I realized that (in a way) I was doing agile software development years before it was formulated (cool:). That is why it felt so natural to me when in 2008 we decided to implement scrum methodology at Davinci. It seemed to fit the best for the way we were working: not too many specifications, frequent need for deliveries, high flexibility, often scope changes, etc.
So we started…
We did quite a lot of what we read in books, but we were also very creative with finding excuses not to do what we didn’t like, or didn’t understand. Here is the list of the most commonly used approaches we evolved into:
Temporarily our ScrumBUT gave us a boost. BUT without the true understanding of the principles behind it and consequences of doing or not doing something, it started to crumble badly after a few months, and we couldn’t figure out what was wrong. Internally we improved a lot, and we were few levels higher than at the beginning, but the result was far from what we expected. We were creating a lot of good code. We shifted our continuous integration to a higher level. We stated to use new tooling which helped us to get a better control over the software development process and the quality. It was very frustrating because whatever we did, it resulted in worse. This trial and fail phase took us to 2012 with numerous ups and downs. We were saving each day by hard work with a very little satisfaction on any side.
A breakthrough was a project we worked on for a few months already. It had all the attributes of a project which ''MUST go OK''. There was a strong dedicated Product owner, experienced developers, and the deadlines were friendly. However, after few months we ended up in the same mess again. The idea to switch to the “scrum by the book” came from a guy from the project team itself. We used an argument that the project is in a bad state anyway, so whatever we do, it can only make things better. So we draw a thick line, and started to do scrum once again. Skeptics were saying that nothing will change, that it is just a methodology, and that we will keep delivering late, half-finished functionalities. Even with the full support from the management, there were tendencies to question the process (for example: 6 guys are sitting for 2 hours on a planning session which causes 1,5 day loss of the development time; or the customer can’t wait 2 weeks for a functionality until the sprint ends, and many more...)
Regardless of all this, we stuck to the rules. We defined roles, enforced their authority, we established dedicated Scrum master, changed the planning and estimation process, set the iteration to 2 weeks and organized all scrum ceremonies. And well, after 3 sprints, everybody could feel the relief. The situation calmed down, functionalities were built on time, things started to work. The trust between developers, product owner and the customer was slowly established. There was still quite a lot of pitfalls we had to overcome, but we kept following “the book”.
After a few months of success, this project become our flagship in the agile transformation effort. We decided to roll out the same approach for all our projects using this successful agile project as a reference – it was very easy to use the argument: ''It worked well before, so it can work well also now''. It was not easy, but it did work in the end.
All was heading such a good direction that after a few months we flew over the Scrum master trainer Iain McKenna. We spent very inspiring two days in discussions, mastered the training and the test, and got the Scrum Master certification. Thanks to the possibility to directly confrontate our reality with Iain’s years of experiences, we ended up in discussions which helped us to get scrum into our bones.
So we continued…
We are becoming more and more agile every day. These days we can deliver desired functionality in shorter time and in higher quality with more joy. The road is not smooth, but with the dedication and full understanding of agile and scrum mechanics, it is possible to succeed. We managed to adjust our scrum to the form which suits us as an organization, and make it tailor made for specific projects.
I still wonder…
Would it be less painful if we started with the scrum master training at the beginning? Or, would it be cheaper if we were supervised for a few months by the agile transformation professional at the very beginning of our journey?
Looking back, my conclusion is that, although it was a bumpy road, it resulted in a strong acceptance and understanding of agile principles by all people at Davinci. We were already technically and mentally prepared when we had our first agile project success, so it was relatively easy to spread the methodology to new projects without a major shake-up in our organization. We understand now that ‘’being agile’’ requires synergy of all these essential elements: mutual trust, agile mindset, involvement of all people, technical skills and the right tooling.
I often speak to our business partners and friends whose companies are undergoing an agile transformation (often pushed from the management). Even though it is accompanied by heavy training and coaching, I see that it is difficult for them to get agile into their blood. Agile cannot be pushed, it needs to be planted into minds. This is the main success factor. We often end up in long discussions with questions such as: What is scrum and agile good for anyway’’? These discussions always ensure me, that we did things the right way…
In my next blog post (Part 2), I will dive into the Davinci scrum itself (distributed teams, collaboration, tooling, etc.).
If you kept reading, let me endow you with some more tips: