Building a product is not easy, and to keep growing, is even harder! However, coders all over the world have been using a strategy to help them keep up with constantly changing requirements, and the same principles can be applied to (almost) any business!
The secret behind the speed and efficiency of many teams in development is called "Agile", which in itself doesn't mean much. It can be summarised as a "mindset". A mindset to break down problems, prioritize work, and constantly deliver results. Sounds great, doesn't it? But how do we put it into practice in a retail/business environment?
This simply means that as a team we'll decide a time frame where we plan to deliver something. In development, this is typically 2 or 3 weeks. Then, every piece of work has to be achievable within that time frame. So let's assume we decided our time frame will be 2 weeks, and we want to launch a new product line. If launching the product line takes more than 2 weeks, then we need to break down the piece of work, so that we have tasks that fit into 2 weeks. Simple enough no?
You've just launched your online shop, but sales are not happening. You investigate and find out that the users are finding it hard to navigate your online store. Within the Agile mindset that is a reason to celebrate (within reason) because you've just found out a way to improve.
In Agile this kind of mishap is not seen as a failure, but an opportunity to be better.
Ever wondered why face-to-face conversations seem to achieve more? It's simple human behavior that Agile appreciates. Face-to-face communication enables us to understand better what the rest of the team is saying, we can read body language, and so much more. Through technology, adopting this has gotten even easier, we can video call each other, and it's as if we're all in the same room even if we're on different continents.
In sales there is a similar saying "Always be closing", the same applies here. Don't get held up in producing something perfect, if it works launch it, gather feedback, and improve. Now, before we get ahead of ourselves, I understand that if we're developing a physical product we don't have the luxury of just "releasing" it, and then fix it. In such cases, Agile encourages us to bring the various prototypes in front of a focus group, and iterate within this small circle. Once, we have a product our circle is happy with, we can launch. We still gather feedback and then release an even better product in the next iteration.
How many sleepless nights did you have to go through because you didn't know if you were going to make that month's rent? Just waiting and hoping for the next sale to come in. Wouldn't it have been better if you were somehow guaranteed that at least 1 sale would happen every day? This is what Agile promotes. Instead of burning out, to try to meet a crazy deadline, and then failing every other deadline after that, Agile suggests setting more realistic deadlines so that we can deliver on our promises, every time. It's better to promise less and deliver that every day, rather than promising a lot and never delivering.
In Agile, specifically in something called SCRUM (a topic for another day) exists a very powerful concept; A self-managing team. A self-managing team is almost impossible to achieve by most but that doesn't stop us from trying, so what does it mean exactly? It simply means that there is no single person that takes decisions, all decisions are taken collectively. More importantly, this also means that everyone in the team should be able to perform all roles within that team. So let's take a beauty salon as an example; There is a hairdresser, a barber, and a nail technician. In an agile team, these 3 people should have at least basic knowledge of each other's jobs so that if one of them is not present, the others can step in.
We've covered the basics of Agile, and its guidelines seem like something that would improve our business, so what's next, where do we start?
The best place to start is by setting up a "team huddle". Think of this as a very casual general meeting with all your team members. It should be the furthest thing from a formal meeting. Have drinks, snacks... it's important. This will be a very long meeting. From this team huddle, you should extract 2 things;
It's very important to encourage discussion during this meeting, whatever you commit to here is going to stick with you "forever".
A sprint is a terminology used in Agile which describes an iteration, so after the “team huddle”, each team should present what they will be committing to in the upcoming iteration (sprint). Things such as "30% progress", "Build half a shelf", etc. are unacceptable. We need to be delivering some working and of value. So, encourage objectives such as; "Release a design", "Build a cabinet", "Design the floorplan"... It’s perfectly fine for an iteration not to produce a marketable product, however, it should produce something tangible and measurable.
Our goal is to launch a new perfume.
In sprint 1, we could set the goal of; Perform market research, and we set clear criteria of what research we’re after. Things such as; Competing price range, Top 5 sellers in the space…
In sprint 2, a goal could be; Design the formulation, and our criteria would be to have a formula that we could send in for review.
By sprint 10, we might reach our higher-level goal of launching the perfume. However, now we have a clear plan that everyone can commit to, and we minimize surprises.
The process of planning a sprint is known as sprint planning.
Once the first sprint is over, take a look at what did the team achieve. Chances are you either under/over-promised. That is ok because now it's time to adapt. Based on the results we achieved from the first sprint, the team will now make more educated guesses as to what they can achieve in one sprint. Remember, the goal is to learn, so if in your first sprint you were extremely off with your estimates, don’t panic. Adjust the plan of the upcoming sprint accordingly.
This concept of looking back at the previous sprint is known as a retrospective.
Agile discourages distinct roles. So it's up to you how you position yourself in the team. In most startups the business leaders tend to take the position of "Product Owners", whilst managers tend to take on the roles of "Scrum Master" (if adopting SCRUM). However, this is not set in stone. Your main responsibility as the business owner in an Agile team is that no one is ever left behind and that everyone is pulling equal weight.
Either if you're a startup or a Fortune 500 company, Agile might help you optimize your operation. So if you're stuck between a rock, and a hard place, with your current team, give it a try, and let us know how it went in the comments below.
Written by Dylan Grech, founder of Lifeboat.app
Dylan has spent more than 10 years working in various agile teams, fulfilling all SCRUM roles.