I’ve been checking out a number of teams and what their workloads look like. I’ve of course worked on more than few with completely disparate practices and policies. Some where really good at making great progress and others were absolutely horrendous. I’d argue one team actually went backwards in progress more than a few times. Suffice it to say, I’ve seen a whole lot of the bad and a fair amount of amazing teams. I’ve been fortunate in doing so as it really helps to have a solid perspective in both arenas.
To summarize, it’s nice to know when the ship is sinking and when the ship is sailing full steam toward the destination!
Quick context: I’m generally referring to a Product Backlog and or a Sprint Backlog.
Work in Progress Versus Backlog
Today I got to thinking and I realized I need to keep things in perspective. Especially, when thinking from the CTO perspective, about what I need to do versus what the rest of the team needs to do. As I slowly build out a team the focus from code to vision comes into stark contrast.
I started to ponder a very tactical concern. When and how does one manage their backlog without it becoming waste within the team that’s actually doing the work? How does one manage team buy in without getting them burned out thinking about higher level, often changing problems? Does one force the backlog to just not change or does one actively prune the backlog at each work effort? Why not just keep things active, forget the backlog, and build up what needs done at the beginning of each work effort? But at the same time ensuring they have vested interest to the actual high level architectural and design of the software they’re building?
These don’t have immediate and straight forward answers, but here’s a few thoughts based on experience and a good idea about what may or may not work.
- Backlogs are great for brainstorming. But they shouldn’t be set in stone.
- Backlogs should be flexible, but they shouldn’t be so abstract and flexible as the work never gets tackled.
- Backlogs shouldn’t be used to store every single wish list item. A backlog should stay active from many perspectives, to maintain its relevancy but also not to damage morale.
But are these things achievable with a backlog?
Backlogs
Backlogs are great if they’re used for brainstorming and determining the way a product is moving. They can be used among the leadership to determine, mixed in with a good dose of marketing information and company mission, the direction of the efforts of the company. However, I have seen far to many times where the actual team of developers that is working to build the product just has their time wasted when leadership brings in a backlog and says “pull tasks from this” or “pull your stories from this”.
Why do I feel this might be a waste? Because most of the backlog, based on most development teams, never actually gets completed. Most of it never even begins to be worked on. I’ve seen it happen, heard complaints to no end, and seen teams spin out of control.
The backlog ends up being a list of things that will be circumvented until the next sprint or call to action. Then at the end the backlog will be reviewed, a bunch of things will change, a bunch of other things will be added to the backlog, and the list of things to work on for the next iteration or sprint is created while actually ignoring the original backlog. This happens far too often.
So my question is, where do you break out your backlog? How do you keep a backlog useful on your team? Do you even use a backlog? How do you encourage brain storming versus just tossing things in a backlog, only to just decide what to do next based on what was just done? How does one manage work in progress (WIP) of the backlog versus WIP of the day to day stories and tasks that need completed?
I’ve just been pondering this lately and would be very interested in seeing some other’s thoughts. -Cheers
Reblogged this on Sutoprise Avenue, A SutoCom Source.
Ditto. I’ve experienced great progress and absolutely horrendous. I’ve done both. “Learning by Shipping” and “Learning by not Shipping” (Steven Sinofsky pun intended :o)
Q. How does one manage team buy in without getting them burned out thinking about higher level, often changing problems?
By sharing the product vision with the team as often as needs to steer the product (2 times per year). Only sharing a shorter horizon with the team. No more than 6-12 weeks of work effort — say 3 to 6 sprints worth (depending on complexity of product and mix of full time vs. contractor developers).
Q. Does one force the backlog to just not change or does one actively prune the backlog at each work effort?
Better to force shipping the product on a regular basis. From the action of shipping the backlog is somewhat automatically stabilized, prioritized and pruned. (Requires some learning to find the shipping cadence of beta vs. stable releases that customers desire (or will endure).
Q. But at the same time ensuring they have vested interest to the actual high level architectural and design of the software they’re building?
Most full-time professional developers and many contractors naturally have a vested interest in actual high level design of the software they’re building — by sharing the vision periodically (2 times per year, perhaps more often when a startup).
Q. Why not just keep things active, forget the backlog, and build up what needs done at the beginning of each work effort?
Winning customers over to use beta product in live production, which I think is key to driving quality, requires an active backlog. The backlog of new features and new vision needs balancing with keeping customers happy using freshly tested code.
Q. But are these things achievable with a backlog?
No — software companies under 100 people need to manage an active backlog. Yes — software companies over 100 people (transition to delegating more thru stable backlog).
Q. So my question is, where do you break out your backlog?
My experience is you breakout your backlog sharing what you are planning to ship in you beta (with accompanying live beta doco for support, customers). Also share your bug list; bugs being worked on are part of the active backlog. Breaking out backlog to more than 3 sprints out is hazardous to setting expectations and keeping good morale with dev team, and all product stakeholders.
Q. How do you keep a backlog useful on your team?
The backlog is what the team is working on now. If the issue is not on the backlog the team or sales or customers, or cofounders need to discuss the product or architectural concept or request with the CTO or whomever is the “product chief.”
Q. Do you even use a backlog?
I always use a shareable digital backlog on shipping product used by customers. I use a whiteboard backlog for experiments or fast moving R&D.
Q. How do you encourage brainstorming versus just tossing things in a backlog, only to just decide what to do next based on what was just done?
Whiteboard brainstorming. The backlog is mainly customer driven. After the 3 sprints out time fence pull the whiteboard into the backlog (yeah you might need to start coding in sprint 0, 1 or 2 for large features or ground work for architectural changes)
Q. How does one manage work in progress (WIP) of the backlog versus WIP of the day-to-day stories and tasks that need completed?
Key the developers; testers have a clear picture what exactly they are working on. For a new application this requires a specification. For a feature access to a domain expert who knows the requirements and can document what the developer and tester does not understand or has questions about. This spec converts into customer doco. For an interlocking application like an ERP app it’s swifter of this is one person, although it’s a strain, especially if the person is also the CTO. Architectural changes should be developed by lead engineer, or at least guided by the CTO, so that impact can be communicated clearly to product team, and appropriate attention given to testing in beta.
In summary: The early stage CTO should focus on making is working on Moore’s Law technology and shipping. The fewest number of live beta customers are using the product in live production to iron out active backlog issues. Then WIP vs. Backlog and balancing product team morale is set to fall into place.
As the ‘CTO type guy’ of a Scrum training and credential company I can tell you that backlogs actually do work. They work in spectacular fashion….when they’re used correctly and the team has bought in to their use as a tool for accomplishing a shared goal (in the case of Scrum it’s an incremental delivery). I’ve used backlogs as a “task list” and I’ve used different methodologies (Kanban, Lean, etc…) that use backlogs extensively, I’ve found that if you focus on the minutiae and don’t keep your backlog reasonably high level it becomes a nuisance to maintain and people will feel like they are focusing on keeping the backlog maintained and not getting work done.
Scrum uses the product backlog as a prioritized list of items that need to be accomplished based on the needs of the business. The person who is responsible for this backlog is the Product Owner (key stakeholder). The PO and the development team generally discuss items in the backlog but they may or may not ever get worked on. This is because it’s up to the PO to make decisions based on conversations with the rest of the team and other business stakeholders on how to proceed. So yes, like you say, some items in a backlog may never get worked on, but that doesn’t make you unsuccessful, that just means you aren’t focused on those items yet…..so I say, add everything you want to it, but keep it high enough level that you aren’t micro-managing your backlog for the sake of having a backlog.