Some time ago, we hosted an experience interview with Bas Vodde. Together with Craig Larman, Bas developed Large-Scale Scrum (LeSS). A framework for scaling Scrum to medium to large products while staying true to the original Scrum principles. During this meetup, Bas answered a wide variety of questions raised by our Patreon community.
For example:
- What would be a 2-minute explanation of LeSS?
- In what situation should LeSS be used? In which ones rather not?
- Why should I use LeSS and not any of the other scaling frameworks (SAFe, Nexus, etc.)?
- LeSS is about many teams working together on one product. What does LeSS have to say about many teams working on multiple products that integrate with one another?
- What are the most common or biggest deviations from the LeSS framework you have seen?
- What is your experience with virtual product development? What changed? How does it impact the use of LeSS?
Interested to learn how Bas answered these, and many other questions? Check the video!
In this blog post, we focus on one specific topic that emerged. It was raised by Eleonora, a member of the Italian user group:
How to help the developers from your Scrum team move from “programmers” to “product developers”?
The question from Eleonora is based on James Shore’s book “The Art Of Agile Development” to which Bas Vodde also contributed. In this book, Bas explains how most teams he works with are on a journey from “programmers” to “product developers”. This means the whole team deeply understands the customer and customer domain rather than depending on someone to clarify for them and hand-off the result of that clarification.
In this blog post, I’ll share my view on this question. Contrary to what you might expect from me, I’ve minimized the use of Scrum terminology. I tried to write this article framework-agnostic. In the end, the importance of acting as a product developer isn’t about Scrum, XP, or any other framework. It matters because of the underlying values and principles for working empirically.
The attitude of a programmer
Now, you might think: “Who cares about this distinction at all? Isn’t it simply playing with words?”. Personally, I consider it a completely different way of looking at the responsibilities of a developer. And also, the potential of a developer. Maybe, the job description of a developer doesn’t literally state “programmer”, but it might be the way (s)he fulfills their role. I’ll give you a couple of examples. They might feel extreme, but its intention is to clarify the difference between a programmer and a product developer, and why it matters.
As a programmer…
- Your focus is mostly on writing code. Code on itself doesn’t generate business value. If it doesn’t address the needs of the stakeholders and/or the users of your product, then why write the code at all? And to be clear, writing code to resolve technical debt can still be valuable, because it improves the quality of the product, and quality is what allows us to release incremental, at a constant pace, our product increments.
- You’re not directly engaged with stakeholders. A stakeholder is someone who helps you decide what is valuable to work on next because it’s important to them to get a return on their investment of time and/or money. The only person you talk to is the requirements specialist. This person explains what he/she has understood as the specifications, which you turn into software. There’s no direct line of communication between you and the stakeholders.
- You’re not involved in setting goals. At the start of the iterations planning session, the goal for the upcoming iteration is announced. As a team, you select the work necessary to achieve it. Or, even worse, the recurring goal is to “finish all the work we selected”. So, there’s no unique, inspiring, and value-driven goal for the team to focus on.
- You don’t take initiative to organize review sessions with stakeholders. You do get an invitation to join the review sessions, but you’re not involved in the preparation or hosting. It’s a pretty meaningless session anyhow. It’s mostly a technical explanation & demonstration, impossible to follow for anyone that lacks a technical background. Often it’s also without any stakeholders, its attendees are people from your own organization who don’t use the product themselves.
- You don’t have a focus on the product as a whole. Writing software is your primary focus. You can explain all details about the backend functionality, but you can’t describe the complete customer journey. That’s the responsibility of the designer, tester, or business analyst. Even though you do understand that software is only output, and the product is the actual outcome.
The attitude of a product developer
In many ways, the attitude of a product developer is the opposite of a programmer. Below, I’ll share some examples. The shortest way to describe the difference is that a product developer is proactive, and a programmer is reactive. A product developer proactively seeks out a collaboration with stakeholders to better understand their needs. A programmer is more reactive and waits to be told what to do next.
As a product developer…
- You’re involved in setting a “long-term” goal for the product. In complex work, shared goals are the lighthouses that help you reach the harbor through dense fog. Without them, you’re likely to get lost and run ashore. To determine where you should set sail in the first place, you create a long-term goal for the product. It probably takes a couple of iterations to achieve. Ideally, you work together with the key stakeholders to craft a product goal together. Everyone brings in ideas to what they consider important, it’s refined to such an extent that only one goal remains left. This is the product goal the team will focus on in the upcoming period.
- You help formulate “short-term” goals. Short-term goals give teams the focus on what is important during an iteration while allowing flexibility to adjust course and avoid emerging obstacles as needed. While the team commits to a specific goal, the actual work is continuously changed as needed to reflect discoveries, insights, and ideas. The creation of a goal should be a joint effort of the entire team and its stakeholders. Ideally, each iteration only has one goal, and everyone already has a rough idea of what the upcoming goals might be. This creates focus & clarity and allows everyone to make trade-offs on what to spend time on.
- You engage with stakeholders. It is difficult to create something of value when you have no idea who your stakeholders are and what they want. Research shows that teams are more effective when they collaborate closely with stakeholders. Otherwise, you can’t be certain that you’re building the right product and adding the right features. And stakeholders often have great insights into what makes your work even more valuable. So, as a product developer, you proactively reach out to your stakeholder to better understand their needs and you can suggest technical options for reducing the work while still fulfilling the product goal
- You initiate the refinement of work items. Refinement is the process of breaking down larger items into smaller ones with the purpose of ending with items that can comfortably be delivered to stakeholders in one iteration. Teams that spend more time on refinement are also more likely to release frequently. In turn, they have more satisfied stakeholders and higher team morale. As a product developer, you understand which items could benefit from refinement, and you proactively refine them into smaller chunks of work.
As a product developer, you understand which items could benefit from refinement, and you proactively refine them into smaller chunks of work.
- You actively contribute to product review sessions with stakeholders. The purpose of each review session is to inspect the work that has been done to date and to decide what next steps make sense based on what was learned from that. This inspection is a joint effort between the team and the stakeholders. Not only do you inspect the outcome, but also the current market conditions, organizational changes, budget, and timeline. As a product developer, you prepare the review sessions and support the stakeholders in using the new features to gather feedback. All of this helps you decide what to do next.
- Your focus is on delivering value to stakeholders. When developing a product, “value” often takes many shapes. It helps to be explicit about what type of value is represented on the backlog. As a product developer, you understand what is valuable to your stakeholders and why. You are also able to explain how upcoming work is valuable for your stakeholders. Especially when the business value isn’t immediately clear, for example with highly technical work and/or the removal of technical debt.
- You take part in product discovery. Product discovery is the proactive behavior of teams to discover new valuable features through experiments, field testing, and research. Often, the insights from these kinds of proactive behaviors lead to more valuable features and avoid unnecessary work. So, as a product developer, you interview your stakeholders to learn what matters most and you make it a joint effort to explore the state of your product and the market conditions. Not only do you understand the business perspective your stakeholders have, but also share the technical side that might influence the development process.
- You are responsive to stakeholder needs. Responsiveness is the ability of a team to respond to changing needs, new insights, and emerging issues from stakeholders. Because of the complex nature of product development, many problems, ideas, and opportunities can only be discovered along the way. Teams that release new versions frequently have more opportunities to get realistic feedback from stakeholders and verify assumptions that exist on both sides. In turn, that allows your team to reduce the risk of wasting time and money on unnecessary features while also creating opportunities to capitalize on emerging insights. A product developer fully understands the importance of responsiveness, and therefore continuously seeks the opportunity to release early and often.
A Sprint Review in which the Scrum team collaborates with their stakeholders to inspect the Increment, gather feedback, and define the next steps.
Quick tips to shift towards product developer
By now, you should have a clear understanding of the difference in attitude between a programmer and a product developer. Hopefully, you see the value in acting as a product developer. But how to make this shift? How to move away from a reactive attitude towards a more proactive one? It could be that you personally already wanted to make this shift but your environment doesn’t support it. Because it’s easy to get stuck, we always encourage teams to make small steps in the right direction. We call these small steps ‘quick tips’. The purpose of quick tips is to spark small and incremental change in your Scrum team. Small steps in the right direction to remove impediments, improve collaboration, manage risk, and deliver value sooner.
So, in the upcoming period, consider trying the following:
- During your next iteration, gather at least 3 actionable ideas for your backlog by interviewing people with a real stake in your product.
- Invite 2 users to join your next product review session (remotely or in-person) that actively use your product.
- For each item on your iteration backlog, together add and complete: ‘[item], and this is important to our users because …’
- During your next iteration, validate 2 items you’re working on with one or more active users of your product.
- Next week, go on a field trip to a location with many users of your product. You can also split up and visit multiple sites. Report your findings to each other.
All quick tips are included in the Scrum Team Survey. With this free product, Scrum teams can diagnose themselves with an extensive, scientifically validated survey and receive detailed results and evidence-based feedback upon completion. Give it a try, and receive quick tips for each of the 30 topics the survey contains!
Closing
In this blog post, I explained the difference between the attitude of a programmer and a product developer. This change in attitude is important because the better your team understands its stakeholders and their product, the more likely they are to build the right things. Otherwise, they may end up wasting a lot of time and money on problems that stakeholders don’t have. As such, a product developer is involved in creating long-term and short-term goals, is engaged with stakeholders, actively contributes to product review sessions, initiates refinement, has a focus on value, takes part in product discovery, and is responsive to the needs of their stakeholders.
What’s the attitude of the developers in your team? How do you help developers focus on the whole product, instead of software only? We’re always eager to learn from your experiences, so feel free to share them. Let’s learn and grow, together!