Whenever I’m talking to prospective clients who are looking to build a website or mobile app, the serious ones come armed with a list of questions for me. It’s a checklist to make sure New Haircut is up for the job. These are my favs. They’re taking this seriously. +1 for them.
And on that list, more and more, is a fumbled question about Agile web development.
Typically the discussion goes something like this…
Biz person needing website: Talk to me about, uh, how your code is Agile.
Me: Well, our code isn’t really Agile. I think you’re asking if we follow Agile web development principles to build websites?
Biz person needing website: Right, right … EXACTLY!
Maybe you scanned an article littered with “Agile web development”. The author and everyone in the deluge of comments seem emphatic about the importance of websites being built utilizing Agile. And they’re right – it’s the right way to work on digital stuff. But it doesn’t mean you need to go out and become a Scrum Master overnight. You just need to grasp the basics so you understand why it’s good for you and your web project. Let’s give you a head start.
First, Agile is not a thing. It’s a way of working. Agile web development, (related websites and mobile apps), refers to a certain umbrella of methodologies that implies an iterative approach to building and releasing software. A by-product of Agile is Lean Development of Minimum Viable Products (MVPs), which is extremely popular within tech startups. Get involved in Lean Startup Machine for a first-hand experience. Or if you’re in NYC or Boston, attend an Ultra Light Startups event.
Then, there are specific religions and practices within the Agile web development community; e.g. Scrum, Kanban, XP, Test-Driven Development (TDD). The common thread here is that Agile touts early and often release of working software. In fact, most developers or agencies will explain that they take bits and pieces of various Agile disciplines and create a custom version of Agile that works best for them and their clients.
Agile Web Development Industry Jargon
- User Stories: The customer requirements of the features that make up the product. They follow the format – “As a <role>, I want to <goal>”; e.g. “As a shopper, I want to search for sneakers by color.” Lots of User Stories make up an Epic.
- Sprints: Timelines within Agile are managed within “Sprints“. A Sprint is simply a time period – typically 2 weeks long (not always). Less than 1 week doesn’t make much sense. More than 4 is simply not Agile. Sprints contain User Stories.
- Release: A Release is comprised of 1+ Sprints which contain all of the User Stories to deliver your working product on a set date.
- Backlog: All of the User Stories that are not being worked on in your current Release/Sprint, are in the Backlog. The User Stories with the highest priority in the Backlog will be worked on next.
- Burndown: A visual representation to show the progress the team is making as they work their way through the User Stories, toward the end of the Sprint/Release.
- Product Owner or Stakeholder: You. This means you need to be actively involved, at least in the early stages. A good agency will have someone on your project team (Account Owner, Business Consultant, etc) pick your brain, spend time researching your industry and then act as your proxy so you can focus on your business.
- Stand-up Meetings: The project team meets every day for 15 minutes to discuss (1) accomplishments from yesterday, (2) stuff they’re doing today, (3) problems stopping them from getting that stuff done.
- Scrum Masters: Think of them as project coordinators. They organize the stand-ups, work with The Product Owner to pore over the Backlog, rank User Stories (easy, medium, difficult) and then agree upon how many can be accomplished within a Sprint/Release.
Why Does Agile Development Work Better?
In order to answer why Agile is better, you should understand what it’s better than. A stark alternative to Agile is dubbed ‘Waterfall’. With Waterfall, you spend (lots of) time upfront documenting what you think the product should do. Then you design, develop and test in siloed phases. Any changes to scope need to pass through a change management process, and then cycle through design, development and testing, again. Change is seen as bad. Product/Project Managers do their best to ‘stick to the plan’, even if it becomes apparent that product being built is not what the market is demanding. Changes that are implemented are often carried out too late in the proces, making them expensive to address. Waterfall works for building a house, where you follow a blueprint. For software, not so much.
Agile web development, on the other hand, consistently ensures that the project team is on-time/budget and not veering off-course within product design. If they are going down the wrong path, it can be spotted and corrected quickly, before it becomes exponentially more expensive to fix; e.g. once the product is already being used by paying customers.
Agile development, unlike Waterfall, embraces change as part of the process – in the world of digital, whatever you’re discussing ‘today’ will undoubtedly change as soon as design and development begin. Once things are visualized and you’re interacting with functional screens, the team will have new insights. What was once the scope and agreed upon UI/UX, now seems inappropriate. But because your’e working iteratively, you can quickly obtain feedback from users and adjust within an upcoming Sprint.
I’ll make this short – Agile for website and mobile app development is the way to go. It’s good, it’s good.
If you’ve got a decent grip on the tenets of this article, you should be able to have a decent discussion with a developer about how they employ Agile web development principles to build website and mobile apps. And if you talk to one you’re still not sure, ask me (seriously). I enjoy nothing more than exposing crap for what it is.