From fragile to Agile.
It is good to break the rules.
We’re delighted to welcome our new Scrum Master, Alex Dimitriou, someone we’ve wanted to work with for a long time, so by way of introduction we asked him to tell us about his own approach to Agile and project management.
“Like many people in the software industry my transition from Waterfall project management to Agile wasn’t a totally painless experience. The theory seemed easy — you just apply the principles of it and all your problems are gone. Well… that’s not exactly how it turned out.”
My first work experience in the IT world was a few years back in a company developing a process management tool and their approach to development lifecycle was pretty much that… process driven Waterfall.
The developers were locked in a room that nobody wanted to visit and the rest of the team in another room. Someone was getting the spec and the developers were developing and then we had to test it. That meant thousands of test cases trying to translate the spec into something that someone could test. I have to say that at the time I thought that this is the right way to do things and I was happy with my little processes.
A few years later I moved on to another company that followed the same Waterfall approach but they were thinking of moving into Agile. I have to say that I hated it, and I mean really hated it… seriously hated it!
The reason? You are asking someone like me to change their process! Really? You don’t mess with the process… never! . But then, how can I keep up to date with all the test cases I have to write, amend and verify in a single sprint? How can the developer develop all these features? How do we manage the project? Answering those questions was the beginning of a very interesting journey.
Agile is easy, just follow the rules. Right?
Er no. The company decided to try Agile (scrum to be precise) which meant that we have sprints and more meetings… retrospective, review, sprint planning and of course the daily stand up. We got a scrum master who seemed to know all about Agile and how to follow all the rules from the book. Ohhh wait… How Agile is Agile if you have to follow loads of rules?
I questioned this approach regularly, to the point that I was even called ‘unprofessional’ several times, but for me it was increasingly clear that something was not right.
Why did we have post-it notes on the wall for our sprint board when we already used a digital tool ? Why did we need to keep updating both every morning? I got really confused.
The answer they gave me was “visibility”. Really? Someone is going to try to read my handwriting on the post-it notes instead of looking to the real-time board on their machine? And at the end of the day they told us that it is about communication so why not communicate? Come to the stand up or even better come and talk to us. Simple.
The turning point.
Luckily enough I got involved in a more isolated project and I ended up being the test / scrum master for the team. This gave me the opportunity to try different things and I started looking into Agile from a different angle. I said to myself, what if instead of trying to follow all these rules we just follow the ones we like and if it doesn’t work then we can change our approach?
I also realised that the most important factor in Agile is communication and good relationships within the team. I shared my thoughts with the team to make sure that they were onboard and we started our quiet revolution.
Trust is one of the main keys to success; we were all in the same boat and at the end of the sprint the goal has to be met from the team not the individual.
This approach to Agile seemed to work nicely in our team and we were getting stuff delivered. From the testing perspective Agile was a very interesting chapter, but we were not using test cases anymore but instead we were using BDDs. The developers got more involved in testing and that gave me more time to help out with organising the team, analysing features, working with prototyping, user flows and design. In a way I started becoming a multi-tool, embracing all aspects of the project, just like every other member in the team. Isn’t that what Agile is all about?
Regardless of our successful releases, we kept getting bad feedback on our implementation from external “Agile coaches”. For a little while I was thinking that they might be right, and doubted our approach. Could it be that our team wasn’t functioning well, even though the releases were there to prove that our approach was working?
The thing that really opened my eyes into the Agile world was meeting Dan North, one of the gurus of Agile. As a team we had a chat with him and I explained the situation and the doubts other ‘coaches’ had sown in my mind. Dan’s immediate reaction was, “This is Agile and that’s exactly how you should be doing it. If it works for you and you deliver then it is right. If not just change it.”
I was delighted, at last I had clear and logical confirmation that my understanding of and approach to Agile was indeed the right way forward, and I felt confident to be the one driving the team in that direction. Our approach kept changing depending on the needs of the team but it was a natural evolution of the original approach and this is the beauty of Agile.
The point is to make the process work for you and not try to fit in a predesigned process that was built for a different purpose.
There are so many things that changed completely since my introduction to Agile, from the approach to test, to the use of BDDs instead of specs or test cases, and from the traditional dictatorial management approach to a smarter and more collegiate way of communicating with teams. But I think that’s for another time.
This is my journey from fragile to Agile… It was not easy but it was worth it.
Subscribe to our newsletter for free advice delivered to your inbox on a fortnightly basis.
Code like Commandos.
What software engineers can learn from submariners and special forces. At first glance there might not seem be a lot of similarities, but some recent reading has thrown up some […]