What All Agile Developers Need To Know

A long time ago I started a software design for a Unix printer interface, the requirement was something like, “Software applications need to communicate with the printer”. I knew the interface was Unix RS-232 and I knew the interface to the printer, so I began designing the print driver. Early on a manager asked me how’s it going and I told him it was slow as there were many operations to support. He looked at me quizzically and asked what I meant. I showed him the printer’s interface document and the life drained from his face. He told me I didn’t need to design the Unix driver, they were buying a commercial driver. The actual requirement was to create a generic interface between the applications and the print driver. Oops!

When working in a Command & Control environment, knowledge is a tool for those in charge, something that becomes part of the attraction; ‘I know a secret’ kind of thing. Agile practices and mindset are meant to break down this behavior and put knowledge in the hands of those who need it, when they need it. In the situation above, the checks and balances were in place but only as a means to correct a misunderstanding, not to prevent it. Agile hopes to prevent going down a ‘wrong track’ in the first place. Agile practices are meant to harness the combined knowledge and experiences of business stakeholders, product teams, and development teams so implementation runs smoothly and efficiently. Agile does this through openness, transparency, and shared understanding.

The challenge for the development team is to move and adopt a different mindset toward business activities. Product owners too need to expand their horizons to seek out and use the development team as a valuable source of knowledge and insights. The steps below provide a guide for ScrumMasters on merging product owners and developers into a mini business team, responsible for progressing the company forward. Each of the steps requires full involvement and participation from product owners and development team members. It won’t work without motivated individuals who can see beyond their current roles.

A note on definitions:

  • ‘development’ and ‘development team’ – refers to the self-organizing, cross-functional group of people who together create the product. This can include Coders, Testers, UXD, BA’s, Architects, Database, and other specialties.
  • ‘Product Owner’ – refers to the person responsible for maximizing the value of the product and is the person responsible for managing the Product Backlog. In some organizations this role might be shared by a Chief Product Owner.


Step Description
0 Company Strategy is developed. A diagnosis of the company/business problem is complete and the Product Team is challenged to derive a plan to deal with, meet and exceed the challenge. The challenges might be stuff like, Increase On-line Sales of our Product or Decrease Product Abandonment After 60-days.
1 Product owner and development team(s) create a project or product vision statement. This is the overarching goal that the team and business are trying to achieve. The product itself is the means for achieving the vision. With the product owner facilitating, the whole team, (I’ve seen this work well with 30 people), should be able to fashion this in 30-minutes time.

  1. Review and discuss the business problem to overcome
  2. Review and discuss the specific goals of the company’s challenge
  3. Product owner to describe how a new/modified product can help achieve the company’s goals
  4. Everyone writes on sticky notes words or a short phrase that inspires or motivates them. Place these on a big wall
  5. The whole group creates an Affinity Map, group or cluster these words and phrases based on relationships.
  6. The product owner builds a vision from these words and phrases with everyone providing input.


  • A short vision statement that the entire team helped develop and can enthusiastically support
  • Product owner and development team start off on the same page with a common high level vision based on real business challenges
2 Product owner and development team(s) begin developing a Business Plan to attack the business problem. Get the full team involved and tackle the challenge. The group starts by identifying potential customer problems which can help achieve business goals if solved. Try the following in a 1-2 hour workshop:

  1. Question current assumptions; what do we assume?
  2. List out all the bad ideas first and why they’re bad
  3. Have the group list out what the customer needs or problems that once solved help meet the business challenge
  4. The group isolates out the top 3-4 best customer problem ideas

I suggest using Ash Mourya’s Lean Canvas. Use this to document your business plan and identifying the problems you can solve to help achieve business goals.


  • List of potential customer problems
  • Common understanding between product owner and development of what these problems are and why they address the high level business goals and vision
3 The Product Owner and full Development team continue on to find the solution for each problem identified above. The group provides one or two solutions for each problem, for the targeted customers. (You might have different solutions for different customer segments.) This is not a technical solution and it’s not about technology (not yet anyway). The solution here defines how the customers’ experience using the product is changed.

For example, the business problem might be customers are not clicking through to the blog page. The customer problem is once on the landing page, there’s no compelling reason to continue on to the blog. The solution might be to display a banner on the landing page with customer testimonials on how the blog entries made their lives better.

The approach is similar to the problem exercise above and can be accomplished in another 1-2 hour workshop:

  1. Question current assumptions; what do we assume about solving problems?
  2. List out all the bad ideas first and why they’re bad
  3. Have the group list out what the customer might want, need, or respond to.
  4. Group discusses how the potential solution will help meet the business challenge
  5. The group isolates out the top 1-2 best solutions for each customer problem listed


  • List of possible solutions for each problem grouped by customer segment if necessary
  • Common understanding between product owner and development team of what these problems are and why they address the high level business goals and vision
  • Lean Canvas has Problems, Solutions, and Customer Segment filled in and linked
Note: At this point the Lean Canvas will have 3-4 Problems, Solutions for each Problem, and the targeted Customers identified.

These first 3 steps should not take more than 1/2 day if that. The outcome so far are hypotheses for customer problems and solutions. These hypotheses now need to be validated with real customers.

4 Product owner and development team begin the process of conducting Customer Interviews to Validate the ‘Problems’ listed in the Lean Canvas. Justin Wilcox of Customer Development Labs has an excellent ‘How to interview your customers’ video you might like.

It’s imperative that one development team member be involved in all customer interviews. I suggest that all or as many development team members as possible be rotated through the customer interview process. This will establish a strong bridge between the customer and development.

Be aware too that you may need UX designs or prototypes of some solutions for customer interviews. This will depend a lot on your product and customers. If there’s any doubt, do at least the UX designs.

The process of conducting interviews might take some time especially if you do this in person but it’s worth the effort to know your customers. The list below is a start but doesn’t do justice to the nuanced skills good interviewing requires.

  1. Create an interview script to guide you (Justin Wilcox also has an excellent interview script generator)
  2. Determine what successful validation means (I had used 3 out of 5 people had my problem and wanted it solved as the measure)
  3. Line up your customers and users for interviews
  4. Have any UX designs, demos, or prototypes ready
  5. Have two or three people attend the interview (product owner and a development team member at a minimum). Only one person asks questions, the others listen
  6. During the interviews, use the ‘5 whys’ to get to root causes
  7. Spend 80% of the interview time listening to the customer
  8. Immediately after the interview, when practical, the interview team discusses their experience and writes up notes from each perspective.


  1. The key outcome will be if your customers validate your problem list or cause you to pivot
  2. Customers may like your solutions and validate them or they may have in mind alternative solutions you didn’t think of
  3. Product owner and development team together build a stronger understanding of their customers and users
  4. Development team gets more insights to business strategies through direct involvement with customers
5 Product owner and development fill out the remaining blocks on the Lean Canvas as best they can. At a minimum, the ‘Revenue Streams’ (e.g. revenue generation plans, lifetime value, pricing, and margins) and ‘Cost Structure’ (e.g. product & maintenance costs, cost of acquisition of new customers, re-seller costs) will need to be completed. Review these additions with the full development team and solicit insights and thoughts. Once the full development team has reviewed the Canvas, the Product Owner can present the Canvas to the business leaders for funding and adding the new/modified product work to the product portfolio or Roadmap.

It’s important to involve the development team in the business side of, well, the business. If the team thinks of themselves as a stand-alone business unit, not unlike an early start-up business, then they’re more likely to be successful from the stand point of building products people actually want and discarding unwanted product ideas early in the process.

6 Product owner and development conduct an Agile Project Planning session (see 15 Steps to Agile Project Planning Success). This is a just-in-time meeting immediately before the project’s first sprint. This will involve everyone working to achieve to goals, part of the overall strategic plan.


By following the guide above you can increase your chances of success. The more eyes on the prize, you increase the likelihood of success. This is achieved primarily through empowering and trusting a team to solve business problems.

  • Having a common goal and vision between business, product owner, and development team
  • Product and development working together to find customer problems to solve to help the business achieve it’s goals
  • Product and development jointly creating a business plan using a Lean Canvas
  • Product and development having joint responsibility and ownership for implementing a solution to solve customer problems and achieving the company’s strategic goals.

Author: Robert Boyd

I'm a CSP (Certified Scrum Professional), CSM (Certified ScrumMaster), and CSPO (Certified Scrum Product Owner). For 30 years I've been streamlining processes and systems. I've introduced agile methodologies to software and product management departments, resulting in a 300 percent increase in feature deliveries.

2 thoughts on “What All Agile Developers Need To Know”

  1. Hi Robert,
    that’s brilliant. I’m going to use it in my teaching (properly attributed of course). Certainly, a whole lot of human things can get in the way of getting accurate requirements.

Leave a Reply

Your email address will not be published.