CSE 370: Software Engineering Principles

Milton Stutz

Agile Excitement

"It just makes so much sense!" Milton said with excitement as they walked back into the entryway of Solution Point Consulting. He and his coworker, Rebecca Greenwood, had just finished lunch with a friend of theirs from another company that had recently adopted Scrum.

"I love the way they can adjust so quickly to any changes that come up in the project," Rebecca replied. "And because of those daily scrum meetings, it sounds like everyone on the team feels a sense of ownership for the whole project."

Being early in their careers, both Milton and Rebecca were hungry for the rapid changes occurring in software engineering. Not only was the technology advancing quickly, as renewed interest in client-side JavaScript was transforming the Web into a more interactive landscape, but even the processes that engineers followed were also rapidly evolving.

Just one year before, in 2004, Ken Schwaber had published his paper, What is Scrum?, providing a concrete implementation of the Agile Manifesto that was gaining popularity. Milton was now reading Schwaber's new book, Agile Project Management with Scrum, published by the Microsoft Press. Milton was fascinated by these new approaches, especially the stark contrast between them and the traditional Waterfall approach he had always followed.

Everyone knew there were pitfalls with Waterfall, but these new Agile methods, like Extreme Programming seemed almost too risky to try in practice. Could pair programming really improve developer performance enough to compensate for the lost time? Would developers get too distracted if they were all working in the same open space without even a cubical wall? Milton wasn't sure, but he was anxious to find out.

A New Project

Life was generally going well at Solution Point. They had just delivered another product for their longtime customer, The Clear Ocean Publishing Company. Clear Ocean distributed all the environmental regulations that governments around the world used to define their policies. Solution Point had completed several contracts for Clear Ocean, including their latest content authoring system that would allow them to publish updates much more quickly. Like all software projects, it had grown in scope, this one being delayed by about 70% from their initial estimates, but Clear Ocean understood the realities of building custom products and was pleased with the end result.

With the authoring system complete, Solution Point had just signed another contract with Clear Ocean, this time for an update to their client-facing site. The new version would not only add key features like improved searching, browsing, and history, but it would also include an exciting facelift to the UI.

Milton was excited to take on a team lead role for the new project. Along with a few other engineers, he and Rebecca had worked side by side on the last Clear Ocean project, under the direction of Kevin Ogden, the Director of Software Engineering. For the new project, Kevin would still be involved, but he asked Milton to be the technical lead.

"What do you think about using Scrum for our new project?" Milton asked Kevin as he tapped on his office door. "Rebecca and I were just talking with a friend, and it sounds like it's been really successful for their company."

"You're welcome to use any approach you like, as long as you deliver all the requirements on time and on budget," Kevin replied with a smile, as he looked up from his computer.

"I'm not sure that's quite how it works," Milton smiled back. "Every two weeks you look at what's next on the prioritized backlog and choose the features for that next sprint and focus on something we could deliver at the end of that period. I'm not sure we could really promise the exact deliverable for 8 months out."

"Well, I don't think Clear Ocean would be very excited if we told them we weren't sure if we could finish their project on time," Kevin countered.

Kevin wasn't opposed to new ideas, but he had come up through traditional processes. He had been very successful in his career defining detailed requirements documents with clients and then working to fulfill them. Once the projects got going, the requirements were never quite accurate, but Solution Point had historically included enough buffer room into their estimates that they could more or less cover the increased cost of small changes.

On the other hand, there had been two major issues in the authoring system that they couldn't directly account for. First, the authentication system ended up requiring much more interaction with a third-party system than expected. And second, using the new product for Clear Ocean's printed materials proved much more difficult than they expected. In the case of the authentication system, Clear Ocean ultimately agreed to sign a Project Change Request (PCR) to allocate more money for this critical feature.

For the print materials issue, they were fairly disappointed, but ultimately had to scale back their hopes, because they couldn't justify spending any more money on the project. While the initial design and contract mentioned that there would be support for the printed materials, it had not been very well researched or thoroughly planned for by either side, so by the time the team started working on it, they realized it was much more involved than they had expected.

A hybrid approach

Milton and Kevin ultimately agreed to use a hybrid approach for the upcoming project where they would still work toward the original schedule and deliverables, but they would divide the work up into two week milestones for their sprints. Along the way, they would follow the Scrum process for standup meetings, retrospectives, and so forth. Milton was a little concerned that they weren't adopting the complete Scrum process as Schwaber and others had defined it, but he felt like it was a step in the right direction.

The Scrum Begins

Anticipation filled the room as the team began their first standup meeting. The whole process was new for Solution Point, and it brought curiosity and excitement. Each person stood around a large circular table they had in an empty office as Rebecca, who had been chosen as the Scrum Master, started the meeting.

"I suppose today will be a little bit different since we're just starting the project, but let's each give our updates one at a time and go around the room," she said.

Each person followed in turn, talking about what they were planning to work on that day, and the meeting ended 7 minutes later. Milton and Rebecca were both pleased with the team's attitude and the progress they felt they were making. Kevin was also happy to see the team working so well together. Even though he wasn't directly involved with coding on this project, as the director of software engineering, he wanted to stay connected to the work they were doing.

The second day continued in much the same way. Everyone had been a little optimistic about their goals for the first day, so they were still working on the same general features, but they were learning to break them up into smaller tasks.

"I'm continuing my work on the topical search feature," Milton reported. "Today, I'm hoping to simply get the table of contents to show up on the search screen."

The others shared their updates in a similar fashion. One of the engineers mentioned being a little stuck on where to go next with the new UI transitions, and Rebecca agreed to help him after the meeting. Milton was excited to see collaboration emerging more naturally on the team. Their separate workspaces historically kept the team from reaching out for help until later in the process, so early communication like this was a huge win.

As the days went on, however, the standup meetings lost their novelty and excitement. Kevin, who had begun sitting at the table instead of standing like the others, started to take a more dominant role. As each person would give their update, he would ask some follow up questions to make sure he understood where everything was at.

The Second Sprint

The first sprint finished without too many hiccups. Only two weeks into the project, the team was still getting started on most of the features, but they had met their overall milestone goals. Milton and Rebecca still longed for a more complete Scrum experience, but they were happy to see the team working so closely together.

Perhaps surprisingly, Kevin was the person most excited with the new approach. He loved getting a daily status report from every member of the team. His excitement, however, had the opposite effect on the team. Rather than a peer-to-peer sharing exercise, the standup meeting had become more of a reporting-to-the-manager process. Because of the shift in focus, each person began to be a little more reserved in their plans, not wanting to mention any problems they were facing until they had solved them, and not wanting to commit to anything they weren't certain they could accomplish.

Unlike the first sprint, the second had a more defined deliverable. The team was supposed to have a prototype system in place, where the client could log in and follow basic site navigation. While everyone on the team was making good progress in the separate areas in which they were each working, none of these features was quite ready for a prototype release.

On the one hand Milton was concerned about their lack of the deliverable, because he knew that both Kevin and the client would be disappointed and feel the project was getting behind schedule. On the other hand, he could see the good work being made in many areas of the project. In fact, on the whole, Milton actually felt like they were ahead of the overall schedule, but unfortunately they didn't have a release to show as planned.

"I'm a little confused," Milton said to Rebecca as the two stayed for a minute after a standup meeting one day. "Wasn't the move to an agile process supposed to produce working code all along the way, and actually give us lots of incremental, deployed updates? Where did we go wrong here?"