Working with a web development company using Scrum

I am sure it would not come as a surprise, but our website (www.scrum.org) needs a major refresh. The current implementation has become out of date and less and less supportive of our vision and mission. As a team, we quickly realized that we do not possess the resources needed to take on a full website development effort in a timely fashion and that we’d need some outside help. This blog post is the first in a series that will document our adventure partnering with an outside company to build our website using Scrum, and the surprises we’ve encountered along the way.

To work with Scrum.org you MUST use Scrum.

Of course, it would be unimaginable for  Scrum.org not to “eat its own dog food” (drink its own champaign), or “practice what it preaches”. But our desire to use Scrum is so much more than marketing, it is our fundamental belief that Scrum enables us to deliver software that is both better and more Agile. And, as Scrum is now practiced by thousands of companies every day, you would think that the requirement of using Scrum would be an easy one for most web companies to follow.

Sadly, you would be wrong. Scrum is the most popular Agile framework, and -yes- is practiced by thousands of organizations but the majority of the web development companies we spoke to:-

• Liked Scrum – and saw its value, but…
• Wanted to use a modified and more traditional partnering approach that was more like water-scrum-fall in structure and values.

The idea that you could, after a minimum amount of prep work move into an iterative and incremental delivery model with cross-functional teams working closely with a Product Owner seemed to be beyond most of these companies. When challenged on why they could not follow this model they responded: -

1. Our customers like a good estimate up front which requires us to build out a detailed view of all the requirements.
2. A holistic approach to design really means we need to spend quite some time building out detailed wireframes and Information Architecture before we can build anything.
3. To keep a team together would be VERY expensive – and you might not have the most skilled people for your situation.
4. We prefer documentation over a Product Owner – after all, there is more than one stakeholder.
5. We find it best to manage change using a formal process – makes sure that both parties are happy and informed.
6. We will deliver frequently, but would rather do it on our infrastructure that we use to demo to you. After all, you don’t want to have to deal with bugs and stuff.

So, they liked Scrum but wanted everything up front, formal change management, and very detailed, documented requirements. And, when it came to delivery, they would go off and create website assets that they would demonstrate on their timeline.  From my experience, this means that after a large number of meetings, teams would go dark for long periods of time, and then would demo something that really did not deliver on my actual needs, but did deliver to the requirements.

This did not sound like Scrum to me.

And we wanted to go one step further. Not only did we want to use Scrum we wanted to both provide a Product Owner and embed a development person from Scrum.org in the team. This approach was VERY different from anything these web agencies had experienced. They all saw Scrum.org as the distant client who was going to receive work from them, not as an active participant in the process. But we all know that this approach is likely to fail, costing more time and effort as we, as a team, navigate unknowns, manage integrations and introduce opportunities, even if those are not covered through the upfront fixed requirements. The reality is that the only way to manage this risk is to have a team that includes not only all technical skills, but also the right business background, and some of those people are from Scrum.org.  

Using Scrum is good for both parties.

One of the biggest reasons why Agile and Scrum have become popular is that by frequently delivering software you reduce risk. The business/customer sees real progress and makes decisions based on working software. No paper reports updated Gantt charts or Powerpoints. And, the Development Team does not waste time building features the customer, in the end, does not want (anymore). Scrum is an elegant way to ensure transparency and accountability in frequent bursts of focused activity. So why was it so hard for a web development company to adopt this model?

It seems that it all boils down to trust. Many of the web agencies we spoke to did not trust that Scrum.org would support this transparent delivery approach, and would not be willing to talk through the budgetary impact of changes. Yes, we said we would, but when push comes to shove history has led us to believe that the exposure of problems, unknowns, and risks will mean we, the client would be disappointed and stop the project or demand more than what was budgeted. After all, the standard approach to web development is to hook the client – build something and then get the next phase which would be all about finally building the right project, based on the experience of the first delivery which never really worked. And, if done correctly, a web project will keep both parties involved at least twice as long as the initial estimates because of documented changes and environmental issues.

By the way, web companies are not evil – and not trying to extract extra money from the clients, but instead have accepted that customers don’t understand what it takes to build a well designed and working website and that no customer wants to see the messy reality of building software. They also often assign their people to multiple projects to spread costs across these projects and become more profitable through maximized utilization. Having a dedicated Scrum Team would cause many team members to have to focus on a single project, impacting profitability.

So the reality is that everyone accepts this traditional model in the false belief that it protects both parties.  The client knows that they do not know everything up front, but pretends that they can write everything down and that will protect them from ‘scope creep’.  The vendor expects that phase one will not deliver what the client wants but will deliver on the agreed requirements, regardless of changing realities, thus getting them set up for phase two.  And that the tension and surprises on the project are the normal reality for web projects.

But there is a better way.

In Blue Coda, a web development agency from Cambridge MA, we have found a partner that can work in our envisioned, collaborative and transparent, way. Here are the key areas that will make it a different web project:

• Instead of the usual 2 months and 20 odd meetings we have condensed the preparation work to 2 weeks ensuring that we are sticking to the principle ‘what is the minimum we need to know up front before we can move to deliver working software’. And the other stuff is sprinkled into the Sprints.
• We are setting up dedicated Scrum Teams – instead of paying by the hour, we have contracted a Scrum Team at $X to work in two-week sprints. This removes any complexity from the cost model, but also allows us to start getting feedback on velocity and scope.
• We have a dedicated Product Owner from Scrum.org – Yes, not a surprise but instead of expecting the web development company to ‘get us’ and only working with them when we have to, we have a dedicated person working with the team on a regular basis.
• We have a shared staging environment – Now, the technology we are using makes this a bit easier and our friends at Amazon Web Services help, but from day one we have a shared staging area that both companies can see.
• Working software is the primary measure of progress – Yes, we do capture stories and other requirements in a Product Backlog, and -yes- we report progress on these, but the real measure, the one we care about is the actual working software on the staging area.
• We use Scrum – We use the events, roles, and activities to ensure progress and have NOT built out a set of additional processes to ensure status, risk, and change are managed. The Product Backlog and the Sprint Planning, Daily Scrum, Sprint Review, and Retrospective events provide both companies with the material and feedback to measure the progress and ultimate success of the project.
• And the contract supports this – No, we did not include wording in the contract around status or failure. Yes, we said we can stop a sprint and for BlueCoda’s stability we commit to 2 or 3 sprints at a time, but that is all. We described Scrum in the contract and avoided the traditional CYA language.