It’s not easy to get along in todays fast paced online world if you are looking at the world with yesteryears tools in your hands. Who wants to get the most out of their time should adapt to what works best, at least, if you would ask me. I outline some basics about how we work at aFrogleap, and how I think it beats the traditional waterfall approach that some clients are still used to. I’ll outline a bit of context first by giving a short overview of what Agile and Scrum are before sharing a bit of personal experiences.
Agile in short
Let’s start with Agile. In the basics it comes down to four core values of Agile development for enabling high-performing teams:
- Individuals and their interactions
- Delivering working software
- Customer collaboration
- Responding to change
These core-values are supported by 12 principles, as outlined in the Manifesto for Agile Software Development.
You might hear a lot of Agile and Scrum around when you are in software development, but what does it mean? Agile is actually a collection of methods to organise development projects. Scrum is one out of the various choices at hand. The method has gained considerable popularity over the past decade. In short, scrum is an open framework with a few basic roles, attributes and activities:
- A product owner creates a prioritised wish list called a product backlog.
- During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
- The team has a certain amount of time — a sprint (usually two weeks) — to complete its work, but it meets each day to assess its progress (daily standup).
- Along the way, the Scrum master keeps the team focused on its goal.
- At the end of the sprint, the work should be potentially shippable: upload to the app store or show to a stakeholder.
- The sprint ends with a sprint review and retrospective.
- As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.
Ever since I am in the mobile domain, regardless of the companies I worked for, we always used some of the scrum principles. There is no single best way to ‘do Scrum’, it’s putting the principles into practice that make the teams successful.
Why not Waterfall?
When I started my career fresh out of college, I wanted to learn more about project management. Friends told me that the dominant project management process was PRINCE II, so that was what I dove into. It didn’t take me long to realise that PRINCE II didn’t work well in the new-media world, as there is always something unforeseen that changes throughout the project which changes the scope and planning of what you are trying to accomplish. Scrum is more resilient to such changes, because of the continuous development, rather than ending of the project. At the end of every sprint your development team delivers a new version, rather than working for 6 months straight on a project. The client still needs to know what (s)he wants to accomplish. The client needs to be involved in the project. The end result will be more likely tailored to the actual needs of the client and, quite importantly, to the needs of the actual person that will be using the software created.
I am not saying waterfall is bad. Waterfall, or any heavy weight-formal kind of method, works very well for projects with a fixed scope and fixed price and where the client is certain that there won’t be any rapid changes in the scope.
Stuff I like about scrum
I like the short iterations loops in scrum. Especially during projects that have multiple sprints, you can see a development team grow, and improve their performance. Scrum is a lot about reaching consensus through conversation. A product owner should know what should be build, and the development team puts their effort in building it in the best way. This feeling of working on a project as a team makes work great fun, not just for me, but also for a client who really has a hand in what is being made, and gains a thorough understanding why a user story might be hard or easy to build.
Also, while it gives a secure feeling to know what you will be building in full detail, it can get frustrating when you are working according to a plan that feels outdated by the new insights gained, or makes no sense due to scenarios that have not been thought out before beginning. This comes together with delays in delivery and a lot of unnecessary stress. Scrum works the other way around: you commit to finish certain stories before the end of a sprint in such a way that you can make them available to the end-user. A client decides what should be made, while the development team decides how this is made best. At the end of a sprint the product is finished. It might be that the client would like to extend on the functionality that might seem limited at first. After iterating the product will improve until the client feels it’s ready for a release. This way the client continues until the product is done, the budget is spent, or the time is up.