Why don’t we stop doing Scrum?
The manager(let’s call her Pam) sighted at the coffee machine, “why, what’s up?” I responded. Out came a long litany of Product Owner vs Product Manager, Development Team, transparency and really actually changing vs the illusion of change. Many topics I’ve seen in increasing frequency on many social media platforms, so let's answer some of Pam’s questions.
The great rewrite
“So what is really bugging you?” I asked. “Well, I don’t know how to manage the teams anymore.” She replied. “The all work in their little corner of the product delivering microservices, but no longer seen to care about the whole.” The switch to microservices had been an ongoing painful project. Breaking up the monolithic, vendor locked system into small easy to manage services had proven a continuous stream of unpleasant surprises, taking up over 3 times the estimated time.
“I am yet to see a transition to microservices that did not result in a complete standstill of the cadence in which features are released to the market. We all know it is a lot of work, but why did we stop releasing?” tweet this
The architect that was fetching a green tea from the cabinet below chimed in: “just wasn’t done mate, there was so much to be set up that releasing earlier makes no sense.” And with what he dissapeared. “All I know is that the old platform is falling apart, the new one still isn’t up and running and customers haven’t seen a new feature in 6 months, just outages.”
“So…. what you are looking for is regular releases?” I tried. “Yeah, I guess we can slow down, but once a month we need to improve, our NPS dropped negative last week and we don’t know when a fix will be out.”
Regular releases would allow everyone to observe how the product is doing and take a far more balanced approach at deciding what to do next.
The UX vs the Development Team
“You guys are spending a lot of time in the coffee corner.” Jason the designer was always the observing guy, but you never knew what you should do with those observations. That sort of summed of the relationship of the UX team with the Development team as well. Especially with the introduction of design sprints the UX team had made great strides in learning what customers wanted and their insights had found their way to the backlog of the Development teams. “Unfortunately to the bottom of that backlog, where good ideas go to die.” Pam sighted.
“The bottom of the backlog is where good ideas go to die. What was the last thing that you deleted?” tweet this
Business analysis, marketing insights, campaign feedback, user studies, operational and customer feedback, UX studies; so many things influence what we should do next, but it all seems to happen in isolation. Take for example SEO analysis. Very valuable for the product, yet seldom is tied directly to what the team does. “So what problems does the Development team solve?” I asked. “Problems?” Pam looked puzzled, “they code stuff, test it and put it on production.”
Often when organisations grow, they grow un-organically. Imagine, an amoebe, a fully functional organism. It grows by making an exact copy, not by growing an additional specialised cell and figure out an interface.
“When we started, we just had Product teams.” Pam explained. “Everyone knew what we were doing and why. Titles didn’t matter, getting stuff in the hands of our customers mattered. We all had something amazing to bring, and most of the time we just had to do the stuff that had to be done, rather than what our title said.”
“If Development team means programming team, you are doing something wrong” tweet this
When specialist teams can’t keep up with the changes the market asks, seek simplification by creating “whole product teams” integrate roles like UX, BA and even operational roles into the team in order to create nimble units that know why they exist and what their purpose is.
The Product Owner Committee
We had walked around a bit when we came up to a huge wall cluttered with post-its. “I’m glad you endorse the value of visual management.” I said. “Well I think our agile coaches own stock of 3M” was Pam’s reply. We were looking at a multi-team alignment wall. It was referred to as a portfolio wall, but covered only a single product that was being build by over 8 teams.
A transparent overview of what is the next thing you want to build drives not only delivery, but most of all validation of assumptions. Shortening this feedback loop avoids creating products that nobody wants. tweet this
“So how do your teams know what to build?” I asked, looking at all the colours, numbers and threads of wool that made up this impressive artwork. “The Product Owners tell them.” she replied. “Well, how do the Product Owners know? and how does this shared ownership work?” I asked, and bit my tongue for asking two questions at the same time. “Well, the Product Manager tells them, Product Owner is more like a Scrum thing, it doesn’t really mean Owner.”
If Product Owner doesn’t really mean owner, then why call them that? imagine I would tell my wife that she shouldn’t take “faithful partner” literally. tweet this
I thought to myself (somethings you should not say out loud.) “So, the Product Manager knows,” I continued “how does this insight gets transferred to the teams?” A lot is lost in translation. The one that is setting the order of things is many steps separated from the ones actually doing the work. As a result, the consequences of choices are often not visible or at a very late time in the execution. Opportunities that are discovered by the teams get lost in the web of authority and handovers, slowing down actual innovation but most of all: damaging morale.
“The distance between those who decide and those who do is perhaps our biggest problem.” Pam continued, “but we need all these teams to cooperate if we are to finish our key projects. All must be done simultaneous and that creates this huge complexity.”
I drew something like the diagram above on a nearby whiteboard. “If you would do one project at the time you might get the first two earlier and benefit from additional focus.” Pam studied the sketch. “But we would need to tell two directors we started their project later.” She shook her head in disbelief. “So that, you can deliver earlier, with less risk and less complexity.” I added.
Complexity is hard to manage, focussed teams that work with direct market feedback is what accellerates value creation, and validation of assumptions. For this to work, you need true ownership and responsibilty on a product level.
Autonomy follows from discipline
“Then there is this constant debate over autonomy”, Pam looked frustrated. “Every time I ask something about what the teams are doing I get pushed back because they feel I interfere on their autonomy.” I wondered if she had teenage kids, and then I asked it out loud.
“Autonomy requires trust, trust comes from transparency and discipline. If you feel you can’t operate autonomous start improving your own discipline” tweet this
“I know where you are getting at, but with kids it is different. They earned their freedom by exhibiting discipline. They do what they say and say what they do.” She replied. “Is it really that different? What would they need to improve in their discipline to gain your trust?” After a bit of thinking we ended up with the following items on the whiteboard.
- Show what the goal is for the current release
- Make and have a plan on how to reach that goal
- Make sure your plan is up to date (daily!)
- Ask for help if the goal is in danger
Many organisations find this transparency hard, the change of behaviour seldom happens voluntary and requires gentle (and sometimes not so gentle) reminding on what to do and how to improve.
“Who helps the teams with this? you know the getting better part, improving the way they work, make sure the discipline sticks. I remember that when our soccer coach was ill, nobody would actually stick to the training rituals.” Pam’s eyes glazed, “Most teams have a tester that doubles as Scrum master if that is what you mean?”
If you don’t take self improvement serious, you won’t improve very serious either. tweet this
Conclusion
It was a good talk, and Pam was happy to discover that their Scrum wasn’t very effective for them. Later that night when she was going over her notes she came up with some things they should do to really make a difference:
Clarity on the what:
- Ship stuff, at least once a month
- Use real feedback from real customers to decide what to do next
- One list of all the things we need to do, ordered, sequential not in parallel
- Teams have a goal, a plan (which gets tuned daily)
- We get better every at doing this stuff using systematic improvement
Clarity on the who:
- One product means one person responsible for ordering the work that needs to be done
- Have teams that contain all disciplines to actually ship a product, no handoffs
- Each team needs a helper that learns them about the rules, until the master more discipline. By then we probably need to educate the rest of the organisation
Then she put her pencil down and asked the one question that I didn’t: “Why are we building this?” and with that she realised that perhaps Scrum was not the problem, (or not doing Scrum correctly was the root cause):
“In the end, Scrum is just a framework. It doesn’t tell you why your product should be built? or if customers will like it? or buy it? or buy it from you? not even if it can be built! It just provides the conditions for you to find out.” tweet this
