In Part I of this series, I talked about why we were changing our processes to better align with the type of work we are doing as well as some of the business challenges and different outcomes we wanted to get. It’s been just over 2 weeks since we started and we’ve done 1 retrospective as a team so far.
I mentioned in our first post that we generally have a bad habit of considering all problems to be emergencies and our previous implementation of Kanban was more of an excuse to not prioritize and push work through. Over the past couple weeks I observed another interesting system effect. I call this the “we should” syndrome. “We should do this work” statements are usually interpreted as “drop what you are doing and go do that new thing“. These discussions usually start with managers and the workers interpret that as an order even though there is no explicit discussion or decision to do the work. This isn’t something new, I haven’t worked in an environment where this type of stuff doesn’t happen.
So here we are a couple weeks later and every standup someone is working on something that isn’t accounted for and the inputs to the team are still going around the queue. I’m probably the most anti-process person you’ll meet but if we agreed to a process, stick to it until it proves that the process needs to change otherwise you end up where you started, random chaos.
Retrospective Output:
Good things:
– WIP limits are good
– Defined some policies
– Separated maintenance from product work
Not Good:
– Policies are too loose
To Try:
– Define more explicit policies
One of the problems with not having explicit policies was that people had different opinions of what ‘maintenance’ items were. The developers felt strongly that ‘maintenance’ was only scripts and config related but did not include any work that required code changes. Even though they felt strongly about that, they would still make the code changes anyway. The inputs to the developers though maintenance was any work item regardless of what was needed to fix it.
We openly agreed to adjust our workflow, the image below shows what our new Kanban board looks like:
What’s Changed:
- policies are more explicit (Standard, Expedite, Intangible, Maintenance)
- code changes invoke product release cycle OR we decide to not do that work and throw it out (IE: if 1 client brings up an edge-case bug, we may choose to not fix it based on our other priorities)
- our weekly prioritization meeting is now focused on feeding the maintenance queue only (we have our product priorities set)
- we have slack in the system to deal with un-anticipated work (we’re a small team and realize we will have to task switch, we just want to eliminate as much of that as possible)
- we’ll start to collect lead and cycle times by class of service and size of each service (IE: standard work items can be small, medium, large and no in progress work that started over a week ago haven’t been finished yet)
Habits Are Hard To Change
Some people think this process is a way for a control freak such as myself to control the team. Oh so not the case! Before I started our average age of a “product issue” was 570 days because the backlog was an un-organized mess, there was no direction in product and generally the backlog was just a dumping ground for “we have to” work. I deleted most of it because if it “has to” get done and it’s been sitting there for year, it ain’t getting done, get over it. Progress is progress and the only way to get a different outcome is to do something different and I am excruciatingly vocal about this. There are a ton of things I want to change about our product, but they are less important than the work we are doing that aligns with our organizational goal. I don’t like it but as the Product Owner, my responsibility to do to the right work for the product at the right time to contribute to those goals and that feels good. I described more problems in Part I of this post if you’re interested.
During our recent weekly prioritization meeting we started going down the path of analyzing all items in the backlog to validate whether or not they were valid. I nipped this in the bud quickly which probably annoyed some people, but too bad. I made it clear our goal was to fill the queue with enough work to get us through to the next meeting. Going through old issues is a waste of time and we’ve done it far too frequently.
I’m a firm believer that it’s not the person, it’s the system. We have great people that mean well, but it’s much harder to stay disciplined with process changes and we usually fall back on the old status quo. It takes much less mental energy to keep doing the same thing over and over than do something different and this subtle change is working is a huge change in the overall system, it affects how we intake work, how we prioritize, how we set expectations with our customers and much more. We’ll get there, bad habits take time to change and integrate into the new status quo.
What’s Next?
Given our size, I expect the next couple weeks to have some painful conversations about priority, which is natural. I also expect our weekly priority meeting to go away at some point but we need to mature as an organization for this to happen. Over the next couple of weeks I hope to get some data from our process and solve these business challenges:
- give our customers (support and professional services) cycle time so they can set expectations with end users and clients
- get data from product work to assist with gaining predictability (allow for better release forecasting based on measured work)
That’s it for now, let me know your feedback!