I am excited to share with you one of my personally tested ways of failing a product delivery.
One important aspect worth mentioning first: we’re following a Khanban-ish process. So no iterations. Just a backlog from where we prioritize and draw items in progress.
- You are about to start a new project. Start the discussions around what you want to accomplish.
- Together with the client you set a release date so that you are both comfortable with.
- Make a prototype using the desired framework to see if it fits the project’s needs. It does, great. Move to the next steps.
- Ask for the designs, but they’re not done yet. It’s ok, you’ll estimate the designs based on the old app and you’ll start with the backend work.
- Write the user stories. Allow the Product Owner to enter the minimal amount of details on it, so you know what feature to implement, but leave out the corner cases and the details.
- Estimate all the stories. Make sure you leave 1-2 weeks for potential bug fixing.
- Great! Start development. So far, nothing would predict the disaster..well, maybe step 4 😉
- Go through the stories, and integrate them one by one on the big feature branch
- Make local decisions on the new discovered use cases encountered during development.
- Don’t test the features as they are implemented, just integrate them in the feature branch and start the next one.
- Don’t discuss the design implementation details with the client. Assume the changes will come when testing anyway, why lose time now?
- Don’t write test cases.
- Yay, features are implemented.! Start testing the new app. The deadline is starting to approach, so hurry up with the testing.
- Test without test cases, so just go through random use cases that you can think of for each story.
- Hmm….the client realizes a certain part of the app doesn’t really work as he would want to. Pretty big issue that we need to fix before release…
- The client becomes a little anxious and start taking a closer look at the app.
- Now everybody is testing the app. The important issues start to appear.
- Spend the evening at work trying to fix the most critical issues.
- Realize you won’t be able to fix and properly test everything before release, which is in 3 days.
- Agree with the client to postpone the release a few days.
- Spend the next evenings at work thinking how to add fixes that affects the rest of the app as little as possible.
- Testing the fixes reveal 3 more important bugs.
- With all the nights spent at work in the last week, the release date still needs to be pushed even more.
- Finally release the app, 2 weeks later, with lots of hot fixes and hacks.
- A pretty unstable app with lots of hacks and technical debt.
- A very tired and frustrated team
- A frustrated client
- A considerably lower degree of trust from the client
What to learn from this?
- Communication!!!! Discuss about all aspects of the app. Every day, all work needs to be discussed, and agreed on with the product owner. Every message text, edge case, color. Don’t assume anything. Or, assume, but also, confirm with the client. I can’t stress this enough.
- Write test cases in parallel with the development. They need to be created every day, after each discussion with the client. After the development is ready, everybody knows what to test.
- Make sure the stories have all the use cases described in them.
- Start testing as early as possible. The problems will be discovered and addresses in a timely manner.
- Follow the test cases when testing.
- Have the design team look over the build on each feature implemented. Discuss and negotiate all the technically challenged design items so you don’t waste precious time on expendable features.