In this article, I’d like to share my condensed view on agile product development teams. It might help you to find your personal role in such a team or even setup a team based on my blueprint, as a team architect. Let me know, if you need any additional input. I’m happy to learn, help and speak about this topic.
In the last years, I gained experience in different projects from delivering individual software with a single small team to developing large IT platforms with multiple agile teams (and non agile management) involved. In parallel, I deduced the principles from frameworks, i.e. Scrum, Kanban, Scrumban, LeSS and SAFe, and adapted them to our specific problems in the project.
In the following sections, I will cover the process, the roles and responsibilities inside the team and how to combine them as well as supportive methods and tools to develop products. The following drawing provides an overview of these aspects, which I will describe in greater detail below.
For example, if you want to develop a product for online video tutorials, there is a huge technical challenge of providing large video files and a big effort in producing the video content. And, yes, it is necessary to solve that. But why would you not start simple by just sending out a newsletter with some links to video that are hosted on an existing service, to firstly figure, if your target customer would benefit from your product in principle?
Product development is about generating value - in two aspects: a) The product generates value by solving the customers problem making her live easy and b) the development of the product provides knowledge to you (the developer) about what is needed. Since you, as a product person, most probably don’t know what is needed by the customer upfront, you need to change the product accordingly. And since, you won’t know every detail after the first walk-through, you probably should to continuously iterate that lean process cycle of build, measure, learn. This is what you’d do in product development. Agility tells you how to do it.
Eventually, agility is an attitude. If you’re more the type of person that loves to follow order and/or is too lazy to change, you’re probably the wrong person to become a ballerina and move with quick ease and grace.
From the vision, you deduce a product vision. In contrast to the CEOs vision, which is about the company, the product vision is about the overarching objective of the product, which supports the big company vision.
Taking that vision allows to deduce a product roadmap, which breaks down the vision into smaller (but still big) chunks of features and puts the in order of priority over time. The roadmap states what should be worked on immediately and what is postponed. Important and urgent stuff now, the rest later. However, the chunks that you’ll work on now are defined in greater detail as the ones you might solve in 3 month, simply because the growing uncertainty over time. You simply don’t know if this huge unimportant feature will still be needed in 6 month or if you could maybe buy it then. Detailed long-term planning is a waste of time in a fast changing world.
Once you have the roadmap, you can define the features for the next iteration in detail. In Scrum, we are usually talking about a cycle length of 2-4 weeks until we deliver a possibly shipable product and plan the next iteration. To my experience, detailed planning at that level could be done pretty well. And it gives you flexibility.
To me, it is highly important that the team really delivers a product to the customer. If the team has the end-to-end responsibility from gathering requirements over building to finally delivering the product, they take responsibility to deliver in quality.
I won’t go deeper into all the handy agile artifacts such as Backlogs, Definition of Done, Product increment, Scrum and Kanban boards, and meetings such as Backlog refinement, Planning, Standup, Review, and Retrospective. There is plenty of articles out there that describe these things.
However, we want to deliver a product that is valuable, feasible and usable (see Marty Cagan: The Most Important Thing). To me, value defines the benefit that the product brings to the customer, e.g. how it makes his live easier. Additionally, the product must be feasible, if you want to bring it to live. But it also should be feasible in the long run, which means that you don’t build a Frankenstein product. This would make your live pretty uncomfortable in the long run, since it will get harder (and more expensive) to add features the bigger the mess gets. And the product features must also be usable. If the feature is implemented, but the customer does struggle with using it, it generates less to no value and the customer will stop using it. No value.
To me, roles and responsibilities is a great concept to form a team. It defines roles independently of a person, which makes it easier to discuss, and define the responsibilities in terms of purpose (why), tasks (what) and expertise (how). A role is not dedicated to a person. A person could fill out more than one role or roles could be shared. It depends on the capacity and the situation. See below.
As a product team, you want to realize the product vision. Roles shape a team. So the tasks to make that vision reality are assigned to roles.
In the teams I worked with, the responsibility was usually distributed in principle as follows:
Having a single Product Owner is crucial (one role - one person), to keep one single source of truth. This is truly a full-time job. She will be busy providing tasks to the developers. The team, however, has usually more than one developer with different expertise, such as mobile or cloud Devops. Hence, responsibilities such as architecture could be shared. In contrast, the role UX-Designer could be shared between multiple teams (1 person - multiple roles), depending on the workload.
Regarding the Scrum master my experience is, that the effort changes over time. While the team needs her full time in the beginning, after training the basics is done (after some month) her effort could be reduced. But it is crucial to keep and eye on the team, simply because change is hard and, as human, we easily fall back into bad habits.
To my opinion, the Scrum Master should additionally be an external consultant, to not get too closely involved in the teams business due to the personal nature of the relation between team members and Scrum Master. As external person, the Agile Coach can keep a professional distance without explicitly denying closeness. That keeps things simple.
I'm an Agile coach, product person and software architect. I'm not only writing articles, I also speak about it, if you ask me to. If you need any help, just let me know. You'll find more information about me at https://www.migge.info/.
I’m looking forward to any constructive response.
In the last years, I gained experience in different projects from delivering individual software with a single small team to developing large IT platforms with multiple agile teams (and non agile management) involved. In parallel, I deduced the principles from frameworks, i.e. Scrum, Kanban, Scrumban, LeSS and SAFe, and adapted them to our specific problems in the project.
In the following sections, I will cover the process, the roles and responsibilities inside the team and how to combine them as well as supportive methods and tools to develop products. The following drawing provides an overview of these aspects, which I will describe in greater detail below.
 |
| Agile product development |
Let me start with how I understand the terms “agility” and “product development”.
Product development is generating value.
Product development means developing value and delivering it to customers. (For simplicity reasons, I don't distinguish between users, who will actually use the product, and customers, who for pay it.) Working product-oriented prioritizes generating value over domain knowledge of experts, fancy technology, optimal processes, power, politics and many other possible aspects of a business organization. Hence, I consider the later as vehicles to value generation. They are necessary, yes, but in case of doubt, generating value is the main goal.For example, if you want to develop a product for online video tutorials, there is a huge technical challenge of providing large video files and a big effort in producing the video content. And, yes, it is necessary to solve that. But why would you not start simple by just sending out a newsletter with some links to video that are hosted on an existing service, to firstly figure, if your target customer would benefit from your product in principle?
Product development is about generating value - in two aspects: a) The product generates value by solving the customers problem making her live easy and b) the development of the product provides knowledge to you (the developer) about what is needed. Since you, as a product person, most probably don’t know what is needed by the customer upfront, you need to change the product accordingly. And since, you won’t know every detail after the first walk-through, you probably should to continuously iterate that lean process cycle of build, measure, learn. This is what you’d do in product development. Agility tells you how to do it.
Agility is not a tool - It’s an attitude.
Agile is a way how you (and your organization) continuously adapt. Merriam-webster states it is “the ability to move with quick ease and grace...”. We basically all become ballerinas. Seriously, in the context of product development, it means to me the way we learn about the customer. Hence, it is about the people and the process of your organization: You become quick and change reasonable by empowering the people in the team (they know what to do) to make decisions instead of following a static plan from management. And you move with grace by setting up a learning culture where you take failure as opportunity to learn instead a chance to blame others, stay busy and become grumpy in the end. And, no, I would not consider making the same mistake over and over again as learning. And, no, agile is not easy. It is rather hard work to figure how to learn as a team.Eventually, agility is an attitude. If you’re more the type of person that loves to follow order and/or is too lazy to change, you’re probably the wrong person to become a ballerina and move with quick ease and grace.
The artifacts to deliver a valuable, feasible and usable product.
What is needed to deliver great products? It all starts with a vision as an overarching goal, that motivates and gives direction to the organization. Most probably it is given by the CEO or any “head of”. If you don’t have one, where would you want to go with your business?From the vision, you deduce a product vision. In contrast to the CEOs vision, which is about the company, the product vision is about the overarching objective of the product, which supports the big company vision.
Taking that vision allows to deduce a product roadmap, which breaks down the vision into smaller (but still big) chunks of features and puts the in order of priority over time. The roadmap states what should be worked on immediately and what is postponed. Important and urgent stuff now, the rest later. However, the chunks that you’ll work on now are defined in greater detail as the ones you might solve in 3 month, simply because the growing uncertainty over time. You simply don’t know if this huge unimportant feature will still be needed in 6 month or if you could maybe buy it then. Detailed long-term planning is a waste of time in a fast changing world.
Once you have the roadmap, you can define the features for the next iteration in detail. In Scrum, we are usually talking about a cycle length of 2-4 weeks until we deliver a possibly shipable product and plan the next iteration. To my experience, detailed planning at that level could be done pretty well. And it gives you flexibility.
To me, it is highly important that the team really delivers a product to the customer. If the team has the end-to-end responsibility from gathering requirements over building to finally delivering the product, they take responsibility to deliver in quality.
I won’t go deeper into all the handy agile artifacts such as Backlogs, Definition of Done, Product increment, Scrum and Kanban boards, and meetings such as Backlog refinement, Planning, Standup, Review, and Retrospective. There is plenty of articles out there that describe these things.
However, we want to deliver a product that is valuable, feasible and usable (see Marty Cagan: The Most Important Thing). To me, value defines the benefit that the product brings to the customer, e.g. how it makes his live easier. Additionally, the product must be feasible, if you want to bring it to live. But it also should be feasible in the long run, which means that you don’t build a Frankenstein product. This would make your live pretty uncomfortable in the long run, since it will get harder (and more expensive) to add features the bigger the mess gets. And the product features must also be usable. If the feature is implemented, but the customer does struggle with using it, it generates less to no value and the customer will stop using it. No value.
The roles and responsibilities of an agile product development team.
In an agile team, the responsibility of valuable, feasible and usable products are shared between different roles. The advantage of supporting discussions between the different roles is bringing up better solutions as team. And distributing the load enables the team to react quicker that a single manager.To me, roles and responsibilities is a great concept to form a team. It defines roles independently of a person, which makes it easier to discuss, and define the responsibilities in terms of purpose (why), tasks (what) and expertise (how). A role is not dedicated to a person. A person could fill out more than one role or roles could be shared. It depends on the capacity and the situation. See below.
As a product team, you want to realize the product vision. Roles shape a team. So the tasks to make that vision reality are assigned to roles.
In the teams I worked with, the responsibility was usually distributed in principle as follows:
Scrum master
The Scrum Master (aka Agile Coach) is responsible for the people and the process of developing a product. By not directly contributing to the product development, it is probably the most underestimated role of the product development team. However, since the roles and responsibilities are split, collaboration is essential for the success of the team. Her daily business is to foster collaboration by moderating meetings, training the team in agile tools and methods and many more that helps the team becoming faster and reliable (i.e. establish flow). She is a servant leader. Although the Scrum Master tries to make herself obsolete by enabling the team, this job never stops, since getting more agile never stops. (Think about stopping to be a parent. Would you?) The most important and strategic responsibility of the Scrum master is to build a culture of learning, i.e. inspect and adapt, which is one of the two core aspects of agility.Product owner
The Product Owner (PO) takes care about the product value, which is the user being able to make use of the product features. She collects requirements from the customer, prioritizing them w.r.t. the business value (BV) and communicating them to the rest of the team w.r.t. to the Definition of Ready (DoR) as a quality criteria. But the most important aspect is to decide what is not build to keep the product lean and long living. To identify the needed features, she measures the usage of the product and collects feedback from the user. This closes the loop between the product and the customer to continuously build, measure and learn. The strategic responsibility of the PO is the product roadmap and the product vision. It allows to align small, short-team features with the long-term big picture of the product.Developer
The developer (DEV) is responsible for the feasibility of the product. Primarily, this is developing features in high quality (w.r.t. the Definition of Done - DoD), software design and testing. In order to increase quality they apply code review and automated test-driven-development (TDD) as part of Continuous Integration/Continuous Delivery (CI/CD) pipelines, to build the product with quick and easy grace. The strategic responsibility of the developers is the system architecture, which is the guideline about how to orchestrate the technical components of the system to assure the product to be clean on the inside. This is required to be able to grow the product with lowest effort. No Frankenstein!UX-Designer
The UX-Designer (aka Experience Designer - XD) takes care about the usability of the product, to assure that the customer can actually easily use the features. Similar to the technical architecture, she provides a UX guideline to keep the UX design aligned and clean, which support ease of use in the long run. The operational tasks are understanding the users with personas and the process of using the product with user journeys, since the UX Designer conceives the user interface (UI) between the product and the customer.Forming an agile product development team.
To my experience, the four roles Scrum master, Product owner, Developer and UX-Designer shape an agile product team.Having a single Product Owner is crucial (one role - one person), to keep one single source of truth. This is truly a full-time job. She will be busy providing tasks to the developers. The team, however, has usually more than one developer with different expertise, such as mobile or cloud Devops. Hence, responsibilities such as architecture could be shared. In contrast, the role UX-Designer could be shared between multiple teams (1 person - multiple roles), depending on the workload.
Regarding the Scrum master my experience is, that the effort changes over time. While the team needs her full time in the beginning, after training the basics is done (after some month) her effort could be reduced. But it is crucial to keep and eye on the team, simply because change is hard and, as human, we easily fall back into bad habits.
To my opinion, the Scrum Master should additionally be an external consultant, to not get too closely involved in the teams business due to the personal nature of the relation between team members and Scrum Master. As external person, the Agile Coach can keep a professional distance without explicitly denying closeness. That keeps things simple.
Summary and next steps
In this article, I shared my condensed view on agile product development team. I covered the development process and the roles and responsibilities inside the team and how to construct a team.I'm an Agile coach, product person and software architect. I'm not only writing articles, I also speak about it, if you ask me to. If you need any help, just let me know. You'll find more information about me at https://www.migge.info/.
I’m looking forward to any constructive response.
I'd like to additionally share the article The Evolution of UX Process Methodology https://uxplanet.org/the-evolution-of-ux-process-methodology-47f52557178b, which provides how to integrate UX design and agile product development.
AntwortenLöschen