Storytime on the importance of organizing work…
A long time ago… in a land not so far away, I was just starting work as a new developer.
Tasks were flying toward me from all directions, so I decided to go to my boss and ask for clarification on what I should be working on. Let’s call him Larry (mainly because that was his name). On the whiteboard, I wrote down all the major projects I was asked to work on. There were about a dozen. In Agile terms, this would be a list of Epics.
I kid you not; in the space to the left of each item, he went down the list and marked the letter “A” next to each item. It was a long time ago, so maybe I’m remembering wrong. Possibly, there was a single “A+,” and the rest of the items were “A’s.” He then literally went through the list and said, “Item 1, that’s an A priority; Item 2, definitely an A priority; Item 3, for sure that one is an A priority…” and so on.
I can remember the room, the smell (we were in the basement of a larger, not-so-great office building that made chemicals), the table, and how sure Larry was of himself that he had correctly identified that every item was an A priority.
At this point, I was dumbfounded. And given the era, there was no way I was going to dig my heels in and challenge him. So, I did what probably every young, new employee would have done. I thanked him, got up, left the room, and went back to my desk.
There was a ton of pressure to get things done, so there wasn’t much time for reflection. Remember, this was years, if not decades, before modern team processes such as Agile were being used. So, wanting to be a good employee, I picked an item off the list and started working on it. Yep, the brand-new employee, working in a completely new industry, who had never managed a project or had even met the client, just picked a random item off the list.
I think we can all agree this wasn’t the best way to prioritize work.
Definitions:
Product Backlog: A prioritized list of all the desired work on the project. It is the single source of requirements for any changes to be made to the product. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. It includes a variety of items, such as new features, enhancements, bug fixes, infrastructure changes, and so on.
Sprint Backlog: A subset of the Product Backlog. It is the list of items selected for implementation in the current Sprint. It is a time-boxed period (usually 2 – 4 weeks) during which a “Done,” usable, and potentially releasable product increment is created. The Sprint Backlog is managed by the Development Team. It includes all the tasks identified by the team to complete the Sprint Backlog items and achieve the Sprint goal. The Sprint Backlog is a plan by and for the developers.
Waste: Any activities, processes, or elements that do not add value to the customer or the final product. Lean manufacturing principles, originally popularized by Toyota in the mid-20th century and later adapted to Lean software development and Agile methodologies, categorize waste into specific types to help identify and eliminate them. The elimination of waste is crucial in these methodologies to improve efficiency, enhance product quality, and reduce time and costs.
Going from Suck to Awesome
Sucks – No process or method to organize work.
Sucks a little less – A method to organize work but no checks and balances or team collaboration.
Awesome – A process to organize work that delivers desired positive results consistently.
Organizing Work Priorities
It Could Be Worse!
In the sad but true story above, at least my manager knew the items I was going to work on. And, the items were generated by others on the larger team. Nothing on the list was made up or not important.
Most of the consulting arrangements I engage with that have more than a handful of developers usually waste about a third of their time working on projects that don’t make any sense and will never make it to production.
Now, before you start blaming the developers, put yourself in their position. In unorganized work settings, there is a common misbelief that working hard is what is important. I am all for working hard, but if work isn’t the right work at the right time, then it is a very expensive form of waste [See definition above.]
Briefly, here are some reasons why waste occurs at this junction:
Lack of alignment: An unaligned team makes it hard to coordinate features the customer finds valuable. Lack of alignment doesn’t make work impossible; it just makes it harder, so more effort, time, or budget is required to accomplish a goal.
Lack of process: Like lack of alignment, the lack of process will require more work because without a known process, much of the work is completed as a one-off task, and the team doesn’t have the tools to work toward a common goal. On a team with a good process, everyone knows what to do and when. Expectations are known, which reduces uncertainty, and we all know that a high level of uncertainty results in larger estimates because the risk is higher.
Lack of leadership: Without leadership at all levels, the team won’t know what is important. The lack of clarity will cause the team to “guess” and make decisions that aren’t aligned toward an agreed-upon goal.
Lack of organization: If everything is organized, less time is spent trying to locate work and find resources. Everyone has had an experience where they have wasted an hour looking for a document that wasn’t in its specified location.
Unhealthy culture: If there is a low level of team safety, employees may engage in activities to protect themselves. They may take the less desirable path because it is safer. If members are motivated by fear, they won’t be honest about all sorts of important things, such as estimates, status of the code, timelines, etc.
Lack of company vision: If the whole company doesn’t have a clear vision, how is each team supposed to do their part? A lack of vision directly hurts teams because a clear vision will provide a framework for making decisions when specifics are unknown or unavailable.
How to Organize Work
To state the obvious, the team should have a product backlog. The product backlog should be in order of what is desired to be completed first. Additionally, the team should have a Sprint backlog, which should be planned by the whole team, not just the Product Owner.
When thinking about what to plan into the Sprint, here are some items to consider:
Can the work be grouped in such a way that expedites the delivery of a usable feature? The feature doesn’t have to be in its final state, but it does have to be usable and valuable.
Can the work be grouped in such a way that allows the developers to reduce the amount of coding and/or testing? Sometimes, grouping like features is a real timesaver for the developer.
Are there certain items that need to be researched before they can be properly planned? The research may need to be done before the work can be properly estimated.
Are there certain items that will take a very long time? Working on items that will take longer may make sense because they could inadvertently block other areas of the system. My peer used to call this “the long pole in the tent approach.” The idea is to complete the items that will take the longest first, so it doesn’t block the release of the whole feature or product.
Are there certain items that have external dependencies? It’s best to at least get the external dependencies they need, so the dependencies won’t impede you when you need them.
Is there a legal, security, or other critical issue that requires immediate attention?
Does your team have single points of failure with specific skill sets, such as a particular programming language? Make sure the team can complete the tasks entered in the Sprint. Don’t let all the tasks fall to specific team members.
Is it Okay to Parallelize Work?
Yes, it is okay to parallelize work, but priorities should be serial.
Priorities should be clear and ordered. No two tasks should be the same rank. I have seen boards where a single person (small team) has ten high-priority tasks. Don’t be like Larry! When the product owners, stakeholders, and the team fail to prioritize tasks, what will happen is the developer working on the task will prioritize the tasks based on their preferences, which may or may not align with the business’s preference. For example, the developer may prioritize items based on the task that uses the latest technology because that sounds like more fun.
A quick note to the Agile purist (you know if you are one of them), because something about this conversation is irritating you. How could a person ever have more than one task to work on? The most optimal way to operate is for each member to pull one task at a time. Therefore, a person would never have more than one task. I get it—but take the scenario where you have a highly distributed team and a developer hits a block during their day, which is the product owner’s night. I would rather the developer task off the work and move to a different task while the block is being removed. You can easily see how a developer could end up with more than one task.
There is a limit to this scenario. If a developer has too many tasks open, then there is a good chance nothing will get completed. This is the classic “Work in Progress” issue. I am not advocating for this but rather acknowledging that stuff happens and a developer having a couple of tasks open should be manageable.
Conclusion
Prioritizing work is one of the most important duties for a Product Owner. Prioritizing helps the team align internally and will affect other teams externally. Issues are going to arise that cause an individual or a team to drift from the ideal stream of work. Setting limits on what is acceptable will help the team avoid drifting too far from what will be productive.
For example, it is best if each developer only works on one task at a time. If a developer is blocked and can’t get unblocked quickly, it may be best for the developer to grab a second task. If blocks keep occurring, don’t have the developer grab another task because exceeding two open tasks indicates something else is wrong. Maybe the work entering the Sprint isn’t ready, for example.