At one of my recent assignments I was brought in as a Project Manager to assist them with moving applications to the cloud, more specifically to AWS. During the interview process they seemed most interested in my AWS and agile experience. I found out that they were using Visual Studio Team Services (VSTS) to manage their work and code. The Technical Architect and Lead Developer had set up a Scrum board, had a backlog, and were using iterations. They were on the 7th sprint when I joined the team, and I spent most of the sprint just observing. Some of the things I noticed included:
- The Daily Scrum was taking 30 minutes for a team of about 8-12 people, and was more of a verbal status report.
- Sprint Planning lasted 1 to 2 hours and consisted of the Technical Architect pulling in stories or creating them on the fly and then creating tasks. Everyone was pretty disengaged as the Technical Architect furiously put together the sprint backlog.
- The Sprint Review lacked any kind of consistent format and demo’s were not the focus of the meeting.
- There really was no formal retrospective.
- The Product Owner was unfamiliar with their role and spent most of their time telling the team what to do.
- The Product Backlog was a mess, user stories lacked any kind of detail and had no acceptance criteria.
- There was no participation by upper management in the Sprint Reviews, they simply did not show up.
I started making changes during the next sprint, changing things incrementally. A few of the things that I changed included:
- Taking control of the Daily Scrum and limiting the discussion to the three questions:
- What did you accomplish yesterday?
- What are you planing to accomplish today?
- Is there anything impeding your progress?
- We lengthened the Sprint Review to 90 minutes and spent most of that time demonstrating what had been accomplished.
- We held a separate Sprint Retrospective where we focused on what went well, areas we could improve on, and an action plan to address any issues we were having. This was all documented and sent out to the team afterwards, and in an attempt to provide some kind of awareness it was also sent to management.
- We tried variations on Sprint Planning with sessions of 3 to 6 hours. These sessions were not perfect as we continued to pull in too many user stories into the sprints, but we did set sprint goals, aligned our stories to those goals, and did a better job of creating tasks and estimating them.
- I also setup backlog grooming sessions so we could be better prepared for Sprint Planning, however we still lacked the kind of detail we needed in our user stories.
- I started sending out what I called the Agile Tip of the Week linking to some relevant agile topic and included some humorous memes in the emails.
It was evident that the teams that were attempting to use Scrum had no real training, so I setup an introduction to agile and scrum training sessions to provide some initial exposure to the concepts. Most of these sessions had pretty poor attendance, but I did my best to teach the concepts to anyone that did attend.
We had a Product Owner and a Sponsor with no real agile training and little interest in learning more. This was literally agile from the bottom up. Over the course of the next year our methods have matured as we addressed our issues now having more detailed requirements, more collaborative Sprint Planning sessions, shorter Daily Scrums, and much improved Sprint Reviews and Retrospectives. We are now using story point estimating, using the capacity feature in VSTS, and making a real effort to limit what is pulled into a sprint. We have made a lot of progress, but no where as much as we could have if this had been a strategic initiative for the IT division.
We planted that agile seed not knowing if someone will water it and it will sprout, growing into something more. One of the managers I worked with recently attended Scrum Master training, others in the organization have asked to be put on my distribution list for the Agile Tip of the Week. I’m sure someday one of the Directors of Vice Presidents in the IT division will have a brilliant idea and propose we create an initiative to adopt agile for the organization. I don’t think they are close enough to what is going on to understand the cause and effect that you get with something like Scrum, but hope is eternal.
I don’t know that I will be around to see if the seed sprouts and becomes a tree, but I am still proud to have planted it.
I would enjoy your comments and what you think about grass-roots agile initiatives.
The Filter Free PM