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.
|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.
|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:
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.
|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:
|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.
|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.