PART 1: Agile transformation at Davinci

There are lots of books written by smart guys about agile. In this article, I will use my experience from the agile transformation at Davinci. I will explain what we learned to avoid and what helped us to succeed. I will describe how we do scrum, what tooling we use, and how we changed from ''doing agile'' to ''being agile''.

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.

What is scrum?

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…

 

Agile transformation at Davinci

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:

  • We had “daily” scrum meetings, BUT only when we had time that day and rarely with the whole team (our Dutch colleagues) due to lack of proper videoconferencing or any other good reasons we could come up with.
  • We had a planning session, BUT just a senior developer attended because the others had to work.
  • We neither had the real Product owner nor the Scrum master, BUT instead of them, anyone who was important enough could initiate an ad-hoc change or change the priorities on the project (we were agile:-).
  • We did work in iterations, BUT we had to be able to deliver a release any time when someone though it is needed regardless of consequences.
  • We didn’t do Backlog refinement, because there was no time, BUT we guestimated needed effort (quite inaccurate).
  • We didn’t do demos, because we had no time for that (we left it to the customer to find out what’s new and how does it work).
  • We didn’t do retrospective, because we saw it as a waste of time (because we all knew why things went wrong).

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:

  • If you don’t believe in scrum, don’t do it
  • Make sure that you have a flag ship example, which can be followed by the others
  • Make sure that you have the right staff (if you don’t, train them give them freedom and responsibility, unleash their capabilities, make them care; let go people who don’t want to change, and poison the others (regardless of their actual importance and role)
  • Enforce the Scrum roles authority (Product Owner and Scrum master)
  • Create secure environment for team (anything can be said by anyone without consequences)
  • Broken trust is hard to restore, so never do anything what can jeopardize it (consciously or unconsciously)
  • Learn how to write good user stories, and define for yourself what ‘’DONE’’ means
  • Make sure that your IT infrastructure, tooling, software development and other processes can fulfil agile demands
  • If you don’t have a big budget to do a long term heavy agile transformation, start to do it by “the book” and stick to it (don’t question it; don’t stop doing all the things defined by the Scrum framework unless you fully understand what are they for and what are their consequences)
Publikované: 31. mar 2015 14:53 | Počet prečítaní: 1853
  • Peter Kobes

    CTO / Software Architect

    Peťo je náš Chief Technology Officer. V softvérovej oblasti pracuje od čias, keď sa veľkosť programov merala na bajty. V Davinci sa stará o to, aby softvér, ktorý robíme a to, ako ho robíme, robilo šťastným nielen zákazníka, ale aj všetkých developerov. Má rád nové veci a rôzne gadgets. Cení si netradičné pohľady na (obyčajné) veci a nemá rád slová "nedá sa".

We want you

Do you see yourself working with us? Check out our vacancies. Is your ideal vacancy not in the list? Please send an open application. We are interested in new talents, both young and experienced.

Join us