Over the last twenty years Agile methodologies have revolutionized the Information Technology (IT) world. The basic premise of Agile as an approach to software development can be best summed up in with these statements taken directly from the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Taken directly from the Agile Manifesto, this succinct summary encapsulates the shift in mindset and approach to delivering quality software solutions. Despite being written 20+ years ago and most people in modern business being familiar, true adoption of agile approaches remains relatively scarce.
Most leaders are somewhat aware of business agility, mainly in theory, but there is evidence to support the fact that true agile remains an approach only adopted by some and not most companies worldwide.
The impact Agile has therefore had on the project management profession is something that should be looked at in some detail because modern software development has been rapidly changing and continues to do so, but so many companies are failing to genuinely respond to this change. Is this because they have “legacy” mindsets? Is project management somewhat of a legacy role?
This leaves us in a position where we ask ourselves:
To what extent is the increase in the adoption of agile as an approach transforming project management?
Project Management in the Long Term
Will product management eventually replace project management as more companies realize the need to think more long-term and less “project-like?” This piece explores these questions and more. Let’s first define product and project management.
Product Management is an organizational function that guides, manages, and directs all phases of a given product across a product’s lifecycle. The typical lifecycle of a product typically consists of market positioning, pricing, design, testing, implementation, launch and maintenance.
Project Management is the application of processes, methods, techniques, experience, and knowledge to achieve specific project objectives.
Traditionally, projects are temporary, comprising of build-only teams designed to implement a set criterion of pre-agreed targets in each period. Projects are typically planned to robust deadlines and budgets, targets that fall out of this must be accounted for by the Project Manager who remains accountable for why.
Is Project Management Optimal for Today’s Products?
There is nothing “wrong” with this approach… Or is there? Afterall, entire professions have been successfully established and industries have been moulded around project management.
Project initiation is when all stakeholders know least, this is the proverbial “finger in the air” moment in which most of the work is guess work, fanciful or best-case scenario (if the goal posts don’t move etc.,).
But is this optimal or realistic? How many of us have been on project teams that were delivered on-time and on budget? Over entire careers, you’ll struggle to find any professional who has been part of any project team, either as a stakeholder or a project professional who could attest to project completion where time and budget factors were met consistently. Most professionals will attest to the reality that project timelines slip, and budgets seldom contain costs.
So, what does this have to do with Agile?
Before we dive into the implications of what this means with agile, we should also note that projects are temporary and upon project completion project teams usually disband and folk go their separate ways. Typically, unfamiliar operational support teams are then hired to support the ongoing functionality, improvements, and maintenance. If more enhancements are required then a new project team is assembled, and a new project is initiated, and the cycle starts again.
The key takeaways are:
- Projects are temporary
- Newer teams are brought in once the initial phase has been delivered
- Planning is done when the least is known
- Teams tend to be build-only
- Myopic in nature
Why This Approach isn’t Modern
This may seem normal and that is because it is, it is very normal for companies to operate in such a myopic, short-term, and relatively narrow way. Projects in and of themselves are not bad, but software development, product management and customer expectations are and have been rapidly changing over the last 20+ years and antiquated approaches will lose and is losing companies big, certainly in terms of attracting the best staff, staff retention, scalability, customer satisfaction and sometimes profits.
According to an article from Nash Tech agile adoption is slow for two main reasons: large companies desire for predictability and long-standing traditions.
“Whether it's about cost or outcomes, predictability is important to large organisations as small mishaps may lead to large regulatory or financial impacts. Big firms want to know upfront what they're getting, which often means extensive requirements documentation.”
According to a report from Capgemini:
“Scaling agile leads to significant value upside, yet only a handful of organizations are successful at it.”
Products not Projects
In today’s world, products are considered long-term, value-creating assets that require permanent teams who iteratively expand and elaborate on design, develop, test, integrate, document, support and maintain products until business outcomes are realized.
The distinction is subtle and nondescript, but this is exactly why is it so important. Rather than assemble a temporary team who disbands once an MVP has been delivered or the project runs out of money (which is a very real reality), contemporary product management from the outset is medium to long-term in approach, as the agile ethos is embedded within its approach, style, expectations, and day-to-day practices.
A high-performing team continuously and consistently inspects and adapts until the customer’s problems are eradicated; and the team retains that knowledge and experience and builds upon it going forward. Moreover, the team and customer are aligned and collaborate in sync, reflecting the agile principals of:
- Individuals and interactions over processes and tools
- Customer collaboration over contract negotiation
A role at any technology titan such as a F.A.N.G (Facebook, Amazon, Netflix, Google) company will almost certainly have this, agile, product led and customer facing ethos embedded into the smallest and largest teams. We can therefore learn a great deal from the most successful tech companies who have agile product principles at the core of their internal operations.
Are Projects Hindered by a Lack of Agility?
It is becoming increasingly certain that the project approach is becoming a hinderance for progress as opposed to helping. Organizations most effectively deliver value when they use this formula:
AC + OC > V = actual cost + opportunity cost > value.
When the actual cost of working on a product’s additional requirements plus the opportunity cost of not working on a different opportunity is greater than the expected value of delivering those remaining product requirements, the team pivots to developing the more valuable opportunities.
This pragmatism isn’t absent in the project world, but it is far easier to pivot and shift in an environment in which responding to change is a given, an expectation and is welcomed. This is a far-cry from the rigid world of Waterfall in which changes to code is followed by the expensive “Change Request” world, adding time to every other part of the development-lifecycle.
The fluid methods in which product management is realized versus the robust project management style is at odds due to technology’s evolving landscape and expectations and by now and for today’s world, there should only be one clear winner in most cases.
Fundamental difference between Managing a Project vs Developing a product
There are three main differences between managing a project and developing a product:
1. Products respond much better to stable and long-lived teams as opposed to temporary teams
2. Products can bring both short- and long-term benefits. Apps are never “finished” per se, they keep evolving over time.
3. Products are part of a portfolio designed to maximize value and benefits over following specifications
Permanent team over temporary team
Working on a project team creates a complex and interesting dynamic. An almost immediate camaraderie must be formed if morale is to be built and maintained and project goals are to be met. On the other hand, all involved are aware that the project is temporary. Longer-term projects may benefit to greater team cohesion due to the duration of the project, but all parties know that once certain goals are met, the team disbands, and a new team is formed.
The product world tends not to operate like this. Long-lived products are best developed and maintained by long-lived and even permanent teams. The longer the team works together iteratively, building, testing, deploying, and expanding an emergent architecture, with added capability and high performance, the better the customer understands and empathizes with the customer.
Because project teams regroup less frequently, the same bond isn’t formed. When working with stakeholders who have day jobs, or Business-As-Usual (BAU) projects can be seen as a hinderance to their normal workflows.
More Differences
Another key difference is the knowledge transfer within a product team tends to be retained because it is the same personnel, whereas, within the project world, teams and people change. A lack of proper knowledge transfer of key processes, documents, ideas, expectations and so on represents a waste of resources. Stable permanent teams enable transparency, inspection, and adaptation (empirical process control).
Products are long term assets rather than short-term deliverables
Product development is risky. In Marty Cagan’s book Inspired Cagan speaks about HP and a product that bombs despite great media reviews and internal satisfaction from the business.
“The product was a complete failure in the marketplace. Yes, it was technically impressive, and the reviewers loved it, but it wasn’t something people wanted or needed.”
Because product development, especially at the beginning is riddled with uncertainty, agility is exactly what we need! Working on a project for a few months, giving it to users to test only to find out that the bulk of the functionality is wrong happens so often. This is because so much was committed at the start, plans were stuck to and not changed until users used the functionality and were unhappy; the time lost is irreversible and the frustration from SMEs and developers alike can really impact staff morale, staff retention and the business as a place to work.
An active product assimilates user feedback and cooperation almost immediately and continuously, not only for requirements gathering, but for continuous testing, feedback, inspection, and the like; something that takes place in the project world, but in a far more rigid way, often resulting in a loss of time and an incorrect piece of functionality.
Agile is better for product development
Three main reasons why agile is better for the development of products:
1. Project success rates
2. Scope creep
3. Inspection and adaptation
Project success rates
Agile approaches of prioritizing by business value and risk usually means early success or failure. A key benefit to agile is frequent testing throughout the product development lifecycle and this ensures that problems are identified early, seldom is there a situation in which 7-10 months of development has taken place, software is delivered, and the users realize what has been delivered is wrong!
Scope Creep
Whilst following agile principles, new requirements can be accommodated at the beginning of a new sprint. Because you develop a prioritized backlog first, scope creep is eliminated because requirements have been ranked and filed by a product owner. Also, change is welcomed in an agile approach.
Inspection and Adaptation
Greater transparency and clarity are critical to agile. Unlike the Waterfall approach in which development takes place in distinct phases and in silos, progress is regularly inspected. Due to this, teams are malleable and can pivot to business needs in a more pragmatic and fluid way. If the agile approach Scrum is adopted for example, the end of every sprint will contain a review and a retrospective.
During the work there is a daily session in which developers opine their progress. The point is, there are regular intervals in which progress (or lack of) is inspected and this provides ample room to adaptation.
Conclusion
As we rapidly move through the digital transformation of virtually all industries it is surprising that so many businesses are still adopting projects in the traditional, waterfall and rigid way. Product development enables and facilitates a new mindset and approach that leads to high-quality, long-term and more customer-oriented products.
