If you are a member of my team I expect you to make our work a better place as a part of your job. I expect you to leave all code cleaner than you found it, to fix issues when they are spotted, etc. Most people like working in an environment like that, but it seems to be a very big hurdle to go from "ahh this code sucks!" to "ahh this code sucks! Let's fix it" for new people who join our organisation. So many have been indoctrinated through previous experience into the state of mind that "There is no way that management will pay for this".
A guide that I've been using to help people come to terms with how they can make these improvements happen is using the Rule of 2.
2 Hours
Will the improvement take less than 2 hours to implement?
If yes, then why are you asking for permission? Just go and do it, once it's up and running then run me through it, particularly if it results in a good benefit.
The first thing I get asked when I tell someone about this is "What if it doesn't work? Haven't you just wasted 2 hours?"
Let's reflect on what happens when we don't allow our team members this freedom. How much time does it take for them to bring up the courage to approach me with the issue? How much efficiency is lost by not fixing/improving the issue there and then? How much time does it take for me to then take the 2 hour idea to my boss and ask for approval? (You might laugh, but I've seen 2 hour requests make it through 3 or more layers of management) How much motivation is lost because you feel that you "just have to live with it"?
When I do that equation, not allowing you the 2 hours is costing us significantly more than the 2 hour investment that you are asking for.
The worst that will happen is that we have spent 2 hours of time and haven't received any measurable benefit. But that doesn't mean that there isn't value to be gained by going through the process. Why didn't our improvement actually improve things? What didn't we foresee? This is a chance for me to help you understand what we could do better next time.
On the positive side, you might have a win, and the more comfortable the team is with this approach, the higher the strike rate is going to get.
2 Days
Will the improvement take more than 2 hours, but less than 2 days to implement?
If so, come and have a chat and convince me that it is worth doing. I don't want you to fill out 10 pages of documentation, I just want you to be able to articulate clearly what the problem is, what the solution is, and what the benefit will be as a result of that. If you've thought it through to that level, and we can't see any major risks, then we'll find some time for you to get it done, usually within the next week or two.
At 2 days effort, I'll be a bit more of a stickler for finding a benefit, but I'm happy for it to be a bit fluffy or nebulous. I'll never discount the positive impact removing frustration from a process can provide, even if it doesn't save time, it does remove negativity.
2 Weeks
Will the improvement take more than 2 days, but less than 2 weeks to implement?
If so, we'll have to do a bit more homework to provide sound reasoning behind the projected benefit of the change. I'll sit down with you and together we'll define what the benefits will be, how we can measure them, and what impacts the change will have (such as training costs, or flow on effects to down stream systems and processes). If the benefit is of minimal impact, then I'll probably point out a few similar sized items of work that are in the backlog somewhere and ask you to convince me why this improvement is worth doing before the other item on the backlog.
If we decide that the work is worth doing, then I'll take the idea to my manager, and we'll probably get approval for it. When we get to it will be dependent on current project commitments, and we'll probably schedule it into the next project gap, which is often within 4-8 weeks.
More than 2 weeks
Will the improvement take more than 2 weeks to implement?
If so, we are going to have to go through the same process as everyone else, we'll walk through the idea to flesh out the problem, solution, and benefits, I'll walk you through other work on the backlog to identify where we think it sits. If it stacks up, then I'll work with you to contact the right stakeholder to get it going (which could be my manager in some cases) and we will have a red hot go at getting it into the pipeline.
Conclusion
One of the keys to making this successful, is to make sure that whoever raises the idea is responsible for making it happen. You need to be the one to do the planning, the implementation, organising the testing, and finding a release for it to go in. If the idea isn't worth doing, I need you to make that call, I'll coach you into that place where you understand that your solution, although valuable, is not high enough in value to be anywhere near the top of the backlog.
I say the Rule of 2 is really a guide, because if the idea is going to take 2.5 hours then we can probably let it fall into the 2 hour rule, and if it is 2.5 days, then the 2 day rule will be fine.
No comments:
Post a Comment