Who owns the code you write? Who's responsible for when the software ships? Who owns the success of the company? Who owns what you work on? Who owns your decisions? If someone comes up to you with a different priority than you were told at Sprint Planning, what should you do?
The answer to some of those may be very obvious. The answer to others may not be what we'd initially think it is. In all these questions and related questions, I'd argue that the answer is "me." I have at least some ownership for my code, when the software ships, the success of the company, what I work on, what I don't work on, and what decisions I make. Let me take a few minutes and share why I think this way.
I recently was in a meeting where we talk about our process at work and discuss what's going well and what's not going well. The goal is to build on the good and correct the bad. The main topic of discussion that day was in regards to some recent decisions that seem to be creating things that operate outside of our chosen processes. There was concern that we were taking shortcuts and should keep those items in our chosen process instead of pushing them out of the process.
A good discussion followed on why these decisions were made, how we see them fitting either inside of or outside of the process, and how we think it'll all work together. We also talked about some cultural aspects that probably influenced these decisions and how we've seen these things impact us personally. One of these cultural aspects seems to be pressure to focus on new features at the expense of fixing bugs. This is completely understandable and even normal. We need new features. Product Managers need to push, in a healthy way, for teams to work hard on those new features. Unfortunately this either comes across, implicitly or explicitly, as a request to ignore quality, ignore bugs, and just pump new, shiny things out as fast as you can (which is the start of the Vicious Cycle of Software Development).
The head of our department made some great comments. He stated that he wants us to do the right thing the first time (which is something I've heard from him since the first time I met him as a prospective employee) and that if there's a contradictory message coming down, it's not coming from him.
His comments got me thinking a bit more about why we, as developers, sometimes feel pressure to ignore bugs and focus on features. Some questions started to go through my mind. Was it really just the PM's pushing too hard on features? Do they not understand the value of fixing bugs? Do they not see that if we ignore bugs, there will be a big delay to releasing the software as we go through a "hardening" phase? Why can't they understand this?
Maybe some of these things are true to one degree or another, but our PM's and PO's are really great people. Was it all their fault? Wait. What if it's not their fault? What if it's my fault? What if it's the teams' fault? What if we are encouraging this behavior? What if there was something we could do to stop it?
That's when a light turned on in my head.
While the PM's and PO's aren't perfect, they do a really good job and they're trying to get better just like the rest of us are. While I can influence this group, there's nothing I can do to change them. So what can I do? What can we do as members of the teams working on the software?
We can take ownership.
We can take ownership for the software. We can take ownership for all aspects of the work our team does. We can take ownership of the quality of the software even if we're not QA. We can take ownership of when the software releases. We can take ownership of delays or shifts in priority. We can take ownership of our sprint plan and the commitment we made to it. We can take ownership of the success of our team, our department, and the company as a whole.
What does it mean to take ownership? It means not shifting blame to other groups. It means looking inward first to identify how I am contributing to the problem before looking outward to help others solve the problem. It means taking responsibility for how your work impacts the product and impacts others. It means being an advocate for your team and for your policies. It means treating everything you do and your department does as though your personal career depended on it.
As you read that, you might think that's either overwhelming or you need to be very stuck-up and egotistical and ruin everyone else's lives. That's not the case. For the most part, having this mindset won't require a change in your behavior. Most days will be just as they were before. There will be times, however, when you might have agreed to something that you'd now have a desire to correct, resist, or seek to understand.
When the PO comes to Sprint Planning and says that the team needs to focus on a certain feature and we shouldn't work on any bugs until it's done even though you all agreed to allocate a certain amount to bugs each sprint, a red flag will raise in your head. When that happens, your first questions might be some to gain a better understanding of why the PO is asking this of the team. Once you understand where they're coming from, you'll probably want to explain a bit of the ripple effects such a request will have. You might say something like, "this will likely delay releasing anything by a few weeks," or "we've all agreed to a certain workload and a certain level of quality. This feels like we're setting that aside." From there, you can hopefully have a discussion of how to meet both requirements. This may require compromise on both ends, but reaching a middle-ground is normally better than simply doing what one party or the other wants.
In conclusion, I'd encourage you to take ownership for the success of your team and the success of your company. If you see things that are circumventing the process, say something. Ask why that's happening. See if there are alternative solutions. Offer help and suggestions. Look to yourself first to see if you're somehow contributing to or causing the problem you're seeing (sometimes it takes time to see this). In the end, take ownership for your actions, the actions of your team, and the actions of those working with your team. The success of the entire organization depends on it. You don't work in a bubble. Everything you do affects your team, the teams around you, and the success of the company.
------
This post turned out a lot longer than I intended. Having an attitude of ownership and trying to help things go right is important in your success in your career. For more thoughts and discussion on how to adopt this mindset, I highly, highly recommend the book The Anatomy of Peace.
The answer to some of those may be very obvious. The answer to others may not be what we'd initially think it is. In all these questions and related questions, I'd argue that the answer is "me." I have at least some ownership for my code, when the software ships, the success of the company, what I work on, what I don't work on, and what decisions I make. Let me take a few minutes and share why I think this way.
I recently was in a meeting where we talk about our process at work and discuss what's going well and what's not going well. The goal is to build on the good and correct the bad. The main topic of discussion that day was in regards to some recent decisions that seem to be creating things that operate outside of our chosen processes. There was concern that we were taking shortcuts and should keep those items in our chosen process instead of pushing them out of the process.
A good discussion followed on why these decisions were made, how we see them fitting either inside of or outside of the process, and how we think it'll all work together. We also talked about some cultural aspects that probably influenced these decisions and how we've seen these things impact us personally. One of these cultural aspects seems to be pressure to focus on new features at the expense of fixing bugs. This is completely understandable and even normal. We need new features. Product Managers need to push, in a healthy way, for teams to work hard on those new features. Unfortunately this either comes across, implicitly or explicitly, as a request to ignore quality, ignore bugs, and just pump new, shiny things out as fast as you can (which is the start of the Vicious Cycle of Software Development).
The head of our department made some great comments. He stated that he wants us to do the right thing the first time (which is something I've heard from him since the first time I met him as a prospective employee) and that if there's a contradictory message coming down, it's not coming from him.
His comments got me thinking a bit more about why we, as developers, sometimes feel pressure to ignore bugs and focus on features. Some questions started to go through my mind. Was it really just the PM's pushing too hard on features? Do they not understand the value of fixing bugs? Do they not see that if we ignore bugs, there will be a big delay to releasing the software as we go through a "hardening" phase? Why can't they understand this?
Maybe some of these things are true to one degree or another, but our PM's and PO's are really great people. Was it all their fault? Wait. What if it's not their fault? What if it's my fault? What if it's the teams' fault? What if we are encouraging this behavior? What if there was something we could do to stop it?
That's when a light turned on in my head.
While the PM's and PO's aren't perfect, they do a really good job and they're trying to get better just like the rest of us are. While I can influence this group, there's nothing I can do to change them. So what can I do? What can we do as members of the teams working on the software?
We can take ownership.
We can take ownership for the software. We can take ownership for all aspects of the work our team does. We can take ownership of the quality of the software even if we're not QA. We can take ownership of when the software releases. We can take ownership of delays or shifts in priority. We can take ownership of our sprint plan and the commitment we made to it. We can take ownership of the success of our team, our department, and the company as a whole.
What does it mean to take ownership? It means not shifting blame to other groups. It means looking inward first to identify how I am contributing to the problem before looking outward to help others solve the problem. It means taking responsibility for how your work impacts the product and impacts others. It means being an advocate for your team and for your policies. It means treating everything you do and your department does as though your personal career depended on it.
As you read that, you might think that's either overwhelming or you need to be very stuck-up and egotistical and ruin everyone else's lives. That's not the case. For the most part, having this mindset won't require a change in your behavior. Most days will be just as they were before. There will be times, however, when you might have agreed to something that you'd now have a desire to correct, resist, or seek to understand.
When the PO comes to Sprint Planning and says that the team needs to focus on a certain feature and we shouldn't work on any bugs until it's done even though you all agreed to allocate a certain amount to bugs each sprint, a red flag will raise in your head. When that happens, your first questions might be some to gain a better understanding of why the PO is asking this of the team. Once you understand where they're coming from, you'll probably want to explain a bit of the ripple effects such a request will have. You might say something like, "this will likely delay releasing anything by a few weeks," or "we've all agreed to a certain workload and a certain level of quality. This feels like we're setting that aside." From there, you can hopefully have a discussion of how to meet both requirements. This may require compromise on both ends, but reaching a middle-ground is normally better than simply doing what one party or the other wants.
In conclusion, I'd encourage you to take ownership for the success of your team and the success of your company. If you see things that are circumventing the process, say something. Ask why that's happening. See if there are alternative solutions. Offer help and suggestions. Look to yourself first to see if you're somehow contributing to or causing the problem you're seeing (sometimes it takes time to see this). In the end, take ownership for your actions, the actions of your team, and the actions of those working with your team. The success of the entire organization depends on it. You don't work in a bubble. Everything you do affects your team, the teams around you, and the success of the company.
------
This post turned out a lot longer than I intended. Having an attitude of ownership and trying to help things go right is important in your success in your career. For more thoughts and discussion on how to adopt this mindset, I highly, highly recommend the book The Anatomy of Peace.
Comments
Post a Comment