Almost a year ago, the company I work for, started an effort to adopt Scrum and Agile principles for software development. The company hired certified agile consultants, did extensive trainings and the whole department made a commitment to give Scrum our very best. We were doing our version of "Scrum But" before that and I had small expectations from this new `experiment`.
After a few months I couldn't not believe the difference. The scrum teams were more focused, people committed to the same goals, the quality of delivered software was better, distractions and impediments were reduced and work reclaimed its meaning and its creativity again. This continued for a while but in the next months fundamental changes brought in the surface a series of dysfunctions and issues.
Over the course of six months the team changed 3 times. Some left, other changed roles, and a few joined us to form our current team. From the original 7 developers in the team when we started Scrum, now only 4 remain. We also changed scrum master 3 times. You would think this wouldn't affect us much but each of them worked differently and tried to apply a new way of doing certain things like retrospectives and the way we interact with our Scrum Board. This was confusing but experimenting with what works for you is important.
I have to admit despite everything the first six months of our scrum journey was very productive and we enjoyed a series of huge successes for us, the whole department and the company. Unfortunately now I feel more confused than ever. The most important of my concerns is that we argue on all fronts, all the time. This has a negative effect on all of us. You can clearly see people simply giving up on debates which means they don't care anymore. I tried to somehow bring this up during a retrospective. You would think that everyone would at least admit the existence of the issue but NO! Because people have lost interest, they are in complete denial...
There was at least one point where everyone agreed with me and that was the way we estimate product backlog items. After all that time you expect this procedure to be fast and easy to give estimations as a team. From time to time we achieved that but not recently. I had the belief that everyone should estimate with the same scale in mind, time or difficulty and risk or a combination of them. In a recent sprint planning one of our consultants was present and I asked him about this. He gave me an excellent example why it should stop bothering me. Let's say I see a pbi as a square and another team member sees it as a circle, as long as we give a similar estimation on the area of the object, it doesn't matter how we perceive it.
After that we did as a team a calibration of our estimation baseline and tried to estimate a new pbi. I will admit that it was one of those `buffer` pbis that we didn't have all acceptance criteria but still our estimations were all over the place. Even our agile coach fell off his chair laughing. He gave us a few advices but I don't think it's his role to give us straight solutions to our problems. We are supposed to be self organized. I don't mind that I actually prefer it but I think my team's number one issue is HIDING OUR ISSUES. Maybe work pressure lately is too much and not everyone feels like contributing in such debates, others may actually believe that there is no dysfunction in our team because they are in complete denial.
I tried from time to time to ask advice from our Scrum Master, but now I realize it's not his role to organize us but instead make us
self.organized. I am giving it a try to start educating myself with scrum and agile principles and I started with Tobias Mayer's `The People Scrum`. I believe Scrum is not just a framework of software development but it really stands as an intermediate buffer between the developers and the customers in order to facilitate the co-existence of these two entities. So reading `The People Scrum` was intriguing. Which people, developers, stakeholders, clients, upper management? Its main focus is the Scrum Team but I couldn't imagine all of the authors opinions applied in my `Scrum World` but I found certain chapters extremely insightful and I will actually attempt to try a few things.
The book is actually a series of blog posts and you can easily find them online. I suggest you to read the whole book but these chapters made the most impact on me:
- Estimation III: Don't Estimate
- Paying Off Technical Dept
- Marriage, But
- Seeking Consent