Putting the pieces together - Product Management
With development, product management, and various processes that we try to follow, I have noticed that all the pieces fall into place with a few key components.
- A good development team
- A simple process to follow
- A great attitude
I know that all sounds very cliche, but apparently some of things that I have learned and take for granted at times, are novel and brilliant observations to others. I am not sure how brilliant some of these observations are, but they definitely help others, which ultimately is my favorite sense of accomplishment. So let's break down these three topics and explain the why behind them.
A good development team
A good development team is more than just good technical developers and sharp meticulous QA. It is the interactions between the team members, the collaboration that occurs, and the side conversations that spur innovation. Every company wants to say they are "leading innovation in their industry". However, ask them HOW do they think they are doing that? Are you providing the team with time to just relax and think? Do you feel if they aren't writing code or tests, are they being lazy? So many great ideas come while walking around. They rarely come with time constraints looming in the background. However, try to tell a bunch of investors that you will finish the product when the team feels good about the direction and the product. LOL, ok that actually made me laugh. Back to the development team, it is important that they have a good workspace, good tools, and most importantly good interactions. I LOVE going to work because of the people I work with. I get excited to see what new solution we come up with, or new way to improve our performance. It really is exciting because of the people. Hire good people, most technical can be taught but personalities are hard to change.
A simple process
A simple process is just that. Something that is simple. I know it sounds typical, but people always come up with exceptions, workarounds, and special cases. So let's define what a simple process is?
New Functionality - Create a backlog item with a wireframe, acceptance criteria, and an explanation of the new behavior.
New Defect - Create a backlog item with repro steps (including browser, os, and user type), Explain what happens, Explain what is expected.
It is not more complicated than that. Now, people reading this are going... What about..
- A defect that comes during testing the new functionality, is that a new defect, or an update to the story, or a new test to track or...
- A background/infrastructure change that doesn't really lend itself to a backlog item with a wireframe
- A refactor to existing code to improve the performance, and make it more maintainable
- A quick fix, that will take less time to fix than to open a new backlog, prioritize it, estimate it... by the time you wrote that I could have fixed it
- A defect that comes in during a sprint that bumps everything...
Well, for those reading that are noticing that I am assuming you are following an Agile approach using Scrum. I think in your mind, you have an immediate answer to all of those questions..
- Talk to the developer, pair with them until it is fixed, close the backlog.
- Explain the story to the product owner, do the work with unit tests, pass the tests, finished.
- see #2
- Just fix it and make sure you have a test around it.
- Priorities change, so fix the defect and continue with your work. (make sure you have a test for it)
You notice a recurring theme: Test It! Automated tests, make code more stable, and raises the trust in the code when you get "creative" in your refactor. Simple process.
Make it even more simple: Defect - Write Test, Fix it and verify test passes. New Functionality - Write test, Create it and verify test passes.
By doing that, you will understand all functionality by running the tests. Ideally, if you have a strong, stable code base... LOL, ok we all know that never happens, I'll stop there. Let's deal with reality. For legacy, crappy code bases, write new tests for any new functionality. Over time you will have a stable code base that you trust.
A great attitude
This often gets overlooked. We all work on code we don't like, usually because it isn't ours or it was written 10 years ago and newer technology exists now that would make it SO much better/easier/choose adjective. However, if you realize all of that and view it as an opportunity to make the code better, improve the company's products, and learn something new about refactoring old code. That attitude will make your job SO much more fun, exciting, and educational. You will be easier to work with, viewed as a leader, and a solid performer. True you need to have technical knowledge to solve the problem, but it will always make a bigger impression when you view your job as someone who is helping the team, the company, the manager. That is something I have done for years but never realized it until recently. I'm a manager now, and my job is not to lead my team to complete the project, but it is to help them solve the problems at hand. It may sound like a semantic issue, but I think that little nuance really makes your attitude different.
I hope this helps you out a little as you approach your Monday with your code base, your project, or your team. Let me know what you think and what I missed, and how it doesn't work.
Thanks for stopping by.