My Agile Journey: Part 1
My formal introduction to agile software development, specifically Scrum, came when the very small, privately held, niche company was purchased by a subsidiary of a large international conglomerate. I was working as a full stack developer: MS SQL, ASP.NET Web Forms, SOAP Web Services, JavaScript, HTML, CSS, XSLT, etc. The code base was over a decade old and had been cobbled together quickly and somewhat carelessly by the long gone founders. Older technologies such as ASP.NET 2.0 and ActiveX really needed to be replaced. The opportunity came with the sale of our company.
The new parent organization said they wanted us to use Scrum and that they would train us. The onsite training was scheduled without regard for their Operations team's schedule which resulted in many issues. We did not have a Product Owner or Scrum Master, so a new to the company (and industry) Development Manager became the Scrum Master and a tenured Development Manager became the Product Owner; neither was ever properly trained.
The corporate Agile Trainer came to our site and our week long endeavor began. Wanting to fully understand the Scrum framework, I asked a lot of questions and challenged a lot of the statements. There was no mention of The Scrum Guide or the Manifesto for Agile Software Development. Some of the material taught was at least two years outdated. Misrepresentations and falsities were also presented.
The last two days of training, without being expressed prior, became the beginning of our first Sprint. So with many new developers, unfamiliar with our product and new platform vision, we created the foundation of a Product Backlog and sized those items. Having been "trained" we were immediately expected to produce a Minimum Viable Product. Lacking proper Sprint Planning event, we began to create a mess (as in not clean) of code. We "successfully" completed the Sprint and were on to the next Sprint.
During the second Sprint we started to receive requests and concerns from management regarding productivity of employees. You know, the classic 100% utilization ignorance. Being the tenured developer, having experience protecting troops, and not being a "yes man" to management, I fielded those conversations to allow the Development Team to focus on working toward a quality product. I used what little knowledge I had gained from the training and a decent amount I had been learning from independent research to keep management at bay.
During Sprint 3, we began to recognize the issues with have a direct manager as the Scrum Master. He was trying his best, but Scrum Master is a role that should not and can not be conducted using classic management skills. We discussed it as a team and requested that we use one of our Development Team members serve as a Scrum Master starting the next Sprint.
Once we began Sprint 4, things improved. The members of the Development Team were becoming familiar with each other, the processes were improving, there was less concern about Scrum Master role conflict. By the end of Sprint 5 almost everyone was seeing the benefits to the Scrum framework, especially how it could improve our ability to create and deliver quality software.
I discovered The Scrum Guide and began implementing some of the missing pieces. Although I was the most tenured and experienced, I chose not to be the Scrum Master. The irony being that I was certainly filling that role in deed.
Other impediments remained. We had Development Team members who had to split commitments between projects. We hired some more resources including a Product Owner, who was actually a traditional, Taylor, PMI trained Project Manager. Management wanted us to track multiple projects in the same Product and Sprint Backlogs. They began asking about individual productivity again. I quoted The Scrum Guide and the wolves were at bay once again.
At the start of Sprint 7 I believed that at thirteen people, we needed to split into at least two smaller, Scrum recommended, sized Teams with resources dedicated to only one product. A few senior members discussed it and we introduced the topic to management. They agreed that it was a good idea. Our Product Owner suggested that we continue to drive the initiative by drafting a proposal to present to management. Why did we need management approval to be self-organizing?
The proposal was drafted, edited, and approved by the "small council" and sent to the so-called Agile Coach who had "trained" us for comment. He gave some feedback and the proposal was sent to management. Later I realized that this was the trainer's first interaction with the Development Team since training. Being a group new to Scrum and lacking trained or experienced people to fill the Scrum Master and Product Owner roles, we were not offered additional coaching or assistance.
Many classic micromanagement expectations were demanded. There was little regard for the values and principles of the manifesto or the Scrum framework. Violating directives were given and we attempted to comply. Our Sprint Backlog became a cluttered mess. We were wasting time creating and updating unnecessary tasks. Management even sent an email asking why not all members didn't have an In Progress task.
The new parent organization said they wanted us to use Scrum and that they would train us. The onsite training was scheduled without regard for their Operations team's schedule which resulted in many issues. We did not have a Product Owner or Scrum Master, so a new to the company (and industry) Development Manager became the Scrum Master and a tenured Development Manager became the Product Owner; neither was ever properly trained.
The corporate Agile Trainer came to our site and our week long endeavor began. Wanting to fully understand the Scrum framework, I asked a lot of questions and challenged a lot of the statements. There was no mention of The Scrum Guide or the Manifesto for Agile Software Development. Some of the material taught was at least two years outdated. Misrepresentations and falsities were also presented.
The last two days of training, without being expressed prior, became the beginning of our first Sprint. So with many new developers, unfamiliar with our product and new platform vision, we created the foundation of a Product Backlog and sized those items. Having been "trained" we were immediately expected to produce a Minimum Viable Product. Lacking proper Sprint Planning event, we began to create a mess (as in not clean) of code. We "successfully" completed the Sprint and were on to the next Sprint.
During the second Sprint we started to receive requests and concerns from management regarding productivity of employees. You know, the classic 100% utilization ignorance. Being the tenured developer, having experience protecting troops, and not being a "yes man" to management, I fielded those conversations to allow the Development Team to focus on working toward a quality product. I used what little knowledge I had gained from the training and a decent amount I had been learning from independent research to keep management at bay.
During Sprint 3, we began to recognize the issues with have a direct manager as the Scrum Master. He was trying his best, but Scrum Master is a role that should not and can not be conducted using classic management skills. We discussed it as a team and requested that we use one of our Development Team members serve as a Scrum Master starting the next Sprint.
Once we began Sprint 4, things improved. The members of the Development Team were becoming familiar with each other, the processes were improving, there was less concern about Scrum Master role conflict. By the end of Sprint 5 almost everyone was seeing the benefits to the Scrum framework, especially how it could improve our ability to create and deliver quality software.
I discovered The Scrum Guide and began implementing some of the missing pieces. Although I was the most tenured and experienced, I chose not to be the Scrum Master. The irony being that I was certainly filling that role in deed.
Other impediments remained. We had Development Team members who had to split commitments between projects. We hired some more resources including a Product Owner, who was actually a traditional, Taylor, PMI trained Project Manager. Management wanted us to track multiple projects in the same Product and Sprint Backlogs. They began asking about individual productivity again. I quoted The Scrum Guide and the wolves were at bay once again.
At the start of Sprint 7 I believed that at thirteen people, we needed to split into at least two smaller, Scrum recommended, sized Teams with resources dedicated to only one product. A few senior members discussed it and we introduced the topic to management. They agreed that it was a good idea. Our Product Owner suggested that we continue to drive the initiative by drafting a proposal to present to management. Why did we need management approval to be self-organizing?
The proposal was drafted, edited, and approved by the "small council" and sent to the so-called Agile Coach who had "trained" us for comment. He gave some feedback and the proposal was sent to management. Later I realized that this was the trainer's first interaction with the Development Team since training. Being a group new to Scrum and lacking trained or experienced people to fill the Scrum Master and Product Owner roles, we were not offered additional coaching or assistance.
Many classic micromanagement expectations were demanded. There was little regard for the values and principles of the manifesto or the Scrum framework. Violating directives were given and we attempted to comply. Our Sprint Backlog became a cluttered mess. We were wasting time creating and updating unnecessary tasks. Management even sent an email asking why not all members didn't have an In Progress task.
(to be continued . . .)
Comments
Post a Comment