Background
When I first started developing software back in 1998, at the time I was still a student and the projects I was building were my ideas — my product. Intuitively, I worked in a very incremental way: building one feature at a time, testing it and releasing it in production for the world to see, and to gather user feedback. It was both efficient and motivating, because I knew my work made a difference to people on a weekly basis.
Building databases was a key element of building any projects. Not because I was obsessed with data models, no. Because I could query data and extract some statistics from my production website, and get insights into how customers were using the features I had built. I was seeking feedback from everyone I knew, from family members to friends and school collegues. I knew getting feedback early and often was crucial for the success of my project.
A Broken Workplace
Fast forward many years, and I was hired by a large telecom company as part of it’s professional services branch. I thought I would be surrounded by passionate professionals just like myself, but I soon discovered that being a developer in such a setup wasn’t a very rewarding endeavor.
The development team was isolated from the users, having no contact whatsoever with the end customer. It was also clear from the organization that developers were not required anything but to read requirement documents produced by project managers, and, of course, provide estimates for the project to be completed. Better than this, the management would usually set which technical platform should be used.
I had become a disposable resource, with no power over the technology I used to implement the project on which I was assigned, and I had no possibility of participating in the process of gathering the needs of the client, who I never met. Gone were the days where I would explore the available data of the database too, since I no longer could access the production database. What was required of me was to maximize the amount of work I could get done, the output, and to let the others handle everything.
It had become clear that I wasn’t interested in becoming an employee in this kind of setup, but it’s what I knew best. Following the crisis, I lost my job at the Professional Services company and turned to consulting. This was the natural next step of what I had been doing. This is how I became a consultant.
Scrum, But…
The first time I really heard about Scrum was in 2008. I was sent as a consultant for a text parsing company, who was extracting meaning and facets from textual content. But like most organizations at the time, their implementation of Scrum could be summarized by saying that they held a daily stand-up, or daily Scrum.
They did not have Product Owner or a Scrum Master, but instead a dedicated a Project Manager. The scope of work was fixed and projects were always taking more time than planned. We did not do Sprints or time-boxing, and we never held a single Retrospective meeting. What’s more, since we did not do timeboxing, we didn’t review regularly the work we were doing either. Quality was average and most of the quality control was done externally at the end of the project. Ah, and we were always doing overtime. But of course, we were doing … daily stand-ups. That’s why they had advertised that they were using Scrum.
It wouldn’t be the first company where I see this kind of Scrum-but implementation, which really didn’t add that much value to the company, it’s client or the delivery team.
“Doing Agile”, Not Being Agile
They were of course other companies claiming that they had been implementing Scrum. They had daily Scrums, Sprints, even a meeting at the beginning of the Sprint and one at the end, although I would be hesitant to say they held a Sprint Planning or a Sprint Review. In many cases, they had a Project Manager coordinating these kind of initiatives, and it was clear the the Agile Values were not embodied, or even known.
Really, they were doing scrum, and “doing agile” to improve productivity and reduce risks, but the scope being fixed, and the use of automated testing being very minimalistic, projects would still require overtime and would sometimes end in very bad shape.
Ever heard “Bugs come from lazy programmers”? Some executives used to think that by hiring better developers, they would avoid having to hire quality specialists altogether; stripping the development team from another precious piece of the puzzle.
The problem was that the human was not part of the equation. The team wasn’t empowered to make decisions or to organize itself how it deemed best. Micromanagement was plaguing and people were very dissatisfied equally about the workplace, and the final product. The team requests would usually be required business case for hiring QA or upgrading computer equipment. There was very little they could do to improve their situation, and, consequently, the efficiency of the delivery process and quality of the delivered products.
Human Software Development
Throughout my consulting career I have witnessed more than a dozen of broken work environments where the development team was not valued or recognized for it’s hard work and expertise.
This was endemic to the industry of web development where I worked for a long time. Given no power even regarding technical aspects of their work, delivery teams were expected to produce quality work, on time, on budget, with a fixed-scope detailed requirements with a management and executives scrutinizing every step of their efforts, micromanaging their day-to-day and pushing for unpaid overtime when the deadline were close.
When I realized that I could be a change agent and help fellow developers have the tools and the proper work organization to do what they liked the most, and effectively deliver more value to their customer, while building better quality products, in a sustainable, over-time free workspace, all at the same time, without all the toxicity of the resource workplace, I thought I had to jump and transform my career, and help transform the workplace.
This is my purpose, and what brings meaning to my work everyday. This how I became Scrum Master, and this is why I am pursuing a career path towards Agile Coaching and Enterprise transformation; to change the workplace and the organization of work, to make it a better place to work while ending the practice of talking about people like we talk about disposable resources.