Lessons Learned from a Rocky Start of a Feature Replacement Project
Scenario: Product approaches engineering and says, "We want to replace and improve Feature X within the application. How long will it take to deliver improvements to our customers?"
This scenario recently came up at work, and we've learned a few interesting lessons along the way. In our case, Feature X was a rather important part of the application that all of our customers use, and we needed to make sure we got it right.
We made some missteps early on in the project that caused some frustration for everyone, so hopefully, others can learn from our mistakes and do better than us.
Do your research first.
Product did an excellent job interviewing customers and figuring out what pain points are currently causing frustration for our customers.
Engineering and product got together and spent some time trying to figure out what we wanted to build and deliver to customers in a few different stages or releases.
Engineering, then, dropped the ball in the research department in a few key ways.
We didn't understand the entire architecture of the existing system.
We thought we knew what the existing system did, but as we continued working on it, we kept finding new things that we didn't know about. This could have easily been avoided by spending some time studying the data model and mapping out everything that the existing system did.
All of the engineers did not have the same level of knowledge about new and existing architecture.
Some members of the team have years of experience working on the application, while others are quite new to the team.
When you're in this situation, it's imperative that the more experienced team members take the time to share their knowledge of how the system works. Don't assume everyone else will figure it out. Rather, expect that everyone should be able to explain how the old system works, and how the changes/improvements to Feature X will change things.
This expectation can only fairly be expected if more experienced members act as guides either through Pair Programming, Technical Lectures/Q&A Sessions, and Writing Documentation. Obviously, there are ways to share this knowledge, but these three work well, especially if your team employs all of these methods.
No consideration was given to modifying the existing data structure
Part way through the beginning of the project, we had a realization that we were creating new data tables and models "Just Because." We didn't necessarily have a fantastic reason to be doing this. we just were. In fact, the legacy tables that we were replacing were not all that different from what we were creating, so we could have saved a lot of time by modifying some existing tables or creating fewer new tables, but again, without effective research, we just didn't know what we didn't know.
So do your research ahead of time. Discover and detail through documentation and research what the current system is doing, and then, when the entire team understands that, move on and decide what needs to be replaced/removed/added.
Talk to your Teammates More, not Less.
You'd think this would not need to be said, but it really does. If people write marriage books on improving communication, then we can spend a few moments driving home the point that communication among team members is critical to a successful project.
The communication problem stems from a I'm-Just-Doing-My-User-Story approach to development. One thing that often happens is that work gets split up between the Micro-Service side and the Client side.
So front-end devs are working on scaffolding the feature up while back-end devs are preparing the api, business logic, and data structure.
This can work well, as long as everyone is talking to each other. But what happens when the the engineers working on the micro service and the engineers working on the client don't talk to each other?
Rework. And lots of it.
I would be shocked if everything worked seamlessly with this approach. The client needs to know what the contract is that they should adhere to, and the micro service needs to know the business rules for how Feature X should function.
In our case, the two sides were not talking and were developing in isolation. This led to massive miscommunication and a great deal of rework. Thankfully, the team swarmed around the problem and began talking again.
Side note: This is one downside to a fully distributed team. Or perhaps, this is a downside to our fully distributed team. We're still working out some of the kinks with that, and everyone being on the same page for technical approaches has been the only problem.
So talk more. Talk more. Talk more.
It's much easier to go to a whiteboard or to look at a flow chart again and again as a team before you begin the work than it is to all go off in our corners and return with whatever each individual contributor thought the deliverable for the user story was supposed to be.
Don't be Afraid to Face Your Problems.
Once a project starts, it can feel as though you just have to keep going, no matter. This is what everyone agreed to, right? Everyone agreed on the table design, business rules, timeline, UX, etc.
If it's not working, stop, reevaluate, and change it. Now, just above, I said that rework is bad, and it is, but we're not fish, and we shouldn't "Just Keep Swimming" simply because we started swimming at some point.
If you're going the wrong way, make a u-turn and go the right way. This can lead to hard conversations about how the team got off the rails, but it's important to have those hard conversations and to make sure you're building the correct thing in the correct way.
This happened to our team as we began Feature X. We kept running into technical limitations with some of the data designs. Product would show up and say "We want to be able to do X, Y, and Z." Engineering would come back and say we can do X and Z, but our current approach means we can't do Y.
What if Y is really important? Well, then pause, reassess, and redesign if you need to. If Y is a must-have, then you must figure out how to deliver it.
Essentially, be agile, but not in a foolish way where you're careless. Be agile in a way where the team acknowledges that unknowns or mistakes will happen, and that adapting to those things quickly and ambitiously will lead to a better result than ignoring the problems will.
These might not seem like game-changing things to do, but they can make a huge difference in team morale, development efficiency, and product quality.
So get to it. Research, Communicate, and Adjust.