Scrum is a method that implements “agile” in much detail. Scrum tells you to specify new features for your software application in “user stories”, and implement those user stories in sprints. In the original book on Scrum written by Ken Schwaber and Mike Beedle, they suggest one month sprints. Today, what I see in companies is two week sprints.
Small user stories and sprints work brillantly in an environment where your goal is to add new features to an existing application. You talk to users, they tell you what features they want most, you and your team implement those features, and within weeks users see their new features in the application they use. I see this work at companies I work for. There are a few requirements:
- Scrum mentions a product owner. As this is the person in charge, rather than the person who has the knowledge, you need to get users involved
- you need to have your continuous delivery in place
- Scrum doesn’t provide a good way to guarantee thorough acceptence tests. You need to implement thorough user testing in or before your continuous delivery environment
But how does Scrum work when you build a new large application? This can be either a brand new application, or replacement of an old application. Think of it. You start the project, you have meetings on the over all architecture, on the frameworks you want to use, on the general philosophy of the GUI, and more. Scrum says you need to deliver your first feature after the first sprint. Even if you set sprint duration to one month, this is not a realistic goal. Scrum tells you to use the metaphore of the “minimum viable product”. But tell me, what parts of a skateboard or a bike can you re-use when you build the car?
Building a brand new application in an agile way requires a different approach. You want to achieve two things:
- build the application in minimum time with maximum quality
- deliver results to users in record time
Often, in projects in which new applications are created, someone writes down the specifications, someone creates wireframes, someone creates an architecture, and someone does the implementation. “Someone” as in a person, or a team. This is done more or less sequentially. First, functional specifications are created, then architecture is figured out, then usability is added. Non-functional requirements are mostly ignored in Scrum. I propose a different approach.
My ideal project has a programmer, a user, a designer, a devop and others doing pair programming from day one. Rather than developing features in much detail one by one, they develop a bunch of features, or even all features, detailing them while working on them. After a month, they have part of the application, with rough edges, big holes in it, some features stubbed, a database that needs more work, a GUI that shows you a glimpse of what the system will be like. Everything is built leaving out details, it’s all aimed at reaching a consensus of how the system should work and what it should look like. I don’t do sprints in such a project. I wait for the team to say “hey guys, this is something that makes sense, let’s show it to the world”. It doesn’t matter if this happens after two weeks or after three months.
For a programmer, it is gratifying to work on source code while right next to you, a user is testing the code that you are building. The user gives feedback while you’re still optimizing your code. Better still, have a front-end developer and a backend-developer in the loop, with the user. The three of you work hard, programming and testing, while talking to each other. If next to a web-based application you also build an app, let the app developers join in. Let devops join. Of course, this rapid prototyping approach requires that every once in a while, you need to sit back, look at what you have created from a distance, and ask yourselves “does this make sense?”. You need to plan periods of time in which you evaluate and process the comments of a broad group of users who have been trying out your last published version. You may want to replace users in your team frequently, in order to get more users involved.
Working this way, there is no focus on “should this button be 72 pix wide, or 76?”, as sometimes happens in Scrum projects. The focus is on overall functionality and usability. You program it to be easily changable. Your team is not static, it changes in the course of time. You need a marketing and communications person at the start, but not during development, and yes, you do need one near the end of the project. You don’t need a finance person all the time, but you do need one to monitor future costs: can we afford to maintain this application for the next ten years, or do we need to simplify it to reduce maintenance cost?
In a project like this, there are no formal meetings. That is, your project in itself is the meeting. You don’t need a product owner: everybody in your team is a product owner. You don’t need a scrum master: the team is the scrum master.
From the projects I have done this way, my experience is that you achieve higher quality at lower cost in a shorter period of time than in a more conventional project or even in a Scrum project. What’s most important to me is that employee well-being gets a boost in these projects. Whenever I meet former team members, they say “remember when we ..” and they smile. I keep them close to me because working with smart people who are happy gets the work done fast. And it keeps you happy.
“Agile Development with Scrum”, Ken Schwaber and Mike Beedle, 2001
“In search of excellence”, Tom Peters and Robert H. Waterman Jr, 1982
“The knowledge creating company”, Ikujiro Nonaka and Hirotaka Takeuchi, 1995