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.

15 Steps to Agile Project Planning Success

Project planning has been around a long time. It started with the building of the Great Pyramid of Giza in about 2580 BC or some 4,600 years ago. To demonstrate that project politics remains little changed since, below is a transcript of one of the conversations between the Pyramid project manager and the principle stakeholder and chief sponsor, Pharaoh. It should sound very familiar:

Pharaoh Khufu: Project Manager Rahotep, a while ago you committed to completing stone course 38 on my Great Pyramid here in Giza before the Moon blazes full 6 times, which, according to my temple astrologers, the 6th time will happen in two Ra days. You’re still one course short, do you want to visit my crocodile farm?
PM Rahotep: My great Pharaoh, according to my well documented papyrus project plan, we will finish the 38th course of stone in two days, nothing to worry about.
Pharaoh Khufu: I, the great Pharaoh Khufu, never worries but you just might start.
Rahotep: Start what?
Pharaoh Khufu: WORRYING! See you in two days and it better be done or else!

Project Manager Rahtep is in big trouble because no matter how great the project plan is, predicting dates 6-months in advance will not be accurate. Pharaoh Khufu doesn’t want to hear about problems or delays, he just knows that the pyramid team ‘promised’ full delivery of the 38th course of stone by a very specific date and heads will literally roll if the date is missed.

Agile Planning

Agile and Scrum attempt to change this kind thinking and replaces long-term planning based on dates with identifying the most valuable or most important work and scheduling it first. If the team can deliver the most important stuff to the customer first, it may not be necessary to all the originally planned work because the customer finds they don’t need it. Agile still does planning so it’s clear when customers and business stakeholders can expect problem solutions but accuracy is lost beyond the 1-2 month time frame. Dates are replaced with release time frames. Here is a guide to estimation accuracy based on my experiences:

  • 1-2 months – 80% accurate
  • 2-4 months – 50% accurate
  • > 4 months – < 50% accurate

This post will look at how to do Agile planning successfully. Agile planning involves everyone at one stage or another; customers, users, testers, developers, product managers, product owners, business managers, BA’s, UXD’s, and other stakeholders. There are several ways the run a planning session but I particularly like Story Mapping by Jeff Patton.

A key outcome of Agile planning will be a common understanding of what needs to be done to solve customer problems and achieve the business goals. Artifacts will include big and small tasks (stories) that will be done to achieve the goals and a general idea in which release these tasks will be completed. Underlining all this will be conversations that fill the gaps the artifacts themselves can not fill. A successful Agile planning session will put testers, developers, product managers, product owners, business managers, BA’s, UXD’s, and other stakeholders all on the same page using the artifacts as a means to remember conversations.

Preparing for the Agile planning session

The planning session will run more smoothly and take less time if you’re prepared. The Scrum Master (or Agile Project Manager), Chief Product Owner, and Product Owner will ensure these tasks are completed before the session:

  1. Define a goal or goals, what everyone will work toward.
  2. Identify the customers, users and key stakeholders. Understand the problems each has.
  3. Conduct customer/user interviews. The best would be a video of a user using the product (see Rocket Surgery Made Easy by Steve Krug: Usability Demo for an excellent example). If a video or audio recording isn’t available, a transcript will work.
  4. Go through each of the customer problems and order these by business value. Businesses could use acquisition, activation, retention, referral, revenue, or other business measures. Any and all are good as long as the measures are applied equally for all problems.
  5. UXD and Product Manager create any necessary wireframes, mockups, or prototypes to use for validating customer problems. Discard those problems that are not valid. Repeat until a viable solution to the problem is found or that a solution is feasible.
  6. Set preliminary release time frames or windows based on past development team capacity or based on past performance for similar projects.                                                       Product managers will usually set dates for as late as possible and work backward from those dates to get a rough start date.

Agile Planning meeting

The purpose of the Agile Planning Meeting is to have everyone in the Team achieve a shared understanding of what the problems are, why we need to solve them, the order these need to be solved in, how we might achieve a solution, and making a commitment to delivering an agreed scope to an agreed release time frame.

Planning is used to set initial expectations but then the team constantly updates those expectations throughout the life of the project as the Product Owner and development Team gain new information. The Product Owner and Team should re-access their commitments at the end of each sprint.

The Agile planning session takes the following route, the recommended facilitator is shown in italics for each segment:

  1. Introduction – Chief Product Owner/Scrum Master. Review the Agile planning meeting agenda and how the next 2-3 days will unfold. Emphasize the dynamic, participatory nature of this planning event and the need for speed (not haste) to maintain schedule timing. (15 minutes)
  2. House Rules – Scrum Master. Whole team defines the house rules. This is a exercise to document the expected behaviors and conduct of the planning meeting. (15 minutes)
  3. Business Goals & Vision – Chief Product Owner.  Senior management (CEO, CFO, CTO, COO) will share how solving the customer problems will affect the business tactically and strategically and why it’s important to the business. (15 minutes)
  4. Vision – Chief Product Owner.  Share the vision of solving the customer problems, how these solutions affect the business and product, and why it’s important to the customers. (15 minutes)
  5. Who are the customers – Chief Product Owner.  Talk to customers live or play customer interviews, read through transcripts. The goal is to get every to feel the pain the customers are feeling. (60-90 minutes)
  6. Empathy Mapping – Chief Product Owner.                                          Develop an Empathy Map of your customers and users. The goal of the exercise is to create a degree of empathy for the person. UXD and Product Management will probably have personas but Empathy Maps are specific to the project Goals and the current problems. (15 minutes)
  7. User Journeys-what will be different – UXD.  User journeys old and new. How the product needs to change to allow for new user journeys. Do this for each of the customers and users identified during the Empathy Mapping segment.  (15 minutes)
  8. Speedboat & Anchors – Scrum Master.                                          Identify what’s standing in the way of your goals and vision. Identify what propels the team forward, things we need to continue doing and those things that slow the team down, blind spots in our processes, and in general, things that prevent us from being more successful. (15 minutes)
  9. Trade-Off Sliders – Scrum Master.                                      An up front determination by the team of, when push comes to shove, whether you are going to be able to flex on scope (preferred) or whether you’ve got wiggle room around the date. Watch the expressions of people when development wants to trade schedule for quality. (15 minutes)
  10. What’s In, What’s Not – Chief Product Owner.                                            Saying what you are not going to do is powerful. It eliminates a lot of up-front waste by letting the development team focus on items that are IN while ignoring everything that is OUT. It is from the IN column that all high-level user stories will flow. The group also identifies those items that are questionable. These might be some nice to haves but are not as important as those items in the IN column. (30 minutes)
  11. Story Mapping Goals, Users, High Level Tasks, and sub-tasks – Scrum Master. The priority of Goals and High-Level tasks are shown left to right with the highest priorities to the left. As a group order the Goals first. Then do the High-Level tasks and align these with the users. Expect the order of Goals and High-level tasks to change once they’re visible on the wall. The Chief Product Owner, Product Owners, UXD people, development team will start top down mapping in progressively greater detail down to the sub-tasks necessary to achieve the goal. The sub-tasks will generally become the User Stories and the High Level tasks will become Epics. Expect a lot of trade-offs, compromises, and debate. The back and forth through the Story Map will continue until a consensus is reached that it makes sense and is achievable based on current knowledge and understanding. See the Story Mapping Guide and Jeff Patton’s Story Mapping for more details. (1 – 3 days)
  12. Estimation and Adjustment –Scrum Master. In the previous step, the team allocated all the work to releases. Now the development team needs to go through and estimate the tasks & sub-tasks (suggest using T-Shirt sizes, XS, S, M, L, XL, XXL) in order to calculate the actual number of sprints needed for each release. Trade-offs and compromises will occur as work gets shuffled based on earlier release time frame calculations made during pre-planning activities. (1 hour)
  13. What will it take – Scrum Master. The entire team will revisit the Speedboat & Anchors chart making any new additions. The team will now review those items, especially anchors, that potentially put the plan at risk. The team will put together whatever action plans are needed to reduce or eliminate critical risks. (30 minutes)
  14. Report plan to the executives – Chief Product Owner. The development team reports the results of the Agile planning session to the executive managers and answers any of their questions. If management doesn’t already know, the development team needs to make them aware that all estimates and dates are based on current knowledge. The Chief Product Owner will summarize the value of each planned release and what the customers can expect.
  15. Closing – Scrum Master. Overview of the achievements made by the team during the course of the Agile planning session. A few highlights, crazy moments, and key outcomes including release dates. Senior management, Chief Product Owner, and Scrum Masters stand and congratulate the team for their time and efforts. People are given the rest of the day off and sprint planning for the first sprint starts first thing the next day.



6 Tips For Scrum Masters Without Authority

For the scrum master, scrum is the tool to help the development team increase productivity, meet delivery dates, improve teamwork, and to better satisfy the customer. The scrum master is meant to help create an environment where the development team is trusted, empowered, and given the appropriate autonomy to get the job done. Once in place the development team can soar if they collectively agree to do so. The scrum master’s job it is to help the development team soar, to become high-performers and hyper-productive. But how can scrum masters achieve this without authority? Here are 6 tips for scrum masters to help improve both the environment and the development team without authority.

  1. Guide management to actively trust and empower the development team
  2. Guide management and the business on how work flows to the development team
  3. Develop an understanding with management for supporting scrum and the efforts of the scrum master
  4. Workshop with managers and development teams to understand limits and boundaries
  5. Train the development team on Scrum
  6. Have the development team create the metrics and measures they’ll use to know they’re doing better, worse, or neutral

Guide management to actively trust and empower the development team

For trust and empowerment to occur, the manager must let go of the team. The scrum master can help the managers cross the bridge between being a leader to becoming a servant leader. This can be difficult and time-consuming but it can happen. This was the topic of a talk I gave at Scrum Australia 2016, The Journey to Servant Leadership.

As scrum master, use yourself as a mirror to reflect back to the manager how they behave. I used a camera to record the manager’s interactions with the team to great effect. It is often surprising to the manager to see how they interacted with the development team.

Guide management and the business on how work flows to the development team

In scrum, all work to the development team should flow through the Product Owner. However, in all organizations I’ve been in there’s always some emergency or critical work that needed to be done immediately. How this is handled can vary widely.  The best situation is there exists a team that exclusively handles these interrupting work requests. The least desirable method was direct contact with the developers by management ‘telling’ them to do the emergency work, essentially overriding the Product Owner. The scrum master can greatly influence how this comes to the development team. The scrum master and management can develop a detailed process that allows for emergency work to come to the team but only if:

  1. the work is more important than any of the work in the current sprint and
  2. could not wait until the next sprint.

If the work passes these two tests, the Product Owner discusses the work in detail with the development team to come to a consensus on the best way forward. This would generally mean dropping a story not already in progress and adding the new work. When this happens, the development team can discuss the emergency work at the next retrospective to see if there’s a way to minimize or prevent this from happening in the future.

Develop an understanding with management for supporting scrum and the efforts of the scrum master

The scrum master will not succeed if flying solo. Development teams will be watching and looking for signals from management, those who pay them, on how they should act and react to the scrum master. If management ridicules or openly disagrees with the scrum master, without due process, the scrum master could lose credibility and once lost, will be very difficult or impossible to recover. The scrum master and managers need to work very closely together. They are both working to achieve the same goals but will have different methods and approaches to meet these goals. The scrum master needs to make talking with the managers a daily habit. In the past, I had worked closely with the development manager, meeting daily to discuss progress and new ideas. The development manager also went to the daily standups for all 7 scrum teams. He showed his support and commitment to scrum every day. If there was something I had done (or not done) that warranted discussion, we would talk privately and come to an agreement on how best to proceed.

Workshop with managers and development teams to understand limits and boundaries

One goal of scrum is for the development team to be self-organizing. This means being responsible for sprint outcomes, meeting expectations and commitments, and finding the knowledge and strength within the team to overcome obstacles.  What the scrum master can do is work with management to establish boundaries where the development team is free to do whatever they deem necessary to solve a customer problem. The workshops are attended by team leads and managers to set clear boundaries which eventually can become part of the teams’ Definition of Done. These can include security, test coverage, quality standards, and coding practices. The workshops created the environment where everyone could propose, understand the intent, and  agree on expected results from these boundaries. These workshops worked well and created boundaries that became standard across all teams. The boundaries can also serve as a challenge to the development teams to improve upon over time.

Train the development team on Scrum

This might seem obvious but I often see that giving overall Agile/Scrum training without constant follow-up is a waste. The scrum master can provide an overall introduction to scrum but should re-enforce the learning with multiple workshops on specifics including the ceremonies. The scrum master facilitates the workshops but the team designs the specifics on how the scrum framework is implemented. I had one team where both the development team and scrum master wrote down a set of expectations for the other during retrospectives. The development team defined what openness means as well as how they’d track improvements defined during retrospectives.

The idea is to incrementally improve the development team by picking up parts of the scrum framework and letting the development team figure out how to implement it. The areas that need improving will usually surface during the retrospectives but will also become known during the daily standups.

Have the development team create the metrics and measures they’ll use to know they’re doing better, worse, or neutral

How is a development team more likely to self improve: by having improvement metrics thrust on them or developing improvement metrics themselves? In my experience, the development team will better buy-in and track to metrics they created. Below is a list of metrics that the scrum master might suggest but leave it up to the development team to decide which, if any, they want.

MetricHow scoring worksWhat this measures
Number of Tasks added/removed during iterationOnce a user story is tasked out, count of tasks add and removed (a task that changes is counted once) - countHow well team knows the work and what done means for the story - INVEST criteria being followed and stories are small
Number of stories forecast Vs actually completed during iterationCount of stories forecast from iteration planning meeting and the count of stories completed and "Done" by end of the iteration - ratioHow well the team understands the work of the iteration - INVEST criteria being followed and stories are small
Average size of stories in iterationsSize in Ideal Days or story points against a common reference storyThe ability of the team to make the stories as small as possible and still provide some value to customers/users
Average score of "Value" per user storyHow happy was the customer for each story or group of stories completed during the iteration. 3-happy (stories solving their problem); 2-Neutral (not sure stories are solving their problem); 1-Stories did not help solve their problem; 0-no customers/users presentHow well the team understands the customer problem and understands how the customer wants it solved (or what success looks like from the customer/user POV)
Percent of user stories in iteration covered by automated System/Solution testsEnd-to-End test coverage using automated system/solution tests-percentageThe team's journey to automate end-to-end tests at the System/Solution level.
How independent is each user story in the iterationCount of stories in iteration that have dependencies-countHow well the team understands how to remove complexity
Test First Vs Test Last testing done in iterationScore per user story of Test First/Test Last strategy: 3-Test First; 2-test First and Test Last; 1-Test Last; 0-No Sytem/Solution level testsMeasure the team's journey to be outcome driven at the System /Solution level.
Number of hours in iteration spent helping team members grow and be betterTotal hours per iteration where the team spends time learning new skills, honing existing skills, teaching other team members new skills (T-Skills), interviewing and discussing customer/user problems with the customer/user-hoursMeasure of an aspect of a self-organizing team: caring and improving the team.
Number of hours in iteration waiting for somethingfor each story, track value adding time and wait state timeMeasure of cycle time for same sized stories, epics - time
Partially done workCount of user stories in progress at end of iteration - countBy counting stories that are in progress at the end of a iteration we highlight the potential waste of incomplete work. This count is minimized by having small stories and having the development team managing their iteration backlog.
How happy are team membersOnce per iteration assessment of how happy each team member feels-scoring - 10-very happy; 0-I'm thinking of quittingThis measures the general fun factor of work for the team. A happy team will work smarter and deliver a better product.

The team will probably ask the scrum master to collect these but be aware that the development team needs to own the metrics they have selected. By doing all the collecting, the scrum master may find the development team growing indifferent to the metrics.


Scrum masters don’t need authority to help the development team become better but will need to cultivate strong backing by management for Agile/Scrum. Highly visible management support can make a huge difference in the team’s ability to adapt, change, and improve.

The scrum master must resist the temptation to ‘tell’ the development team what to do, although suggestions may start the conversations. By respecting the development team and allowing them to make a majority of the choices, the team is much more likely to buy-in and adopt change. As scrum master, you are serving the development team, helping them help themselves.