There’s a revolution underway, and it’s agile, it’s holistic, and it’s big-picture. It’s called “Project to Product.”
The idea behind the “Project to Product” shift grew out of the agile philosophy. With increased teamwork, communications, speed to market, and iteration, agile software development has never been better.
In fact, agile DevOps is poised to move to the next level – from task-based project management to business-focused product management. This broadened perspective elevates the project manager to a product manager.
Agile Project Management
Understanding How Agile Project Management fits in the Project to Product Revolution
There’s a reason that being a project manager has always been a full career path. Particularly in today’s DevOps world of lean software development, the world is moving faster, projects are getting more complex, and the pressure is higher than ever to deliver excellent work, on time, and under budget.
To understand the next wave that is product management, it’s first necessary to have a clear picture of the key ideas behind agile project management and how it’s evolving to agile product management.
Project managers are responsible for drafting the project plan, coordinating the many pieces of the project, identifying risks, and keeping the project within scope and on track. It’s an important role, particularly in DevOps. For these reasons, many organisations have chosen an agile mindset, often utilising the scrum methodology.
According to Simon Buehring, founder of UK-based Knowledge Train, believes that agile project management can help systematise sound decision making. “During a lengthy career in IT, I had seen many projects go wrong. This was often because the people making decisions did not understand the best practices for managing projects, and so ended up repeating the same avoidable mistakes over again.”
“Agile (methodology) boasts flexibility, team collaboration, and iterative delivery,” says Buehring’s Knowledge Train. “This helps teams adapt to changes easily, especially when customers change their minds about what they want.”
Today, as project management is being elevated to a place where the professionals in this career think and strategise beyond the individual project, they are focusing on the impact on the larger product – in the context of the entire business. While agile project management is certainly still a component, it is now a part of the overall business strategy under the umbrella of Project to Product, or “P2P.”
In today’s Project to Product world, the principles of agile project management are non-negotiable. Project-focused principles that had always kept individual project work on track now must fit into the bigger picture within the organisation. This comprehensive focus shifts the project manager's role to that of a business leader. Agile project management, as it evolves to agile product management, is an ideal method in the P2P movement.
Why Agile Product Management?
In a nutshell, agile product management takes an iterative approach to the development process. Rather than releasing in a once-and-never-again linear “waterfall” approach, the agile approach releases a product in increments, entering a continuous product life cycle feedback loop of prioritisation of customer feedback, completing a retrospective, and making incremental improvements to meet customer needs. This nimble method brings projects to completion more quickly and collaboratively. It’s also better for the business as a whole.
Agile product management has become even more urgent in the Age of Disruption. Mik Kersten, Ph.D., author of “Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework” argues that the traditional, tried-and-true IT project management methodology is at odds with the way the world works today. “Tracking activities and budgets provide a false sense of security that may become apparent only when the software product hits the market,” he said. “Worse yet, baking in risk and spending decisions upfront may delay teams in incorporating feedback as the initiative progresses.”
Kersten’s Project to Product paradigm shifts the focus from a siloed, project-centric mindset, to a big-picture focus on the business, serving customers, and nimbly staying ahead of disruptions. In short, the focus shifts from internally-focused project milestone metrics to client-focused business outcome metrics.
“IT leaders can assess software organisations not by the lines of code written or microservices produced, but by how much business value their products deliver to customers,” Kersten said.
Getting started: Agile Planning
What is Agile?
In project management – and especially in product management – an agile approach is a philosophy focused on continuous improvement. Every project has a goal and the desired outcome, and to get from Point A to Point B, a structured and strategic plan is necessary. The agile planning approach breaks down each segment of the project into “sprints.”
Sprints are specifically identified parts of the project, including specific timelines of 1-3 weeks and the specific risks associated with each sprint. Effective sprints also contain OKRs, or “objectives and key results,” that help measure the effectiveness of the sprint and indicate clearly whether the sprint is completed or not. This approach helps to identify risks and delays sooner and helps to keep the overall project on track. It increases collaboration, value, and quality.
The vision behind agile working environments is outlined in the Agile Manifesto.
The Agile Manifesto: 12 Agile Principles for Lean Software Development
In 2001, 17 software developers developed the Agile Manifesto, which includes the 12 Agile Principles for lean software development.
The Agile Manifesto focuses on these 4 values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change by following a plan
This mindset was revolutionary and helped organisations bring software to market faster, which also served the clients better. According to AgileManifesto.org the principles are:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximising the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organising teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Understanding the hallmarks of the Agile Manifesto provides the framework for Agile Planning.
What is Agile Planning?
There are five levels of agile planning commonly referenced:
- Agile Vision
- Agile Roadmap
- Agile Release
- Agile Iteration
- Agile Daily Stand Up
Like all good plans, it’s important to start with the end in mind. For Agile Planning, that means documenting the vision for the project in the larger context of the business. Thinking about the Project to Product movement in Agile, it’s crucial to think about the goal of the project in the context of the organization’s larger goals.
A useful tool for this step is a Product Vision Box. This is a fun and surprisingly useful way to get the team thinking about the vision. It will take about an hour.
- First, break the software team into smaller groups.
- Then, think about the product as if it was a consumer product.
- Next, take a piece of paper, and on the front, sketch a product box and a few selling points. On the back of the paper, include important technical details.
- Then, each team has 5 minutes to “sell” the product to the other teams.
- Finally, the teams can vote on the best elements and agree on a final, unified vision. Be sure to cover the basic bases, such as who, what, where, when, why, and how.
This method achieves the dual purpose of aligning the vision of the team and elevating the team’s view beyond the project – and focusing them on the higher level product goals.
The visioning exercise is a valuable and collaborative first step – but it is actually not an official part of the agile process. Still, with the product vision in hand, you are ready to approach the development of the Agile Roadmap.
An Agile Roadmap is a flexible and visual map of the path to achieving the shared vision. It keeps the teams focused on the strategy, and informs all of the stakeholders and teams working on the components of the project on what should be done, by whom, and when.
Typically, the agile roadmapping process starts with a sprint planning meeting. Powerful software tools like Jira for Atlassian can be extremely helpful to keep projects on track. Jira provides a visual view of a roadmap, backlog, sprints, and reports to manage project workflows. It’s also helpful to have all of the information in one place for version control and to adapt and re-set expectations when any of the moving parts of the projects change – which they always inevitably do.
Releasing the product to the customers is an exciting moment, but an agile release is not the end of the project – it is simply a step along the way. An agile release kicks off a 3-12 month agile release cycle of planned iterations. The iterations within the cycle will run in one week to one-month sprints. During the iterations, adjustments to the product will be made, based on data gleaned from customer feedback, adoption, and usage.
Agile release teams are comprised of cross-functional agile teams within the organization. The teams are sometimes referred to as “agile release trains” where multiple teams work together, using design thinking to ensure the functionality, timeliness, and continuous improvement of the agile release iterations. A best practice of this development methodology is to use automated releases of new features through Jira’s software release hub
Agile iteration is a set period of time where parts of a release are tested and improved. Iterations are generally small sections of the new product which allows the development team to focus tightly on smaller sections of the project. The recommended time period for agile iteration is two weeks.
Agile Daily Standup
Daily standups are a core part of agile product management. However, it’s important to understand what agile standups should be used for – as well as what they should not be used for.
What is an agile daily standup? An agile daily standup is a scheduled and organised huddle, consisting of the key members of the agile team. In the same way that athletes put their heads together before a play, agile team members put their heads together at the start of the day.
Agile daily standup participants should utiilse the scrum board to as a reference point, and each member should briefly update the team on the following:
- What I worked on yesterday.
- What I’m working on today.
- Any roadblocks?
Leaders in product management roles will ensure that the product requirements are met, the user experience is focused on what the customer wants and needs, that the agile product development formula is followed and that the larger business objectives are met.
Gaining Momentum: Agile Coaching
What is agile coaching?
Agile coaching helps teams learn, understand, and live agile values, mindsets, and values. Agile coaching fosters all of the core tenets of agile methodology: communication, collaboration, flexibility, autonomy, and trust.
Like all effective coaching, agile coaching helps the members of the team grow. According to Olympics.com, the qualities of a great coach include:
- Understanding of both the fundamentals and the advanced tactics
- Eagerness to learn
- Sharing of knowledge
- Motivational skills
- Knowing the team members
- Listening skills
- Leading by example
- Commitment and passion
“An effective coach communicates well and exudes credibility, competence, respect, and authority. You should be able to explain ideas clearly. Clear communication means setting defined goals, giving direct feedback, and reinforcing the key messages. Acknowledging success is also essential for good communication.”
An important component of effective agile coaching is pulling together cross-functional teams from throughout the organization in order to better serve the customer. Again, this is the kind of big-picture, executive thinking that elevates project management to product management.
Many organisations provide agile coaching courses and certifications, at a variety of price points. The most important elements of agile coaching are:
- Knowledge and understanding of agile frameworks
- Excellent communication skills
- Understanding of agile tools
A variety of agile tools are available in the marketplace. One of the most tried-and-true project management tools is the GANTT chart, which has existed since Henry Gantt created the first one around the year 1915. More than 100 years later, they are still a functional and visual tool for project management and can be built using basic spreadsheet tools. However, in the era of product management, more sophisticated tools can be extremely useful in keeping the moving parts under control.
Tools like Asana or Monday.com can provide plug-and-play functionality for agile coaches, or it may make more sense to opt for agile-specific options like Kanban boards or scrum boards. These boards are also visual tools. They use cards in columns to illustrate the work needed to be completed at each stage of the project. Kanban and scrum boards can be used in concert with Jira to manage product management workflows. According to Atlassian, “The Jira scrum board is the tool that unites teams around a single goal and promotes iterative, incremental delivery.”
An agile coach helps DevOps teams adopt agile methods while ensuring they also understand the philosophy and reasons behind this approach. An agile coach will have a team that is cross-functional, communicative, and cohesive. Agile coaching, when it’s done well, will lead to better products that better serve customers.
Bring it All Together: Agile Product Management
Now that there is a shared understanding of project management and how it has evolved to product management, it’s time to dig deeper into exactly what agile product management entails.
Who is the product owner in agile product management?
The product manager is responsible for the high-level product strategy and product development leadership. The product owner takes more of a tactical role.
Agile product management takes the agile principles of agile project management and incorporates key teams from across the organisation. This high-level perspective ensures that no team works in isolation, and that every member of the team understands the impact and importance of their role, and how it affects the project and the company.
The teams that would be involved in this elevated product management approach include the DevOps team, the communications team, and the pricing team, brought together by the vision and efforts of the agile coach. This model prevents silos, builds communication and trust across the organisation, and keeps the focus where it should be – on the customer.
While project management is focused on the project, the timeline, the documentation, and getting the project “done,” product management is focused on the customer, companywide transparency and collaboration, and continuous improvement.
Agile at Scale
Agile business processes provide a repeatable framework and proven approach for agile software development. For these reasons, it’s tempting to think about applying agile at scale throughout the organisation.
According to the Harvard Business Review, “When implemented correctly, agile innovation teams almost always result in higher team productivity and morale, faster time to market, better quality, and lower risk than traditional approaches can achieve. What if a company were to launch dozens, hundreds, or even thousands of agile teams? Could whole segments of the business learn to operate in this manner?”
The answer: it depends.
Lean, communicative, iterative, and customer-focused teams certainly sound idyllic. They both depend on the power of human communication and collaboration but have a formula that is repeatable. More than that, the data supports this approach. Why, then, doesn’t everyone do this?
The challenge starts with people and the reality that functions and people do not always fit neatly into off-the-shelf boxes. Even agile teams know this, and agile coaches will often pick and choose agile elements in order to make the system work for their team. This challenge is precisely what makes agile at scale difficult to implement. The reality is that not all functions will neatly transition into an agile approach. Add to that the fact that people can be unwilling to change, and that bureaucracy can make change difficult for even willing participants.
“Agile teams work differently from chain-of-command bureaucracies,” reported HBR. “They are largely self-governing: Senior leaders tell team members where to innovate but not how. And the teams work closely with customers, both external and internal.”
Some leaders may resist this loss of control, despite the decades-long transformation away from command and control leadership into new, empowered, transparent leadership styles. Even with these challenges, the fact remains that agile is here to stay.
Getting into the Agile Mindset
Before jumping into agile at scale for your organisation, it’s important to get into the agile mindset. Agile is a mindset, described by the four values and defined by the 12 principles in the Agile Manifesto, and they are made into reality by practices such as Kanban and scrum.
For agile at scale to work, it’s crucial that leaders at every level understand the agile mindset. The Agile Manifesto is very right brain-focused on emotions and values:
- 4 Values
- 12 Principles
- Ethical, respectful working environment
On the other hand, agile practices are quite left-brained, in that they are analytical and methodical in both form and function:
- Prescriptive actions
- Formulaic communications
For agile teams to function at any scale, it is important to embrace the foundations of the agile mindset – both the social/emotional values, ethics and principles, and the logic and structure of the agile practices.
Tools for Product Management
Although product management is an up-and-coming iteration of the project management profession, Jira software tools by Atlassian are utilized by many agile teams. Workflow features, like roadmaps and reports, can be turned on and off depending on the product manager’s needs.
What is a Community of Practice?
Cross-functional teams are a pillar of product management. However, sometimes developers need to collaborate with other developers. This is where a Community of Practice (CoP) comes in. a CoP is a group of people who “share a concern or a passion for something they do and learn how to do it better as they interact regularly.” This idea of people working on the same team and focusing on continuous improvement was introduced in 1991 by Jean Lave and Etienne Wenger in their 1991 book Situated Learning.
The concept of communal learning and improvement included:
- Domain: area of expertise
- Community: the social fabric for learning
- Practice: focus
Lesser & Storck argue that a company’s performance can be improved by a Community of Practice:
- Shorter learning curve
- Rapid customer response
- Sharing knowledge to stop reinventing the wheel
- Fresh ideas for products and services
It has long been known that “talking shop” can help solve many challenges in organisations. Talking shop via a Community of Practice can be a powerful way for people to learn, share, and retain knowledge. In other words, sometimes developers just need to talk to other developers.
Clearly, communications are key to a high-functioning Community of Practice in DevOps. The CoP will need to meet regularly and be able to collaborate outside of meetings as well. Instituting a CoP within an agile organization can be a powerful tool with extremely positive results.
When thinking about agile delivery of software, the biggest mindset change is the iterative approach, versus “one time” delivery. Agile delivery means that the product is built incrementally over time, and the product backlog is prioritised based on the overall product roadmap, plus user stories and data, and analytics.
Either way, agile delivery is an agile approach to product management that puts people first by focusing on both the customer and the product team. It manages risk by using iteration and data. And it is deft enough and flexible enough to withstand the inevitable changes in scope, requirements, and more.
Agile delivery requires an agile delivery lead, which can also be the scrum master. The agile delivery lead may act as a facilitator for several scrum teams. Like all agile leaders, this person must have an agile mindset, facilitate communications, remove obstacles, coach team members, and take responsibility for the agile delivery of software.
Agile delivery is a cornerstone of the agile product management approach. There are several delivery methods, which provide flexibility to choose the agile delivery approach that works best for your organisation.
From agile planning, to agile coaching, to agile delivery and product management – it is clear that the Project to Product movement is here to stay. With the right knowledge, mindset, and tools – project managers are elevating their careers to product managers, to the benefit of the project, the business, and their own careers.