by Laura Timmis
Director of Program Management
The majority of businesses want to go faster. This may be driven by a lack of internal capacity or the inability to decide exactly what the product needs to dominate the market, but there is a refrain of wanting to get there first.
Here are five things we’ve learned about going fast while trying to help clients do the same. Consider these lessons learned from the field.
1. Pick All the Tools and Get Going
A client recently needed a proof of concept for a multi-year project to replace a key piece of software in its universe. We had three months to build the POC, which would be a vertical slice of functionality to prove out services, infrastructure, and the UI to display results and allow user controls.
On the day we kicked off the project, the client had already chosen all the technology tools we would use -- including our key communication tool -- and had the licenses available for the whole team. The most wonderful thing happened: the team was able to stand up environments and write code within days of the kickoff. This removed all the debate about what tools to use and why that normally happens when a team first forms. There was no debate to slow us down from starting to build.
During the course of the engagement, we learned that some of the chosen tools may not have been the best. We documented what the issues were and why, and offered alternatives that could be investigated and utilized before the bigger project begins.
The debate – if there is any – can now take place in a time and space that isn’t impacting the launch of useful software.
If you don’t have a list of tools, we can offer some examples of what we’ve used, depending on the environment.
2. Be Ruthless about MVP
Every product owner dreams of a full-featured product that launches to the world and is a raving success. But a full-featured product takes a really long time to build – potentially so long that you miss your window of opportunity.
The best advice is to be ruthless about defining an MVP and get it out to the world. You really can build software iteratively and continue to build on the initial set of functionality. It’s not the end.
If you launch more quickly, you also have the advantage of building more features based on actual user feedback. This is invaluable information when you are trying to decide what comes next.
3. Nimble Backlog
We often don’t have the luxury of starting product development with a healthy backlog of user stories. For the first few weeks, you have to live in the uncomfortable space of building a backlog at the same time you’re building the product.
Write the first key stories and get them to the development team members during sprint 0 so they can get started. If you do five stories and then try to groom them, you will eliminate a lot of waste by getting feedback from your designers, developers and quality assurance team; they will share the level of detail required to complete software from the user stories.
We recommend that the user story articulate a small-enough or partial feature that can be built in under a week. We utilize the standard user story guidelines, but find that acceptance criteria are the most challenging things for new product owners to get good at writing. We have coached many new product owners in their climbs to mastery of this skill.
4. Overhead is a Killer
We’ve used Kanban for these “go fast” projects so we can respond to the lack of backlog quickly. This allows us to avoid overburdening the team with ceremonies.
Don’t worry about your velocity for the first few weeks. Instead, focus on getting code written and tested. Have the development and QA teams track time so you can determine how much you can build in a given period.
If you want to practice Scrum with all of the ceremonies, it will take time to get the team comfortable with the interactions, expectations and to start to work together in a more seamless way. The more lightweight and, yes, agile, the process is, the better off you are going to be.
We can either build product fast or we can work on refining process. The choice is usually pretty easy to make.
If you have a small team of four or fewer people and they all know how the process works, don’t worry about perfection of process. They usually know when they need to communicate and what they need from each other. A daily stand-up goes a long way to uncovering things that need longer discussions. Encourage the team to call out things as blockers if they are preventing team members from moving with speed.
5. Be Agile
To go fast, responding to changing stimuli is a must. You have to be willing to change course for the good of getting to market.
If your favorite feature is going to take weeks to build, you have to weigh the benefit of launching without it vs. the benefit of waiting for it to be completed. If there’s a way to break it down and offer a basic version, this may be the best answer. Then, you can get feedback from users on the most beneficial bells and whistles.
These are a few of the ways that projekt202 has found to work fast and to help our clients get to market quickly. Our methodology helps us adapt quickly to changing conditions.
projekt202 is the leader in experience-driven software design and development. We are passionate about improving the experiences that people have with enterprise and consumer digital touchpoints.