If you have spent time in agile or project management, you have probably come across both the product manager and product owner titles. They sound similar, they are often described in similar ways, and both are sometimes called the CEO of the product. But they are not the same role, the responsibilities differ and as it turns out, so do the salaries quite significantly.
The Salaries
Product managers earn between $272,000 and $326,000 a year, and more in high-growth environments where stock and bonus considerations come into play. Product owners earn an average of $107,000 a year in the US. Both are strong salaries, but the gap is significant and comes down to scope.
What a Product Manager Does
Sharif Mansour spent 16 years as a product manager at Atlassian, the company behind Jira. He describes the role as driving the development of a product, defining its strategy and building out its roadmap and features.
In practice that means identifying and understanding user needs, monitoring the market, developing competitive analyses and aligning those insights into a clear product vision. From there the product manager prioritizes features and capabilities to deliver on that strategy, aligning stakeholders and teams to turn it into reality.
What a Product Owner Does
The product owner role comes primarily from agile and scrum. The Scrum Guide describes the product owner as accountable for maximizing the value of the product resulting from the work of the scrum team.
In practice the responsibilities look similar to a product manager: developing and communicating the product goal, creating and prioritizing product backlog items and ensuring the team is always working on the highest-value features. The key difference is scope. A product owner typically works with one team on one product. A product manager often oversees multiple projects or multiple teams, operating more like a program manager across the product landscape. That broader scope is largely what drives the salary difference.
Both roles require a strong understanding of the user, the technology and the business. If you are closer to a single agile team, product owner is likely the more relevant path. If you are thinking about product strategy across a broader organization, product manager is the direction to explore.
Also available are my Project Management Templates – these don’t have a coupon code but they’re a great way to save 100s of hours when you’re first starting out:
More than 86% of software development teams have used agile in some form. If you have been meaning to get your head around Agile here is everything you need to know, from the history through to the daily practice.
Where Agile Came From
Agile did not appear from nowhere. It traces back to the Toyota Production System and lean thinking developed decades earlier. Kanban was created at Toyota in 1953. Scrum grew from a 1986 paper called “The New New Product Development Game.” Extreme programming, feature-driven development and several other lightweight frameworks followed.
In 2001, 17 practitioners representing these different approaches came together and agreed on a shared set of values. The result was the Agile Manifesto, which prioritizes individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan.
Agile Roles
Three roles sit at the center of most agile teams.
The Product Owner represents the customer. They maintain the product backlog, which is a prioritized list of features to be delivered, with the highest-value item always at the top. They are one person, not a committee. They have the final say on what gets worked on next.
The scrum master is a servant leader. They help the team remove blockers, facilitate cere
monies or “events” and protect the team’s focus. They are a neutral third party in problem solving to help unblock the work.
The team does the work. In software that usually means developers, but agile applies equally to research, design and any other knowledge work.
How a Sprint (or Iteration) Works
Work is organized into iterations, typically two weeks long. Here is how one flows from start to finish.
Sprint planning kicks things off. The team selects the highest-priority user stories from the product backlog, enough to fill the sprint based on their velocity. Velocity is simply how many story points the team completed in recent sprints. If the last few averaged 25 points, the next sprint is filled to 25. This keeps the pace sustainable.
Every day the team holds a 15-minute standup around the Kanban board. Each person shares their progress and flags any blockers. The goal is to surface problems quickly so the team can swarm around them and keep moving.
During the sprint, backlog refinement happens in parallel. The three amigos (someone representing the customer, a developer and a tester) come together to break upcoming features into user stories, add acceptance criteria and estimate their size relative to each other.
At the end of the sprint, the team holds a sprint review. A real, usable increment is demonstrated to the customer. Not a presentation. Not a report. The actual thing. The customer gives feedback and the backlog is updated accordingly.
The sprint closes with a retrospective. What went well, what did not and what will improve next time. Actions are agreed and carried into the next sprint.
The 12 Agile Principles
The signatories of the Agile Manifesto later published 12 clarifying principles. They are worth knowing.
Satisfy the customer through early and continuous delivery of working software.
Welcome changing requirements even late in development.
Deliver working software frequently, with a preference for shorter timescales.
Business people and developers must work together daily.
Build teams around motivated individuals and trust them.
Face-to-face communication is the most efficient way to share information.
Working software is the primary measure of progress.
Maintain a sustainable and constant pace.
Pursue technical excellence and good design continuously.
Simplicity, maximizing the work not done, is essential.
The best solutions emerge from self-organizing teams.
At regular intervals, reflect and adjust.
Agile works because it is built around real feedback, real increments and continuous improvement. Once you understand the logic behind it, the events and the roles all start to make sense.
Jira is one of the most widely used project management tools for agile teams. Here is everything you need to get from first login to sprint reporting.
Creating Your Account and First Project
Jira is free for teams of one to ten users. Once you are in, create a new project, select Software Development and choose the Scrum template. For most users, Team Managed is the right choice as it keeps your project self-contained. Company Managed is worth knowing about if you have multiple projects that need central administration by Jira admins.
Give your project a name and Jira will generate a short key that appears on every card.
Setting Up Your Epics
Your two main workspaces are the Backlog and the Board. Start in the Backlog.
Open the Epic panel by pressing E or clicking the option in the panel. Epics are your high-level features. Click Create Epic to add one and assign each a different color so you can track which work belongs where as the board fills up.
Building Your Backlog
With epics in place, start adding user stories by clicking Create. Each card can be typed as a story, bug or other work type. Custom types like risks or spikes are available through Manage Types.
Click any card to open its details. From there you can assign it to an epic, set its status, assign it to a team member and add story point estimates. Add a description to capture acceptance criteria and any supporting information.
Creating and Starting a Sprint
Click Create Sprint, set the duration and select a start date. Jira calculates the end date automatically. Add a sprint goal to give the team a clear focus.
Move cards into the sprint by dragging them from the backlog or right-clicking and selecting the target sprint. Keep an eye on story point totals and match them to your team’s velocity. When ready, click Start Sprint and your cards move onto the board.
Working the Board
The board displays your active sprint in columns. Add new columns by clicking the plus symbol on the right and dragging them into position. Custom filters through Manage Custom Filters use JQL (Jira Query Language) to adjust the board view. A simple filter showing only cards assigned to the current user is a good starting point.
Completing a Sprint and Reading Reports
At the end of the sprint, click Complete Sprint. Unfinished cards roll over automatically. Review your backlog, confirm priorities with the product owner and start the next sprint when the team is ready.
After two or three sprints, navigate to Reports to start tracking performance. The Velocity Report shows story points committed versus completed across recent sprints, giving you a reliable average to plan against. The Sprint Burndown Chart tracks work coming down over the course of a sprint against the ideal trend line, making it easy to spot if the team is falling behind mid-sprint.
Using the Timeline as a Roadmap
The Timeline view shows your epics and user stories laid out across time, similar to a Gantt chart. Drag items to adjust dates and use this view to communicate progress and upcoming features to stakeholders. It is one of the clearest ways to show where the product is heading and when things will be delivered.
Set up your epics, build your backlog, match your work to your velocity and use the reports to keep improving. It is a straightforward tool once you know where everything lives.
More than 87% of people working in agile use scrum or some part of it. Yet many teams do not fully understand where it came from or how it was intended to work. The Scrum Guide, written by Ken Schwaber and Jeff Sutherland and last updated in 2020, is the authoritative source. It is free at scrumguides.org. Here is the whole thing explained plainly.
What Is Scrum?
Scrum is a lightweight framework for solving complex problems and delivering value through adaptive solutions. It works best when you cannot know everything upfront. Rather than planning in detail for a future you cannot predict, you deliver something real, get genuine feedback and adjust. That is the core logic.
The Scrum Team
A scrum team has three roles: developers, a product owner and a scrum master. No sub-teams, no hierarchies. Ten people or fewer.
Developers deliver a usable increment every sprint. They create the sprint plan, maintain quality and hold each other accountable. The term applies to anyone doing the work, not just software engineers.
The product owner manages the product backlog: defining the product goal, ordering backlog items by priority and keeping everything visible to the whole team. One person, not a committee. Others can suggest changes but only by convincing the product owner. When organizations trust this role and give it room to operate, decisions get made faster and the product improves faster.
The scrum master is a coach who also clears the path. They help the team stay self-managing, remove blockers, escalate issues and keep events productive. They serve the team, the product owner and the broader organization.
The Artifacts
The product backlog is the single source of work for the team: an ordered list of everything needed to meet the product goal. One product goal at a time.
The sprint backlog is the set of items selected for the sprint plus the developers’ plan for delivering them. Its commitment is the sprint goal: one clear objective that keeps the team focused.
The increment is the real, usable piece of value delivered at the end of a sprint. It must meet the definition of done before it can be released. If it does not, it goes back to the backlog.
The Events
The sprint is the container for everything else. One to four weeks, fixed length. The sprint goal must not change mid-sprint. Only the product owner can cancel a sprint, and only if the goal has become obsolete.
Sprint planning kicks off the sprint (timeboxed to eight hours for a one-month sprint). The team answers three questions: why is this sprint valuable, what can be done and how will the work get done?
The daily scrum is 15 minutes, same time and place each day, for developers only. Inspect progress toward the sprint goal and adapt the plan for the next 24 hours.
The sprint review (timeboxed to four hours) is where the team presents the real increment to stakeholders. Not a recording, not a mockup. The real thing. Together they discuss what was learned and what comes next.
The sprint retrospective (timeboxed to three hours) closes the sprint. What went well, what did not and what will improve next time. The most impactful changes are acted on immediately.
Theory and Values
Scrum runs on three pillars: transparency (make the work visible), inspection (regularly examine progress) and adaptation (adjust quickly when something is off track). The longer you wait to course-correct, the harder it gets.
The five scrum values tie it together: commitment, focus, openness, respect and courage. When a team genuinely lives these, trust builds and scrum works.
Scrum is simple by design. The challenge is not understanding it. It is applying it honestly and giving the team the trust and space to do the work.
If you’re working in or studying Project Management, becoming familiar with the Agile Manifesto is crucial. Although it is brief and straightforward, its principles have had a huge impact on project management techniques for more than 23 years now.
The manifesto emphasizes core values like individuals and interactions, working software, customer collaboration, and responding to change, which have proven to be effective when working through complex situations. The only trouble is – as human beings we somehow cannot wait to complicate it again.
We add processes, extra names, extra functions, extra job roles, heck we even add extra departments to handle all this extra stuff we’ve added. The core of the Agile Manifesto is being corrupted, because it is actually hard work keeping things simple.
But the simplicity in the Agile Manifesto highlights a key truth: simple approaches often yield the best results, fostering clarity and efficiency in software development and project management.
Just as simple, refactored code is easier to maintain and less prone to errors than complex code, simple designs are more user-friendly and effective than their intricate counterparts. Embracing the simplicity of the Agile Manifesto allows teams to focus on what truly matters, leading to better outcomes. And doing that often leads to greater success and effectiveness, helping you and your team win.
The Secret History of Agile: Unveiling the Roots of a Revolutionary Methodology
The Agile methodology, a transformative approach in software development, is often mistakenly attributed solely to the Agile Manifesto of 2001. However, the roots of Agile stretch much deeper into history, with influences from manufacturing and even early industrial practices. Let’s check out the lesser-known origins of Agile, and see how it has really evolved from the 19th century to today.
The Waterfall Model: A Misunderstood Beginning
The story of Agile cannot be told without mentioning the Waterfall model, traditionally seen as the “enemy” of Agile. Interestingly, Winston Royce, who formalized the Waterfall model, came up with a more iterative and feedback-driven approach in his final notes. Royce emphasized the importance of integrating feedback from testing into design and requirements, advocating for an iterative process and customer involvement.
This philosophy, remarkably similar to Agile, shows that even the origins of the Waterfall model came from principles that Agile later embraced.
Early Industrial Influences: Toyota’s Innovations
Agile’s principles can be traced back to early industrial practices, particularly those pioneered by Toyota. In 1896, Sakichi Toyoda introduced the “Stop and Notify” concept, also known as Jidoka or autonomation. His invention of an automatic loom that halted production if a needle broke was revolutionary, combining human oversight with machine efficiency. This concept of built-in quality control is a cornerstone of Lean manufacturing and, subsequently, Agile.
Post-War Innovation: The Birth of Lean and Kanban
The real transformation began in 1948 when Toyota faced severe resource constraints post-World War II. This led to the creation of the Toyota Production System, the precursor to Lean manufacturing. Lean emphasizes waste reduction and Kaizen, or continuous improvement. From Lean, Kanban emerged, a method of visualizing the work to optimize flow. This later became integral to Agile software development.
The Agile Manifesto: A Culmination of Decades of Ideas
Agile as formally recognized today was crystallized in 2001 with the Agile Manifesto, but its foundations were laid much earlier. The Manifesto was influenced by various methodologies, including Lean, Kanban, Extreme Programming, Feature Driven Development and Scrum. These frameworks collectively contributed to Agile’s emphasis on flexibility, customer collaboration, and iterative development.
Scrum: A Revolutionary Approach
Scrum, often synonymous with Agile, has its roots in a 1986 white paper titled “The New New Product Development Game” by Japanese researchers Hirotaka Takeuchi and Ikujiro Nonaka. They proposed a holistic, team-based approach to product development, likening it to a rugby team working together to move the ball down the field. This approach emphasized overlapping development phases, self-organizing teams, and continuous learning—key principles that underpin Scrum and Agile.
The Six Secrets of The New New Product Development Game
Takeuchi and Nonaka identified six characteristics of successful product development teams, which resonate strongly with Agile principles:
Built-in Instability: Assigning broad goals to capable teams, granting them autonomy and flexibility to meet that goal.
Self-organizing Teams: Teams acting like startups, from ideation to implementation, fostering autonomy, self-transcendence, and cross-functional collaboration (the Product Owner idea in Scrum today).
Overlapping Development Phases: Continuous interaction between research and development and production to ensure constant progress and iteration.
Multi-learning: Encouraging team members to pursue ongoing learning, both within and outside their areas of expertise.
Subtle Control: Implementing visual management and maintaining open workspaces to facilitate communication and collaboration.
Organizational Transfer of Learning: Converting project activities into standard practices to spread knowledge throughout the organization.
As you can see there are many similarities between Scrum as we know it today, and The New New Product Development Game introduced in 1986, even if some of the names are different.
Conclusion: The Ever-Evolving Journey of Agile
The history of Agile is rich and multifaceted, drawing from various disciplines and evolving over decades. From Royce’s iterative vision for Waterfall to Toyota’s Lean principles and the collaborative ethos of Scrum, Agile embodies a continuous pursuit of improvement and adaptability. Understanding this deep and varied history not only enriches our appreciation of Agile but also underscores its enduring relevance in today’s fast-paced, ever-changing technological landscape.
For those eager to dive deeper into Agile’s principles and practices, comprehensive courses and coaching can offer valuable insights and practical skills. Embracing Agile is not just about adopting a methodology; it’s about joining a long-standing tradition of innovation and excellence in product development.
See more PMP Articles and Tips for Passing your Exam:
This is the Agile Practice Guide from the Project Management Institute and Agile Alliance, and this particular one is delivering in an Agile environment.
Check out the video and article below!
Delivering in an Agile Environment
There are two things in focus when delivering in an Agile environment, and the first is the team and the project charter. The second is the way we measure results – it can be very different than that of a traditional approach when we’re using Agile. First let’s look at the Charter.
Charter the Project and the Team
Usually in a traditional approach using the project management body of knowledge, which goes through very set steps that will initiate a project with a project charter. It will go through what the project stands for, what the risks are, who the stakeholders are, all those things. It will initiate that project and kick it off.
Now in addition to that when we’re using an Agile approach, our cross-functional team will initiate with a team Charter. What that means is you’ve seen the cross-functional team before where we’ve got the roles like the facilitator, we’ve got the product owner, and they represent the customer or the business. And then we’ve got our cross-functional team members who are those T-shaped members who have a general knowledge of a lot of things and then one really deep specialty knowledge. So these team members are extremely valuable because they might have one deep specialty of development and then many many general knowledge areas such as design or testing or or even leadership. All of those different things.
Our team Charter includes the project vision or the purpose, and this is so important and it’s so wonderful as well. Why? Because we want to start with “why”. Start with why is a classic book by Simon Sinek, and it’s just a wonderful way to get everyone on the same page and make sure everyone is heading in the right direction. “Why” is it that we are doing this in the first place?
Once we’ve got that, we work on a clear set of working agreements and that can involve many different things. When we were working on the purpose and the why we ask the questions “why are we doing this project, who benefits from this project,” and what does done mean for this project? What is the definition of done, when do we finish working? And then how are we going to work together. Now the best role and this can be anyone who has this leadership quality is the Servant Leader, who may facilitate that chartering process sitting down with the team, facilitating everyone, getting them working together and extracting that information from the team.
So they can put it down into words where it may have been hidden before. The servant leader’s role is also to help coach and to help remove blockers.
Now the team charter is also a social contract. That social contract can include things like team values, such as the sustainable pace and the core hours. We’ve talked about the sustainable pace before – we don’t want people to be working the midnight shift and then crashing and burning the next day. Or really going crazy one week and then having three days off sick – it’s just not sustainable, and it’s not a great way to work. From an Agile perspective we want that sustainable pace, and we want to put that down in words. What is that sustainable pace? Do we have set breaks, do we have set hours, what are our core hours, are they late or are they early, does everyone get in at the same time? All of those things, let’s write it down.
We have working agreements such as what “ready” means, so the team can take in work. So when are you ready to take in more work? What done means – so when are you finished that work? And the team can judge that completeness consistently.
Respecting the time box – so they are iterations of two to four weeks, and their work in progress limits. If the team is working in an Agile format where they’ve got cards and maybe they have limits for how many cards they can take on at a time, you don’t want all of your cards sitting in the backlog of work, but likewise you need to make sure that everyone understands when they can take on a new piece of work as well. And that goes in the team charter.
We want ground rules, such as one person talking in a meeting at a time. Or maybe you want a lot of discussion, a lot of collaboration at a time and maybe everyone agrees with that. And we want group norms such as how the team treats meeting times – is everyone on time? Or can someone miss it if they’ve got something really important on? What are those rules and does everyone agree?
Of course you can put any other behavior that the team wants to work with or address. Maybe something has bugged someone in a previous working arrangement and they just want to bring it up and they want to say – “Hey this didn’t work well the last time or maybe this worked really well,” and they want to bring this up and that can go in the team charter
as well.
How Agile Teams Measure Results
As we’re delivering in an Agile environment, Agile teams measure things quite differently to that of a normal project. The way they do that is that they actually measure results in the way that the project is delivered in other words the pieces of the project that are delivered, the functional pieces.
Agile favors value-based measurements, and that’s value from the perspective of our customer. So what are the valuable pieces that our customer can get their hands on and use, and how many of those pieces have we delivered? Instead of normal predictive measurements like Earned Value Management or Schedule Management or cost management that we could use in a more traditional waterfall approach, by measuring what is done and re-planning at each iteration by iteration there’s less room for error and more room to correct course.
And we’ll see that in the way that we measure those results with a burn-up chart or a burndown chart, and these burn up charts or burndown charts are basically these story points remaining. As you can see we might have features and then often many smaller “stories” will make up those features. And features can make up larger increments that we’re delivering to a customer.
The pieces of work that we’re working on as a team – maybe we have a thousand stories altogether in the in the product backlog and then per iteration we might have 20 or 30 or 50, but each time one of those stories is finished we’re marking it off on the chart, so we’re basically counting down the number of stories that we have completed. We want to aim for a certain amount of stories so as you can see here over 10 iterations we’re wanting to
finish that amount of stories but in reality sometimes it is a little bit different. So we can give ourselves a guide but obviously when it’s happening it might fluctuate – it might go up and down or not go at the exact pace that we want it to, because life happens and things get in the way.
So by making it visual and by measuring by the story points and the features that we’re releasing and the things that are getting done and the value that we’re adding to the customer – that is the way that an Agile team will measure results.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile and Lean frameworks from the Agile Practice Guide, by the Project Management Institute and Agile Alliance. There are core frameworks and auxiliary frameworks that you will come across on your Agile journey. Depending on the organization or the team that you work in, usually someone will be using some of these methods. You don’t have to use all of them, as often many of them have the same core practices underneath such as visual management, daily stand-ups, having a product owner, and grooming a backlog.
It’s really useful to know the actual frameworks and the names that
people might be using to refer to them, just so that you can keep up with the conversation and also understand what’s happening underneath – the underlying principles behind these methodologies. This one we’re going to look at involves Scaling Agile methodologies. We’ve got Scrum of Scrums, the Scaled Agile Framework, we’ve got Disciplined Agile, and we’ve got Large-Scale Scrum.
Check out the video and the article below!
Scrum of Scrums
With Scrum of Scrums, it is similar to Projects, Programs and Portfolios. If you’ve worked in project management you’ll know that we’ve got portfolios at the high level, then we’ve got programs underneath that, and we have a number of projects underneath that. It’s just a really high-level approach to managing a portfolio of work.
Scrum of Scrums is conducted when we’ve got two or more teams, usually of three to nine people (most often in a scrum team we’ve got three to nine people so it’s not too big but also not too small) and we’re needing to coordinate all of the work across those teams. A representative from each team will attend a meeting with other team representatives around three times a week. This is very similar to the daily standup but not quite – it’s just a method of keeping everyone on the same page across streams. That representative from the team will attend the meeting with the other representatives from their teams three times a week to report on their completed work, their next set of work, any current blockers in their work and potential upcoming blockers.
This is a really good practice and it’s good to see what other teams are doing. Keeping that
communication line open is important when you’ve got multiple streams of work all working towards similar dates or similar deliverables. The goal is to ensure that our teams are coordinating their work and removing blockers across teams, not just within the team itself.
The way it looks is you’ve got your Scrum teams of between three to nine people. You might have multiple Scrum teams so then one of these representatives will come and report to the Scrum of Scrums meeting three times a week. Then once a week we’ve got the Scrum of Scrum of Scrums – similar to that portfolio level.
Scaled Agile Framework (SAFe)
As part of our Scaling Agile frameworks we’ve also got the Scaled Agile Framework, or SAFe. SAFe basically helps with detailing practices, roles and activities at the portfolio, the program and the project levels, similar to our scrum of scrums.
It focuses on organizing the enterprise around value streams, that provide value to the
customer. We’re focusing on the customer’s point of view. These programs that we’ve got and the projects within them provide this particular piece of value and it’s basically with the end customer in mind, so everything is all organized around that value to the customer.
The principles are to take an economic view, to apply systems thinking (so to understand that this small piece in the system will affect the bigger cog in a system will and so on), in other words nothing is done in isolation and we always think about the consequences of even the smallest actions. Assume variability and preserve options, building incrementally with fast integrated learning cycles.
Does that sound familiar? That’s definitely an Agile principle – we’ve got our iterative approach, we’ve got our incremental approach, all of these things help us get stuff into the
hands of our customers quickly.
We want to base milestones on objective evaluation of working systems. This is Continuous Integration where we’ve got all of our changes going up into the one
environment so we can see whether it’s working or not, and we can see that on a daily
basis.
We want to visualize and limit the work-in-progress, reduce batch sizes, and manage queue lengths. Now that will be familiar to you as well with the visual management approach of Kanban. We’ve got the Kanban board and we can clearly see the work and whether it’s flowing through the the value chain, or our team value chain, from the backlog on the
left to done on the right. We can clearly see whether it’s flowing or whether it’s stuck.
We want to apply this cadence for synchronizing with cross-domain planning, and that is where our scrum of scrums will come into it. So now we’re planning with other teams and we’re helping other teams remove blockers, and we’re making sure that we know what’s
happening across streams as well.
We want to unlock the intrinsic motivation of knowledge workers. This is something that I haven’t seen mentioned in any other part of Agile, but it really is a core part of Agile. In fact the all of the practices that we perform as an Agile team and their core methods will actually help unlock that intrinsic motivation. That’s where you’re motivated internally as opposed to just motivated by money or a bonus or something similar like that. We’ve got things like checking in with with our team and making sure that everything is really clear, helping bring meaning to the work by making sure the work is connected to the customer. All of those things really help with the intrinsic motivation.
We’ve got decentralizing the decision making, and that comes across with our whole team approach where we have all the people involved, not just you know one person or one team.
Large Scale Scrum (LeSS)
As part of our scaled Agile frameworks we’ve got Large Scale Scrum, also known as LeSS. LeSS aims to organize several development teams towards a common goal by extending the Scrum method across teams, similar to scrum of scrums.
Because of that you’ll see some similarities between LeSS and Scrum and some LeSS techniques have been added to scrum. These similarities we’ve got one single product backlog, we’ve got one definition of done for all teams so everyone is on the same page. We’ve got one potentially shippable product increment at the end of each sprint (and we’ve touched on that many times we’ve got a sprint of two to four weeks and we’re showcasing an increment to the customer at the end of that so that they can see whether we’re on the right track or not and that’s our potentially shippable product)
We’ve got one product owner, who is someone representing the customer. We’ve got complete cross-functional teams – that’s our T-shaped person, our generalizing specialists with one specialty area and many general knowledge areas.
We’ve got one sprint and sprint planning is more formally divided into two parts of what
and how.
We’ve got organic cross team coordination, we’ve got overall cross team refinement (an overall retrospective focused on cross team improvements). This is where we take all of those normal scrum methodologies and we apply them across all teams. For example that retrospective where we can get all of our teams together and say what’s working well
across our teams, not just within the one scrum team itself.
Enterprise Scrum
Enterprise scrum is a framework designed to apply the Scrum method at an organizational level, not just at a single product development effort.
It advises leaders to extend the use of scrum across all aspects of the organization and to generalize the scrum techniques to apply easily at those various levels. We are wanting to scale the scrum method with supplemental techniques as necessary – core principles like stand-ups, retrospectives, Kanban boards and visual management, having iterations and
increments and all of those things.
In other words we’re not precious about which scrum techniques we’re using, but we can add to them whatever we feel works for our teams as long as it helps us scale that method across teams.
Disciplined Agile
Lastly for our scalable methods we’ve got Disciplined Agile. DA is a process decision framework that blends various Agile techniques based on the following principles:
People-first
Learning oriented where we’re encouraging collaborative improvement,
Full delivery lifecycle, where we’re promoting fit for purpose life cycles
Goal driven, where we’re tailoring processes to achieve specific outcomes so we’re looking at results over the process – that’s one of the core things you’ll see in Agile come back time and time again.
Enterprise awareness, where we’re offering guidance on cross departmental
governance. That means we’re still managing across teams whether it’s by
any of these scalable techniques that we’ve seen or just a scalable scrum
technique that seems to be really the core common denominator across all of
these scalable techniques.
Lastly, Scalable, covering multiple dimensions of program complexity and doing that in such a way so using the Agile techniques where we’ve got Visual management across streams and Scrum or stand-ups across teams
All that can help us scale this this approach and help all of our teams work together.
And those are the auxiliary methods and the scalable methods of Agile.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile Practice Guide from the Project Management Institute and Agile Alliance. This one in particular is “Evolving the organization.”
Check out the article and video below!
Evolving the Organisation
When we say evolving the organization, really what we’re talking about is bringing Agile into an organization in a way that also uses the Agile methodology. Maybe traditionally you’ve been using a more linear approach, very step-by-step, very focused and figuring out all the scope and cost upfront, and then being afraid when all that changes as the project rolls out.
But if we’re moving towards more of an Agile approach it’s really recommended that we undertake that work incrementally. In other words we’re actually using Agile, and our Agile way of putting things in the hands of our customers (which in this case is our teammates and our organization) then we’re using that to actually roll it out so we treat the change as an Agile project with its own backlog of work, and backlog of changes or Agile things that we could implement and that could be introduced to the team, based on the perceived value.
In this case our team is the customer so whether you’re leading a team or maybe you’re trying to implement it across an organization, but either way the customer in this case is other people who you’re moving the implementation of Agile onto. That means that the value has to be based on what they perceive the value to be, and that’s very important.
Iterating Towards Agile
When we’re iterating and getting that feedback from the customer as we’re implementing Agile, then we’re putting that feedback back into the process and using what works and discarding and what doesn’t. So when we are are implementing practices like Scrum or Kanban or Feature Driven Development, or maybe Scrum of Scrums across multiple teams, or many other things like the whole team approach and regular feedback using iterations – each of those changes can be treated as an experiment. They can be tested for a short period of time to determine the suitability or need, or to further refine it.
What that means is we don’t have to say “Look everyone, this is happening!” We can instead say “Let’s try it out for one or two iterations,” in this case using Agile terminology again, say four to eight weeks in total, and then let’s round back on it using a Retrospective where we ask is this working well, what didn’t work well, what did I learn and what still puzzles me during this implementation.
Then we can put that feedback back into the process.
Using the Agile Method of Kanban to Track Progress
We can also use Kanban boards to track the progress of the things that we’re implementing – showing the new approaches to use as “done” and the things that we’ve tried as or we’re currently trying as in progress. Again this is another Agile approach. We’ve got all of these things that we want to implement in the backlog – maybe we’re going to move to Scrum, maybe we’re going to use Kanban, maybe we’re going to use the Whole Team Approach or a cross-functional team and some of those will be moving those across into “in progress” and some of those will already be finished.
Assessing the Current Culture
We’ll have gone through that retrospective process to find out what worked, what didn’t work, what we want to keep and what we want to discard. Now before we get into all of this or to start implementing these changes we can assess the current culture and its readiness for a job and tailor a solution to suit.
As we’ve seen there are quite a few different methods and practices that we can use in Agile and not all organizations will want to use all of those practices. One model that we can use to find out what would suit an organization is where we ask:
Do we value exploration more than execution for example, maybe we really really just need to deliver things and we need to deliver things quickly and in that case maybe we can increment and deliver increments every two to four weeks on a regular basis. Or maybe we want speed or maybe we’ll want stability in the team. Which one is more valuable?
Maybe we want quantity maybe we want quality. And maybe want flexibility in our work or maybe want predictability in our work. This will just help us determine which of the Agile practices will be valuable from a team’s perspective. You could use any framework really when you’re figuring this out and what to use from an Agile perspective but the key point is that we want to be understanding the team. Whether it’s just going and talking to the team and saying “Hey what are you currently doing, would this work, can we use it as a test?” and we then get feedback on it, let’s work together. The whole point is delivering value from the perspective of your customer, and in this case the customer is the team.
And that is evolving the organization from an Agile perspective.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
We’re looking at the Agile and Lean frameworks from the Agile Practice Guide from the Project Management Institute and Agile Alliance.
We’re looking at this because as you go along your Agile journey, you’ll find many core methods, and people may call themselves an Agile team and use only one or two of these methods. That’s often fine as long as we’ve got the core Agile practices as part of that – things such as the whole team approach, daily doing stand-ups, retrospectives. Many teams will have some of these core methods and sometimes even some of these auxiliary methods that they’re practicing as an Agile team or an Agile company.
This one we’re going to look at is the Agile auxiliary methods of Agile Unified Process, DSDM or Dynamic Systems Delivery Method, and Behavior-Driven Development.
Check out the video and article below, now!
Dynamic Systems Delivery Method
Dynamic Systems Delivery Method or DSDM was designed to add more rigor to the rising iterative methods of the 1990s. It’s most known for its emphasis on constraint-driven delivery, which sets Cost, Quality and Time in the beginning and then uses formalized prioritization of scope to meet those constraints. In other words, it’s meeting up with the Agile approach of having fixed time, where we’ve got our fixed time boxes of two to four weeks depending on what your team has arranged or has agreed on and then a set time frame for delivering the product. The cost might be fixed as well, and the quality – we always want high quality and that needs to be fixed within an Agile team. However, we can adjust the scope as we go along. And as we iterate with our product, yes, sometimes that product will change and the requirements might change when a customer sees it and just has a little bit of feedback based on what we’ve been developing.
Eight principles guide the use of DSDM. We focus on the business need, and there are many different ways of doing this within Agile. The product owner represents the customer, and we’ve got reviews of the product every two to four weeks so the customer can see, feel and touch it and make sure that we’re on the right track.
We’ve got delivering on time, collaboration, never compromising quality, and building incrementally from firm foundations. We’re making sure that we understand what the main feature and the main product is going to be, as part of our feature-driven development (that you might recognise) and then building incrementally – building those features out from those firm foundations.
We’ve got developing iteratively. So making sure our customer can see it by performing those reviews at the end of our iteration. This means a customer can see what’s going on and make sure that we’re on the right track and adjust if necessary.
We’ve got communicating continuously and early – that’s part of our daily stand-ups that you might recognize, and we’ve got demonstrating. control, using the appropriate techniques and prioritization of scope.
We’re making sure that the product owner is involved and making sure the customer is involved in prioritizing the scope that they want to see, and we develop what’s most valuable to them.
Next, we’ve got Agile Unified Process or AUP as well. The intent of AUP is to perform Iterative Cycles across seven key disciplines and incorporate the associated feedback before formal delivery. So someone using AUP will have these disciplines within a release:
We’ve got the model implementation, testing deployment, configuration management, project management, and the environment. All of these are the disciplines of AUP.
But the principles guiding those disciplines are: we want to make sure that the team understands and has clarity and knows what it’s doing. We want simplicity with what the team is doing- so we don’t want complex things just for the sake of doing that. We want agility – so the ability to adjust and change quickly if needed. Focusing on high-value activities, of course we’ve seen that many times with the Product Owner getting involved prioritizing that backlog of the highest value activities for the customer. We’ve got tool independence, so things can function on their own if necessary – if one item goes down, it doesn’t bring the whole thing down. We’ve got tailoring to fit and situationally specific.
Lastly, we’ve also got Behavior-Driven Development as one of our auxiliary methods to Agile. This is another simple way of defining these stories or the features from the Customer’s point of view, and it’s a great way to define those when you’re performing collaborative user story creation. So when the whole team is getting together, creating that user story based on all the different inputs from the tester, the developer, the designer, the product owner, we make sure everyone has an input into that so that it’s a wholly created card from the customer’s point of view.
With BDD, we’ve got “Given” some initial context, “When” an event occurs, “Then” ensure some outcomes. So given this system is in this mode, when this happens then we want that to happen. And that’s just a nice way to describe it so everyone is on the same page.
Those are some more of the auxiliary methods of the Agile and lean frameworks.
Want to learn about Lean? Get the book "Five Minute Lean", by David McLachlan - a wonderful book that blends teaching of the tools, culture and philosophy of traditional Lean with a modern-day Lean parable.
You can get the whole book on Amazon here and enjoy your own copy.
Sharif Mansour spent 16 years as a product manager at Atlassian, the company behind Jira. He describes the role as driving the development of a product, defining its strategy and building out its roadmap and features.
50+ Project Management Templates in Excel and PowerPoint (Gantt Chart, Risk Matrix and more!)
Pre-made Project Management Plan Templates: Save 100 HOURS!
A Simple Manifesto for Complicated Humans
The Secret History of Agile: Unveiling the Roots of a Revolutionary Methodology
