In the last four parts of this series we focused on:
These four recipe ingredients create the main dish and allow for a wonderful meal. This article enables experimentation and with all experimentation, it can either cause things to surpass the original recipe or be bound for the dumpster. Skirting this fine line is a skill that is very important for any development team.
If the four ingredients above are so important, why would we ever bend the rules? With a new product or a new feature the answer is almost always we need to be faster to market. This is a very valid point of view and one that should be understood as to what it could mean.
"We need to be faster to market"
Why do we need to get to market faster? There can be many reasons. Finding the root reason will help you decide if it is the right decision and if it is, how to best execute that need.
For example, one root reason may be because no one else has this idea and we could be first to market. This is a super enticing prospect, and one that has probably driven many many development teams to move faster. But is being first always the best? I will give a couple of examples.
In the early days of VR for the home market SEGA announced that it was going to be developing a headset for their system of the time. They eventually dropped this as a failed attempt. But Nintendo didn’t know that was going to be the outcome. So they got to market first and put out a product called Virtual Boy. It was awful, and didn't fill any user need or want at the time. It ended up being a huge failure for them.
As a second example, when the digital music player market started to take off, there were many many commercial products that came out, some fairly successful. But the one that ended up dominating was the one that sat back and watched and gathered information about the market that eventually one the day, Apple’s iPod.
On the other hand there could be legitimate reasons to try and move faster. For example, one root reason may be financial. “We need to realize an income stream to offset the cost of development as soon as possible.” Again, if we can somehow mitigate this we might make more if we move slower, but sometimes there aren’t any ways to mitigate the issue.
If we need to move faster, where do we bend the rules? To know that you need to understand who the audience is and what the outcome is for the company. Is it to be an innovator? If so, cutting corners to produce something subpar could hurt more than help (see above Nintendo example).
In Part 1, we looked at how focusing on people and not technology can improve our solutions. So what could we do to bend the rules. Hyper focusing on the end user could allow for less requirement gathering and shorten the ramp-up window on the project. This may mean ignoring some key stakeholders, but depending on the company's goals, this could be mitigated later with future iterations.
One thing we should not do is run our development team above their normal pace for long periods of time. A short burst is okay, but holding the turbo button can and will break things.
In Part 2, we learned we should always be improving. A way to go quicker here is to go with a known solution. Instead of learning a new framework or implementing a new design. Can we reuse a solution and tweak it for our needs?
The first and acceptable way to go faster is back in Part 3 of this series. Getting to the smallest possible thing to vet the problem and idea is the best way to mitigate wasting time and money. Creating prototypes can also be the quickest way to to know if this is the right course of action. But this is following the plan, not bending it.
For development, we can cut corners by not writing tests. There will be consequences to this decision, like maintainability, long term growth, added technical debt, etc. But it could help you move faster at the start. I would highly recommend not taking this route, or if you do immediately go back and resolve as the next step. And I would only do this if the implementation is fairly straightforward.
Lastly in Part 4, we talked about supporting the future by working with early career team members. While it is very important and also makes everyone feel great, it can also slow down the team's overall performance. There is a cost to helping someone level up.
If your team is established and already has early career team members. Find something else for them to work on for a bit, or something ancillary to the solution where they won’t need much support or supervision.
If your team is new and you don’t have any early career team members, hold off on bringing them on board until a good architectural foundation is established.
If you are establishing a team, think about hiring an experienced consultancy like ZEAL who knows how to hit the ground running and deliver solutions.
These are all short term solutions to help the development cycle move faster for whatever the reason. The emphasis should be on the short term. Really we want to avoid using them at all if possible.
If any of these changes are implemented over the long term, you will not be bending your team/product, they will break. In the final article we will look at how to clean up the mess made by bending the rules and moving fast.
Photo by Michelle @Shelly Captures It on Unsplash
Are you ready to build something brilliant? We're ready to help.
.jpg)
