I Need a Date: Organizational Anti-Patterns
So, you need a date? Everyone wants a date. Try visiting a ‘dating app’ or some other dating application because in this blog post, we are referring to date as in a timeline and how all anyone ever cares about is a date/timeline plan that is typically wrong anyway ☺. Some Scrum Masters, Product Owners and Agile Practitioners might wish they can tell customers “try visiting a dating app,” but that just isn’t reality, nor is it clearly in the interest of customer service excellence.
Yet time and time again when working with product teams building software applications, the big question always is “When will it be done?”
This question seems to loom so large that leaders, Product Owners, stakeholders (not to mention their many extended analysts, managers, delivery managers, tech-leads, architects, and others) ask the question like wildfire, pressuring software development teams for a timeline as if the team was building the next mechanical heart that was going to save a heart patient’s life tomorrow.
“No Rush, But…”
As an Agile Coach and Scrum Master working with numerous clients, I can share an endless list of examples:
At one former banking client, the development team’s technical manager continuously asked the team when they would be done and informed them that they had to finish ALL of the items in the Product Backlog in 3 months, yet he kept pulling the team off of their work to focus on production/maintenance items or other work that required their help – how can a timeline ever be correct with all of the interruptions?
At an entertainment company, multiple teams worked to get various software products completed as many teams had dependencies on each other. These teams would spend 2 whole days in a planning session trying to plan out their work and determine when it might get done because leadership wanted to have dates.
At a professional services client, leadership and others promised dates and timelines without ever conferring with the actual team who would build the product; the team was not even assembled yet and the work was not fully understood. As a result, the business members promised a product within a timeline. Seven months after the timeline they were still waiting and more frustrated.
At other clients, I have seen teams hounded for timelines. The team members were secured, but were not 100% allocated to projects, so when they provided timeline estimates, they were not able to factor in time lost for ‘context switching’ (a.k.a. multi-tasking across multiple projects) – no one can properly factor in time for ‘context switching’ across multiple projects and activities.
Other clients forced teams to use overtime in order to stick to a timeline or plan. This might work for a Sprint, but at what cost? The cost of quality. When a team is asked to work overtime for continuous periods of time, quality degrades. The pace is not sustainable. The team is tired and burnt out. Defects cost more time and more money – extending the timelines.
Progressive Refinement
The list of examples goes on and on, and what have people gained in return? In many cases, the return on investment for utilizing precious time to estimate everything upfront just isn’t there. The time spent on estimating and planning (planning, NOT ‘project plans’) should be viewed as an investment. The goal should be to invest in estimating and planning ONLY to the extent that the effort is rewarded. As Dwight Eisenhower stated, “In preparing for battle, I have always found that plans are useless, but planning is indispensable.” This “planning along the way” means adjusting plans as discoveries arise and as facts become known. This is also known as “Progressive Refinement.”
All of the talk about timelines and plans is ultimately futile in the complex world of software development. No degree of planning, scheduling, or setting deadlines is going to make the work more predictable. So instead of focusing on dates and plans, practice DIVERTING the timeline conversation to focusing on delivering the highest value working software to customers every sprint. After doing this, if the timeline question still persists, then the seven tips below might help us to help leaders, managers and others understand a more effective way of getting some return on investment when asking for timelines.
Timeline Diversion Tips
Try to work with your customers and have them focus only on what they deem as the absolute highest value features & understand how those features will provide the highest value return on investment. This is easier said than done because after all, customers want it all. Apple did not build the first iPad with all of the bells and whistles. Initially, it was a portable tablet PC with web access, contacts, and emails as some of the initial ‘highest value’ features. This enabled Apple to get it out to market and test the demand. Later, more features were added. Work with your customers to create an end-to-end barebones product that has only the highest value minimal features needed. All other desired features can be phased in throughout future product releases. A Scrum Product Owner is valuable in helping customers with this. A “User Story Map” Jeff Patton of “User Story Mapping” is a helpful tool to use to find the “Minimum Marketable Features (MMF).” Mike Cohn of “Better User Stories” and author of “Agile Planning and Estimating”, among many other top-notch books.
Secure a small (3-9 ) Scrum team of dedicated and 100% allocated people that have all of the skills & experience necessary to build the product including testers, and let them self-organize – don’t forget to include the experienced Scrum Master and the experienced Product Owner (these are in addition to the 3 to 9). Enable them to stay focused on only this ONE product, and keep the same team players on the team without adding others.
Have the Scrum Team work with the Product Owner to determine how to organize the work into a Product Backlog (in other words, a “customer wish list”). The wish list is best visualized from a ‘user’ angle – meaning a list of work written from the perspective of ‘user-desired features,’ NOT technical items/work. For example: ‘Create customer request’ vs. ‘Build a web platform.’
Ask the team to break the features down into smaller product backlog items and use relative estimation (i.e. the Fibonacci sequence, see ‘Fibonacci in Scrum’) to size the items. A Scrum Master or experienced Product Owner can help train a team on relative sizing.
Set the Scrum team loose to start development on ONLY this one product – in other words, start sprinting. Get out of their way and avoid becoming overly involved (especially if you are a manager or leader). Instead, be there to support, listen, and help them IF THEY NEED YOU, and stop doing all of the talking & commanding. When the sprint is completed, you will be left with the sprint velocity and working features
Repeat the steps above and have the team continue to sprint for 2 to 3 more sprints. This will enable the team to learn more about their relative estimates, the technologies, the unknowns, and you will get an average velocity. And the completion of the first 3 sprints is a good gauge to determine how long it took the team to deliver the first feature or first several features.
From this point onwards you can have the team relatively size the remainder of the items in the product backlog so that you can determine approximately how long it might take to deliver the remainder of features. For example, if the backlog total of relative sizing points is 200 and the team’s average sprint velocity is 20, then 200 divided by 20 is 10 sprints. If each sprint is 2 weeks, then 10 x 2 weeks = 20 weeks. CAUTION: a percentage should always be added to account for Feedback. Feedback comes in the form of defects, customer changes/tweaks, new discoveries made that were not accounted for before, but are necessary. A good practice is to add a percentage for feedback.
So take the 200 total of backlog points and divide it say by a feedback percentage such as .6 (this factor will vary based on the history in working with the team building this type of product and other factors, but it gives you the increase in the product backlog points - in this case, the backlog will grow by approximately 40%) to find out what 200 is sixty percent of. Reference “Real World Examples of Project Status and Updates on an Agile Project Webinar” by Fred Mastropasqua of ClearlyAgile
200 divided by .6 = 333 points (meaning 200 is 60% of 333) which means the backlog will grow by about 40%.
Take 333 points and divide that by the average velocity of 20. You get 16.6 sprints
16.6 sprints x 2 weeks (for a 2 week sprint) = 33 weeks
So now you have a best case and worst case range of 20 to 33 weeks for a backlog of 200 to 333 points
Adjust the Scope
We all can help DIVERT conversations away from the “timeline” question by saying “you will receive valuable functionality within two to three sprints. Please help me in this process by providing product feedback during the sprint review and process feedback during the sprint retrospective.” Once the product development team has been sprinting for two to three sprints, they will gain valuable knowledge and insights into how they work together, they will start to understand the work, the unknowns, and the time it is taking them, and be able to make course changes. They can start to accurately understand HOW BIG (a.k.a. how much effort) each work item is, and if they are using relative sizing (as in story points), they will start to form an average velocity that will help them predict how long it might take before that next product feature or two will be completed.
If all else fails and you find yourself in dire straits ‘adjust the scope,’ not the team size, not the budget, not the schedule, and certainly not the quality – this all goes back to Tip 1 in finding the highest value minimum marketable features.