Product Management Methodologies – an overview of Agile and Lean

Skilled professionals nowadays, besides being skilled on technical matters, are supposed to know how to operate according to the principles of modern product management methodologies such as Agile and Lean. The traditional waterfall approach of gathering all the requirements, design everything as a whole, develop everything and test everything before deploying has been superseded since it cannot bear the demand of a quick time to the market of modern times: it is very likely that the delivery comes too late, when the service is no-more needed. The aim of this post is to explain what you should know about  Agile and Lean methodologies so as to operate into teams that use them.

Should I use Agile or Lean?

This is a typical question: both of them are aimed at achieving business goals and delighting customers with a competitive product of the best possible quality. However they serve different purposes and tasks: while Agile is a subset of some of Lean principles and practices, Lean is wider since its smart approach is not limited to mitigate time loss: Lean influences all types of losses such as money, labor, energy, and so on.

We begin our discussion from Agile, since it is the methodology that it is more likely the reader will meet in the IT field.

Agile

It has born in 2001, with the aim of specifically improve software development productivity, publishing the "Agile Manifesto"; any team that follows the following 12 values can be considered Agile:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

In Agile development, customer value is delivered in small increments, gathering feedback from customers that is synthesized and used to inform the next stages of the process. This, besides resulting in a quick time to the market, let the development quickly react  and adapt to changes depending on the received feedback.

One of the main benefits of this approach is the ability to adapt and change at any step depending on feedback, market conditions, corporate obstacles, etc. and to supply only products relevant to the market.

There are several methodologies that can be applied to Agile principles, such as SCRUM, eXtreme Programming (XP), Feature Driven Development (FDD), ... in this post we quickly examine only SCRUM, since it is probably the most commonly used one.

Whenever you get involved in a project you must talk to the product owner to define the macro scope of the product: neglecting this obvious thing leads to catastrophic outcomes sooner or later, because of the 2^nd value - if you do not identify and set a macro scope (and this does not mean that you are not working Agile), sooner or later you'll get requirements that are so in contrast to the pillars of  your design that you won't be able to fulfill them without a complete rework - that in turn is start another project. Of course there are people that don't admit this, but when the rework goes beyond a certain degree - and so it becomes a re-design, ... the most obvious and wise choice is to start another project, with a different design, with different specialists and so on.

As an example, consider  a customer providing "means of transport" as the project requirement: if you do not set a macro scope to their expectations, it will wind-up pretty much as follows.

Let say you start by delivering a bike: this can be a list of the next requirement an deliveries iterations:

1. they ask you for something that can go faster and that can move by its own:  you add a motor, and you rework it as a motorbike
2. they say that they want it to spare people from getting wet if it rains: you transform it into a car
3. they say that it is required to transport at least 40 people, ... you turn it into a bus
4. they now say that the market require to transport hundreds of people, ... well, you have to remove tires and put it on the rails, that's a lot of rework, but it can still make sense
5. they eventually say that the market is requiring it to fly

Here you fail to meet their expectations: you are not able to improve the product at the next cycle, ... but is it really your fault or are they too demanding? It's your fault: you have not defined the macro scope, and so you are not able to meet the customer's expectations. If you initially agreed for a land vehicle you'd be able to always satisfy requests.

By the way, in this example the customer is lucky enough to ask for the vehicle to fly at the 5th iteration, ... there are people that if the customer asks for this as the 3rd or even 2nd iteration will simply find a way to attach wings to the bus or to the car. I don't think that it will fly very well - of course the requisite is just "fly", but ... for Lord's sake, this reminds me of something that really happened.

The point however is: since the vehicle was born as a land vehicle, the "flying" requisite is not related neither reasonable - it's out of scope. If they really need something that can fly, ... it is a requirement that is too far from the other ones, that requires a completely different design, made by people with different skills and so this is another project.

Be wary that defining the macro scope is not so trivial as it can look like: let say you agree for a flying vehicle as the macro scope - development cycles will somehow be as by the following list:

1. hang gliding
2. glider
3. single engine airplane
4. multiple engine airplane

Now your customer says that they need to use it to refill the International Space Station.

Well, here we go again. I think that we got the point.

And of course I think you got that you must clearly write the overall scope you agreed within the Product Data Sheet (PDS) - this is a quite short document (often less than three pages) that must be produced before the beginning of the development, used to describe the project, highlighting its aim and overall scope, the business values it produces, the foreseen milestones, estimated costs and so on.

Lean

Lean is a philosophy born in Japan in the mid-1950s at Toyota mainly aimed at loss reduction and sustainable production. In the 2000s, Lean was adapted for software development by Mary and Tom Poppendiecks who related it with 7 initial Lean principles and Agile philosophy.
In 2008 Lean was applied in the startup industry by Eric Ries as a way of developing "new products and services in circumstances of extreme uncertainty." In his book "The Lean Startup'' he states that a startup is considered "Lean" if it meet the following 5 Lean values:

• Entrepreneurs are everywhere
• Entrepreneurship is management
• Validated learning
• Innovation accounting
• Build–Measure–Learn

Lean principles are a subset of System Thinking that requires a never ending cycle made of action-loops that consist into

• learn
• measure
• build
• thoroughly test

In addition to that, Lean pays particular attention to customer's feedback considering it the ultimate value to be used to continuously improve. It is a smart development that improves everything by eliminating everything that doesn’t bring value to the customer. This approach, besides reducing the time to the market, helps to figure out what the market actually wants and adjust the direction from time to time. The most commonly used Lean methodology is Kanban.

SCRUM

Scrum is an iterative incremental time-boxed methodology suitable to implement Agile, aimed to manage things so that they will be done in the right time. Everything start from a project with

• a clear (although not detailed) vision of what should be achieved stated on business needs rather than in technical terms
• vague details on how and when to achieve the goal: they becomes clearer and clearer as the project moves forward

A project can either be a software to be developed, a new service platform to be installed into a site, the upgrade of an existing one and so on - that is only to say that this methodology is not limited only to software development.

Scrum Roles

There are three roles in scrum:

Product Owner

He represents stakeholders and is responsible for the product (or the service availability of that product) and of the return on investment (ROI). Because of this he's the one that prioritizes the Product Backlog using business value points to ensure that the most valuable functionalities are developed first.
Effective Product Owners also seek input and feedback from customers, from designers, and from the team itself to optimize the product delivery.

Team

Of course team members are the one that brings things to reality: they guess how to turn the Product Backlog into an increment of functionality within each time frame of the sprint (everyone in the team is jointly responsible for the success of the iteration) and they do implement things.

Scrum Master

He's not part of the team: he is responsible for the Scrum process, ensuring everybody plays by the rules, removing impediments for the Team if necessary.

SCRUM Project

When dealing with a project, the very first thing to do is

• gathering the requirements to get to what the project want to achieve
• defining a roadmap to implement it

Right after this a prioritized list of work derived from the roadmap and the requirements is stored into the so-called Product Backlog: the most important items are put by the Product Owner at the top of the product backlog so that the team delivers them first.

The overall work inside a Project is split in smaller units:

• Epics: these are the most high level work units – they are groups of smaller working units called stories. For example, the effort to be done to implement a set of features can be considered an Epic
• Stories: these describe a need – for example a feature of the product. A story should describe the need from the user's perspective avoiding technicisms: it should always mention the user role that is needing the request to be fulfilled, the goal to be achieved and why the user needs it (i.e. received benefit).

It is up to the Product Owner to decide what to complete first: maybe an entire epic, maybe some stories of different epics because they are needed by the business before the others.

Uncompleted stories are put and stay into the Backlog: their state can be either

• New (freshly inserted)
• In Progress
• Blocked

and so on, but the point you should get here is that there cannot be completed stories in the Backlog.

SCRUM Sprints

Scrum iterations are called Sprints: these are the forecasts to complete user stories or other work units during a fixed time duration.

A sprint usually lasts one, two or even four weeks (although two weeks is the most common duration): its duration is highly related to the type of work - if we are talking of development and the work is split into quite big projects, sprints can be long. If we are talking of shorter goals, like system engineering tasks such as installing a new service infrastructure, sprints can be very short (usually one week is enough).

SCRUM Ceremonies

Scrum requires some ceremonies: attendees are always at least the Scrum Master, the Product Owner and of course the Team.

Sprint Planning Meeting

Choosing the right work items for a sprint is a collaborative effort between the Product Owner, Scrum Master and Team: before starting the Sprint the Scrum Master should plan a meeting (about one hour for each week the sprint lasts for - e.g. a two week sprint can have a two hours sprint planning meeting).

In the first part of the meeting the Product Owner discusses the objective that the Sprint should achieve and the items of the Product Backlog necessary to be completed to achieve that goal.

The team then

• sketch up tasks from the high-priority items (the Work Breakdown Structure) and estimate time to accomplish them
• commit to completing a certain number of stories by the end of the sprint: these stories and the plan for completing them by the end of the Sprint is what is known as the Sprint Backlog.

Daily stand-ups

A daily recurrent very short meeting (should last no more than minutes), typically in the morning - it is called stand up because attendee should stand up ... this helps keeping the meeting short by the way.
Its purpose is to quickly inform everyone of what's going on across the team. It is not intended to provide detailed information, rather than to surface any blockers and challenges that would impact the team's ability to deliver the sprint goal.

Iteration review

A 30-60 minutes meeting at the end of the Sprint the team uses to celebrate their accomplishments and to demonstrate the work finished within the iteration.

The purpose is to get immediate feedback from project stakeholders (stakeholders are encouraged to attend this meeting). In addition to that, it is wise to give a celebratory feel, so as to have team members to be proud of what they did and the achieved outcome.

Retrospective

A one hour meeting right after the iteration meeting: it is used to provide quick feedback to improve the product and its development. Retrospectives help the team understand what worked well and what didn't.

KANBAN

Kanban is considered as one of the best Lean methodologies in the Software & IT industry.
It has three basic items:

• boards
• lanes (lists)
• cards

Kanban requires to divide the board into several lanes (someone call them lists): the simplest set is

This is the simplest approach, but it is possible to add as many lanes as is required to get a better governance of your project (of course, lanes are very specific to what your projects applies to).

Examples of additional lanes can be

and so on.

The last item is the card: it is the working unit wanted to be tracked using Kanban.

Cards are initially put  as ToDo, and then will be moved forward throughout the workflow until they will reach the end.

Kanban Roles

Same way as Scrum has the role of Scrum Master, also Kanban has some specific roles for Kanban management.

Service Request Manager (SRM)

It's goal is bridging the gap between the Business and the Customer. He asks the individuals to improve the efficiency and effectiveness of the workflow.

His main responsibilities are:

• create an environment that brings value to the Customers and to the Business: to achieve this he gets feedback from the Team, Stakeholders and Customers so to prioritize work, taking in account of cost of delay, complexity, analyzed approach, technical risk market competency and many more
• define and maintain process policies: to promote the underlying business value he introduces and manages CoS ( Classes of service) that rank work items according to priority. He establishes also sequencing policies (according to priority level of different CoS) that define how each CoS should interact with each other
• make sure that both the CoS and their sequencing policies are in place

Service Delivery Manager (SDM)

He oversees the quality of Service Delivery ensuring an appropriate response to the demands of the Customer. He helps the team work the best way focusing on shortening the response to the market demand, on optimizing the delivery speed while reducing costs.

His responsibilities are:

• ensure that the best Kanban policies are followed by the team members
• check the Kanban board to make sure that no work item is pending or has been blocked for too long - if a given task is being delayed more than expected he checks if there’s a problem and he also addresses the topic with the requester
• promote continuous improvement with the workflow process: to achieve this he should be involved in meetings and activities such as the Service Delivery Review.
• identify loopholes of work items on the Kanban board and their root causes so that errors are not repeated more than once

Kanban Meetings

Of course there cannot be true governance without meetings - also Kanban requires them: they are specific to each board and of course a moderator is needed. Some of them are oriented to the service delivery itself, other improvement specific.

Delivery Planning Meeting

This kind of meeting is scheduled at each delivery cadence and is aimed at communicating to entities receiving and accepting the delivery: within Kanban, when tasks complete, often happens that other dependent tasks become deliverable (maybe to other teams) indeed. The outcome should be to ensure a smooth transfer of work in progress, and plan and decide which items to deliver.

Daily Meeting

Somebody calls this meeting “walking the board”: it's a very short (it  should last no more than 15 minutes) daily meeting mostly aimed at identifying new events that risk to be team blockers, but also to present what's going on. It's also the right moment to check if Work In Progress limits have been met, before pulling new tasks from the backlog.

Replenishment & Commitment Meeting

It's aimed at making informed decisions (shared at the Daily Meeting), supported by the team and stakeholders. These decisions help to prioritize incoming work and keep a steady flow of work. Besides the team, it also includes the Product Owner, the Product Development Management and anyone who can provide help in scheduling, sequencing or grouping tasks.
It usually lasts 20-30 minutes and it can be seen somehow the same way as the Sprint Planning meeting.

Strategy review

During this (usually four hours) quarterly meeting the overall business strategy gets reviewed and adjusted accordingly to market and customer changes. It's here that potential large-scale problems should get identified along with their suitable solutions. Information and decisions of this meeting are suitable to find Key Performance Indicators (KPI). From the team perspective, only representatives of customer facing teams can attend this meeting.

Service Delivery Review

This (usually thirty minutes) bi-weekly improvement meeting is aimed to check that the delivered service met the customer expectations. From the team perspective, only representatives of the teams attend this meeting, whose decisions and findings are then reported at Operations Review..

Operations Review

The aim of this (usually two hours) monthly meeting is to ensure that work goes smoothly across the different teams: demand and capacity of each Kanban team are checked, also relying on findings of Strategy Review and Service Delivery Review. Decisions are then communicated at the Service Delivery Review, Strategy Review and Risk Review meetings. No team members attend this meeting

Risk Review

This (usually one-two hours) monthly meeting is aimed at identifying risks and bottlenecks before they substantially impact the workflow and to take the right steps to mitigate those risks. It considers the issues identified at Operations Review, Service Delivery Review as well as the input from Delivery Planning meetings. Everyone familiar with the recent blockers, even team members, attends this meeting.

Kanban vs Scrum

This is a question that often arises: Scrum or Kanban? They are quite similar: both of them

• focus on delivering results early
• require breaking down the work into units
• assume pull scheduling
• limit work in progress (Kanban at the task level, limiting Work In Progress time; Scrum at the sprint level, defining the batch size)

Most of all, the release plan is continuously optimized using empirical data (Lead Time/Cycle Time in Kanban, Velocity in Scrum) in both of them.

The most straightforward difference between the two methodologies is in iteration length. In Scrum, it usually lasts 2 weeks, while in Kanban you may provide team members tasks every day.

Footnotes

Here it ends our journey on product management methodologies: I hope you enjoyed it. I think that even if you are a technician, and so most of the time are involved as a team member, you should get benefits from knowing a little bit about the methodology in use on your team, and that this can actually improve your skills as a professional.