The first corporate impediment was lack of planning. Our onsite training was scheduled without regard for the Development Operations team's schedule. Therefore they rushed to create and configure our TFS instance. This led to users not being able to connect, missing users, users who should not have been users, workflow issues, and a poorly constructed source tree.
We did not have a dedicated Product Owner or Scrum Master. (At the time I didn't know what those were.) So we used a new to the company (and industry) Development Manager as the Scrum Master and a tenured Development Manager as the Product Owner. Later we learned why this was bad.
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. Some of the material taught was about 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 stories.
Having been trained we were immediately expected to produce a Minimum Viable Product. Lacking proper preparation or even a Planning Meeting, 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 producing 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 Team members 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.
Of course things weren't clear sailing. We had Team members who had to split commitments between projects. We hired some more resources including a Product Owner, who was actually a classically PMI trained Project Manager. Yet another failure from the "agile" mentors above. 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 hadn't the so-called Agile Coach seen this and made preparations or initiated the conversation? 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 Agile Coach for comment. He gave some feedback and was also happy that we were discussing splitting into multiple teams. 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.
About this time the requests began again to have every Development Team member have his/her name on a task at all times. I expressed the same concerns that we had before, I quoted The Scrum Guide, I asked for reasoning as to why this was important, I expressed the Team's concerns about micromanagement. The was a lot of illogical or irrelevant "reasons" and "we're not using this for evaluation" talk. There were even a few Scrum incorrect statements made by the Agile Coach.
In the end, during Sprint 8, the violating directive was given and we have been attempting to comply. Our Sprint Backlog quickly 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. I have submitted a direct query to the Agile Coach as to how this is not a direct violation of The Scrum Guide.
What happened to the proposal? It was still being considered. Some managers could/would not resource plan, didn't seem to accept the single product focus objective, and wouldn't commit to staffing. We are requesting feedback and approval again.
Management has failed. They have failed to adapt to the Agile philosophy, especially the Scrum framework. They have failed to be the ones foreseeing and addressing challenges. They have failed to coach and empower. This is why, unless things change, TR will be another failed Agile implementation and be just another ScrumBut.
- Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
- Development Teams are structured and empowered by the organization to organize and manage their own work.
- The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team
