The central tool of managing work in Scrum/Agile teams is the backlog, "an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product." (ref)
And that's mostly true. But it doesn't reflect the reality of Agile, especially for Product Managers with an entrepreneurial spirit (hmmm... all of us). The reality of Agile is that there are three "logs" - the Backlog, the BLACKlog and the Dreamlog. In this post I'll share which of these are normal, which are healthy and which are dangerous and how to fix them.
Let's start with your backlog, since that's the one log we all have!
I take the definition of the Product Backlog provided by Scrum at face value, because it is a good one. The Scrum Guide is quite explicit about the many ways in which Product Owners collaborate with the Scrum Teams and other stakeholders in managing the backlog. Simply put, smart Product Managers know they need help in managing the backlog.
Unfortunately, not enough Scrum practitioners follow my lead. They follow simplistic, and incorrect, views of a Scrum-centric Product Manager who is solely managing the backlog. In this model, the all-knowing and all-powerful PM not only sets the vision of the product, they define and prioritize all of the backlog.
HA! Good luck with that.
And best of all? Our customers help us improve our products and services through design jams, joining us for Sprint reviews, trying out ideas in our preview system and sending us loads of feedback.
And you know you're customers and partners are Agile when they send you feedback as a user story. Here is one just today from Certified Conteneo Collaboration Instructor Raphael Goumot:
Hey Luke, could you add this to your backlog?
As a facilitator of a Conteneo forum,
I want to drive every participant to the same zone (forced zooming)
in order to focus conversation and align the participants.
Yes, we added that one to our backlog!
So, if we have a Backlog, what's a Dreamlog? And do you need one?
Our Dreamlog is our repository of our hopes and dreams for our product. It is, admittedly, a bit of a tangled mash of "stuff" drawn from:
Our philanthropic ambitions: How can we make sure our server grid can scale to support the millions of simultaneous forums we're planning at Every Voice Engaged Foundation-a topic we'll explore at Engage the Bay, our upcoming conference on civic engagement, Dec 8/9 at NetApp in Sunnyvale, CA.
Cool and crazy things we see: Did you see that awesome data visualization from the team at Tableau?
Our Dreamlog inspires us to "keep going when the going is tough", challenges us to think about the world in different ways, opens our eyes to the awesome new ideas from other companies (including competitors!) and keeps us searching for the deepest understanding about our customers truly unmet needs and how to solve them.
I'm willing to bet that you have a Dreamlog too. Good! Dreamlogs are natural, healthy, wonderful things. And if you have one, you should share it: talk about it, build on it, nurture it and let it nurture you.
I'll go even further: We created Conteneo because we're committed to making the world a better place. We didn't create Conteneo because we had, or wanted to get, VC funding. And we didn't create Conteneo so that we could flip it. I'm not saying that striving to get VC funding or building a company to flip is bad. If that's your cup of tea, by all means drink it. I just don't know of many (any) sustainable, truly remarkable organizations who focus more on getting funding or flipping than on solving important customer problems. Put another way, we like to talk more about our customers and actual revenue instead of the amount of our funding, which makes Conteneo a bit of an anomaly in Silicon Valley and helps explain why we keep growing when some of our competitors have run out of funding and have therefore stopped improving their products.
And if you don't have a Dreamlog? Oh my. That's a tough one. I don't think I could work on any product that didn't have a Dreamlog. It would be dead, lifeless, uninspiring. If you really don't have a Dreamlog for your product I feel a bit sad for you and strongly recommend that you find a product with a Dreamlog that inspires you to realize the best parts of yourself in service of others.
As for our Dreamlog, more of it will be coming true soon with the forthcoming release of an entirely rewritten platform - Conteneo Weave.
I define the Blacklog as
the work that Scrum teams do that is purposefully hidden from management because management doesn't care, doesn't support, doesn't agree with, or otherwise doesn't want to understand or acknowledge.
Blacklogs are a sign of a dysfunctional organization - one that may or may not be trying to practice an Agile method, and certainly one that does not embrace the values of Agile, Scrum, Lean Kanban, or whatever other major Agile method the organization has chosen.
I see blacklogs all of the time, especially in organizations that are struggling with some aspect of their Agile transformation. Here are three of the most common blacklogs I see:
Technical blacklogs: These are blacklogs for technical work that a team must do that the PM chooses to ignore. For example, deploying code into production, upgrading libraries, or addressing a security vulnerability are all legitimate work and should be put on the backlog.
Investigative blacklogs: PMs like me are an incredibly demanding, often curiously demanding bunch of people. We'll see something, recast it for our own products, and then ask our team to build it - often forgetting that our teams need time to investigate and learn new technologies. Simply put, when my team asks for an investigative story, I always say yes (though we do negotiate the priority ;-).
Iteration blacklogs: The mad rush of the world to churn out features has converted Agile from its roots of Iterative-Incremental development to pure incrementalism. That's a huge mistake. Teams need the opportunity to iterate on things they've accomplished - even when the software is working just "fine".
I find that there are two common root causes to blacklogs.
Lack of Collaboration between business leaders (PMs and related stakeholders) and development/production/operations teams.
Rejection of Reality that sometimes things take longer than we want, that new features have to be delayed to address a security vulnerability, or that developers need time to learn.
The simplest way to get rid of blacklogs is to insist that all work - 100% - every single bit of work - that the dev team undertakes is represented on the Backlog. This ensures that you're arguing (collaborating ;-) about the full set of work that needs to be undertaken by the team to produce the Whole Product. And we have a whole boatload of collaborative frameworks to help you do exactly that!
This is a tough ideal, and candidly, I know that sometimes even I fall short of this goal (like when I asked our designer to help fix an image for a newsletter - he just did it - but I really should have put it on the backlog). Fortunately, our team has a high degree of trust and discipline (normally, one of us would have put it on the backlog and then prioritized it accordingly in a transparent way).
What's your Dreamlog?