Piloting Agile at Macmillan Science and Education

27 February 2014

Bill Rinko-Gay
Agile Integrity, LLC


At Macmillan Technical Services, a part of Macmillan Science and Education, we have decided to move to Agile development methods. We decided to pilot Scrum with a single development team, and I'd like to share our experience for others who may be looking to start their own pilot Scrum project.

Context

Our scope and schedule were decided for us before this project was chosen. This isn't the best circumstance when it comes to backlog grooming and prioritization. This is because we didn't have the flexibility that a product owner would normally have to ensure that highest-value work is completed first, modifying the backlog when necessary. Still, we were able to pilot the way the Scrum team would work together and organize our work into two-week sprints.

Scrum team

Our Scrum team included a product owner, user experience designer, three developers, and two QA experts. We had one additional person not in a traditional Scrum role, whom we call the solutions architect. He had more technical knowledge than our product owner, so he worked with her to help bridge the business and technical needs. We also included the product manager in our daily Scrum meetings. At first we faced a little difficulty having three people supporting the traditional product owner role, but we were quickly able to settle that with the product owner doing her job and the other two providing input and support.

In addition to our team, we had dependencies on traditional teams that were not piloting Agile. Our product displays digital content. Because of this, we had to work closely with the team that produces this content, and the team responsible for the tools that produce and deploy this content. Since all projects have dependencies, it was good for us to learn how to manage those dependencies in our Scrum team and ensure excellent communication to these other projects.

Kickoff

Before starting our pilot, we had all team members attend a Scrum training day. During that training we reviewed the roles, ceremonies, and artifacts used by Scrum and mapped the additional roles into Scrum roles. We emphasized key issues, such as developing in small increments and giving quick feedback through test and desk checks. We also did a hands-on demonstration of story grooming and story estimation using Planning Poker.

Once training was complete, we began grooming and estimating the initial backlog. We did an exercise to estimate our velocity and then groomed and estimated enough stories to provide three sprints' worth of work.

Self-organizing teams

Our developers had three specific skill sets, each needed for success in our project. This was good for the project, but not good for the kind of flexibility that you really want in a Scrum team. As we progressed, we found developers picking up "their kind of task" next rather than ensuring a story could be completed. This led to multiple stories in flight and delays getting stories to a tester. Overall, this did not create any blockers to achieving the goal of the pilot, but I do believe it inhibited our velocity. It also caused us to carry defects (technical debt) from one sprint into the next.

Our developers had roles within the traditional development team that gave one a leadership title. Fortunately, the training about self-organizing teams took hold. The person with the title led in his area of expertise, but the other team members began leading where they were good. We actually needed three types of leadership: organizing work, integrating work, and achieving technical solutions. Each team member naturally picked up the correct role and the others accepted that role.

I could be tempted to suggest you look for these three types of leadership on your teams, but your work and your team members may be different. I do encourage you to remember that there can be more than one kind of leadership. All kinds do not need to reside in one team member.

Delivering small, testable increments

We had some issues here. Our method for completing work did not allow for rapid release from a developer's local into a testable environment, and our QA experts had never set up a local environment. We discussed giving local environments to QA but tabled that for after the pilot.

Even with the constraints of our release process, we could have made code testable faster, but our developers needed to learn to work in smaller increments. When we started, they tended to merge work into larger tasks rather than breaking it into smaller ones. This is a difficult habit to break. Unfortunately, my development experience is focused on testing, not on coding. I could exhort, but guiding developers through this takes a developer who has been there before. We've engaged someone with this experience to help us going forward.

As a note on this point, training is good, but coaching is important for helping to break some of these habits.

Testing

Our QA experts were mostly trained to work with functionality in bulk. In the beginning, we had lots of discussions about how stories couldn't be tested because the test case prerequisites weren't met. Test cases were being written from preexisting use cases that included the entire functionality of the use case. It took a while for our QA team to learn to focus solely on the functionality delivered with the story. Once they developed this habit, they were able to keep up with story delivery and provide timely, useful feedback to our developers, although we are still evaluating how well they tested.

The QA team members never got to the point where they were automating the testing of the stories as they were being built. This led to regression bugs that we didn't catch before we ended a sprint. Returning to previous sprints dragged down velocity on new development. Once again, technical debt caused us trouble.

Because of our problems making stories testable until the end of the sprint, we had recently opened bugs that we couldn't fix before the sprint ended. We also didn't insist on good acceptance criteria because of our preexisting use cases, which meant there were issues raised in sprint review that should have been caught sooner.

We have a goal of having no open bugs (no accrued technical debt) when a sprint is complete. We still have work to achieve that goal.

Overall

Overall, we met the first objective of the pilot, which was to deliver a set of functionality on time with one Scrum team. Our second objective of piloting Agile had mixed results. We learned several lessons that we will apply as we continue to move to Agile, but we proved several positive outcomes of working with Agile:
  • Collaboration allowed us to catch mistakes early, before they became problems.
  • Biweekly demonstrations kept us on track.
  • Transparency allowed everyone in the company to keep up with how the pilot and the software were progressing.
  • Developers maintained a sustainable pace and had fun doing their work.
  • We integrated with non-Agile teams without losing our ability to remain Agile.

This was a very successful pilot. Hopefully I'll be able to provide an update in the future about a successful Agile transformation.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 5 (2 ratings)

Comments

Karin van Grieken, CSPO, 3/5/2014 8:55:43 AM
Hello Bill. Thank you for sharing your story. While reading it, I was wondering about something. You write that your product displays digital content, which is produced in a traditional team. And that another team produces the tools that are needed. Have you thought about developing your product, including tools ans content, in the Scrum way? In one integrated Scrum team? Would you consider it in the future?

You must Login or Signup to comment.