Many of the problems that companies experience along the way of enhancing the capabilities of their products come from an unbendable reluctance to view them as products. A project management doctrine has engraved itself deeply into the core organizational practices. Yet this doctrine that proved itself efficient before, renders itself as an obstacle to achieving greater productivity in the current market setting. One may say that it comes down to the old battle of waterfall vs. agile, and they wouldn’t be wrong. But a much more important mindset barrier originates from the “new” battle of the Project vs. Product delivery approach.
Please don’t get me wrong, I am not saying that a project-based approach to product development does not work. Many successful organizations are using it to-date and are satisfied with the results. However, in my mind, it solely depends on what level the organizational standards are at. Given enough budget, the work will be done either way. But don’t you want to have much more bang for your buck? This is ultimately what the agile mindset and product / customer focus is about.
How does project delivery work? Let’s say, you are a multi-billion corporation whose main business is vehicle sales listings. You have noticed that your user base has dropped month over month for the past 5 months, and your analysts associate it with a competitor website that provides for a seemingly better user experience.
Now, in order to get your users back, you start a project to improve the user experience of your entire website. Over the next 3 months, your analysts will be working hard to understand what areas of the website could be improved, and then for another 3-4 months they will write detailed requirements for the tech department to implement. Finally, the requirements will reach IT, yet your BAs would probably spend another month or two explaining what is required to the tech people. And then finally the work begins. By that time the budget gets thin, yet you don’t see any results of the project yet, so your management starts pushing IT harder to get the results. And in another 3-6 months and a dozen(s) of cut corners later, a new shiny version of the website is done. Yet, within this year, your users have almost completely transitioned to a competitor’s website. Not to mention their feedback on the new version of the website is mixed. Sad scenario, isn’t it? Yet it is a very real state of affairs for many organizations out there.
And this is why more and more organizations are moving from realizing short-term goals via project-based delivery to investing into continuous and coherent product enhancements. Shortening time-to-market is only one part of the success. More importantly, it’s to build great products.
Product Mindset
A product mindset prioritizes outcomes (not outputs), learning, deep understanding of the user base, and the overall system health.
A product is an organization’s response to a customer’s need or desire that confers a benefit to both the recipient and the provider of the response.
Ownership vs. Management
Whereas projects are delivered according to the software requirement specifications or BRDs that are often written for months by people with a limited understanding of the product and customer needs in question, a product owner organizes work using flexible, adjustable backlogs that are momentarily aligned to ever-changing business needs. When developing products, teams closely collaborate with the customers (directly or indirectly i.e. through A/B testing), and change the products on the go, based on the feedback received.
The product owner prioritizes development of software features based on the ability of these features to add value to the customers, make the product more desirable, and ultimately to generate more return on the investments.
Organizational Structure
Rather than moving from one project to the next, which could potentially be in an unrelated area, individuals within software development departments should be dedicated to products. In order to have people (not resources) care about the products they produce, organizations must stop moving motivated knowledge workers from one project to another, where the measure of success is a mere ability to produce a predetermined output within the predefined period of time. Only when these people can associate their names with the products developed, only when they are invested into the success of the the users’ response to features, and not simply crossing out outputs from the list, only when we give them room for creative realization of their potential, only then we could realize the full potential of the talented people we hire.
Instead of being merely the doers, motivated teams are encouraged to own the success of their products.
Agile Budgeting
However, in order for this approach to thrive, it is not just enough to focus on the customer, identify the products, and allocate people. Quite often, something as trivial as the budgeting approach becomes the main roadblock on the way to a successful transformation.
Each time I’d be talking about the product-based delivery to the PMO, I’d hear the same question: “But how are we going to finance this?” For decades, the budgeting approach was as clear as day: define the scope of the project; create requirements; estimate requirements and build a project plan, assign a dollar amount to the resources and you are done (however, I often see cases where the budget is locked-in even before any version of the project schedule is created).
Changing this paradigm is a much greater challenge for the agilists than driving a mindset change. After all, “bureaucracy gives birth to itself and then expects maternity benefits” © Dale Dauten.
To date, there is also not much literature available to help agilists to deal with this issue. I’m grateful for the SAFe practitioners who have attempted to describe their vision of a solution. However, I believe there is much more to be written in order to solidify the proposed concept.
Nevertheless, the overall approach comes to financing development of the features, rather than financing projects. Some say it’s easy, you simply break down the project to a set of objectives that create business value, and then allocate funds to the highest priority ones… Maybe it sounds straightforward in theory, yet in practice there are many hidden rocks in this seemingly calm, bureaucracy-protected harbour.
Throughout the years of dealing with this issue, I have developed a vision of the working model of an agile, feature-based budgeting approach that I recommend to my clients. However, I will save it for another article. Meanwhile, below is a schematic of a transitory approach that helped a few of my clients to undergo this difficult, yet inevitable step in their transformation journey.
