Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Semelhante a Asking Why (The Right Question for the Right Requirements)
Semelhante a Asking Why (The Right Question for the Right Requirements) (20)
Último
Último (20)
Asking Why (The Right Question for the Right Requirements)
- 5. question theright fortheright conversations analysis technology architecture design code software
- 6. ask
- 7. OKAY,LET’STALKABOUT WHAT’SWRONGWITHSOFTWARE HOWASKINGWHYCANHELP TOOLSFORSUCCESS HOWASKINGWHYCANHURT
- 11. Mostsoftwaremethodologies focusoncostandcraftsmanship “Howdowedevelopsoftwarein thebestpossibleway”
- 16. why ask why
- 33. tools use
- 34. whys
- 36. active listening
- 38. changeyour words
- 41. IGETIT.
- 45. Asacorporatesafetymanager,Iwantto detectwhenreportingofnear incidents andhazardousconditionscomparedto actualincidents mightrepresentadecline inpreventive activitiessothatIcantake actiontoincrease preventivereporting wherethedecreasehasoccurred.
- 52. idon’tknow
- 54. thanks!
Notas do Editor
- In the software space I am responsible for making sure that we deliver the best software possible I’ve worked for big companies (IBM, Motorola) I dig small companies Enough about me: Quick demographics survey what does everyone do (PM, BA, dev, test)? What size company? What kind of company (software is main business?) Having a good mix of roles for this talk is not a problem, because:
- This talk is for everyone. It’s not about any specific methodology - works for agile and non-agile Also not for any specific role – fits everywhere, and highly encouraged for everyone, because…
- … the title of the talk is misleading – this isn’t really about requirements It’s about how to make the entire software development process work better
- So as you see, it’s about the right question for everything in the process… The right question for the right SOFTWARE
- The question is “why”. Thank you, have a nice night. Seriously, we’re going to talk about why asking this question can be the most important part of your project
- Look at all of the roles involved here Things can and do go wrong at all stages
- Failure research – here are some studies showing software project failure rates: 2001 Gartner Group: 50% 2002 Butler Group: 70% 2005 AMR Research: 18% 2006 AMR Research: 31% 2007 AMR Research: 29% 2009 Forrester Research: 47% Who has experienced a failed project? Less clear is what constitutes failure
- Non-agile: Waterfall and Unified processes Very cost focused Want to make sure everything is done to the letter on time and budget Agile: XP and Scrum Want to adapt to changes during the process Very focused on quality and reducing friction But what causes those cost overruns and that friction in the first place?
- We have to remember that we are not developing software for software’s sake – there is a purpose behind it
- Going back to this depiction of miserable failure, how much of it focuses on the misunderstanding of the needs? Look at the first and last picture
- Even if we built what was on the left with perfect quality, under budget, and with everyone happy, the project would have failed.
- "Eliciting" requirements is a misnomer. Without understanding the need it is guessing on everyone’s part.
- When we assume the customer knows exactly what should be built, we start by focusing on the “what”. This often manifests in the form of mockups or “functional requirements”. Anemic tools that result in lackluster, valueless software.
- Why is the question “why” so different?
- Asking what to do leads to the requirements of what to build, which gets the team focused on the “solution”. But how can we focus on the solution without first understanding the problem? Asking WHY we need to build the software gets us focused on needs, which leads to us focusing on understanding the problem.
- Other questions lead to all the stuff we need for a project. “How do we DELIVER SOFTWARE in the best possible way.” “Why” leads to focusing on the reason we’re building it, leading to getting the most value. “How do we MEET THE NEEDS in the best possible way.”
- Developed by Toyota (like Kanban!) Simple application: Ask why iteratively to get to the deeper needs Turns out it doesn’t work so well for well defined processes For things that are fuzzy though, it’s great for getting to deeper roots
- It turns out that user stories are a great fit with this technique Focus on the “So That” part of the story. Clarify it, and put it into the need. Repeat. We’ll do an example in a bit.
- It turns out that simple repetition of someone’s words back to them drives deeper analysis.
- The actual word "why“ may trigger defensiveness and hostility – more on that in a bit. Learn to use simple investigation techniques and gentle probing questions to get you deeper.
- Many people only think in terms of proposed solutions. Going away from a solution and towards the problem can seem counterintuitive. The needs are very often elusive. YOU need to truly understand the pain the customer is feeling. Put yourself in their shoes all the way, until you feel it, and would want to ask for a solution yourself. Focus on the problem before ever thinking of software.
- Let’s dig in and extract a real reason “why”. Here’s a typical user story. The customer (or product manager!) might give you this story say “I think this should be a pyramid chart showing the counts and percentages of each type of entry”. Let’s ask why.
- Ask why, and add the answer to be the “so that” part of the story. Oh, they’re looking for ratios. Okay, that makes some sense. Let’s go deeper.
- Now here’s the trick – move the “so that” to be the “what” they are actually asking for, and figure out the deeper need. Ask why. Oh, they’re looking for something external to the software – they need to know if their prevention measures are working. Very interesting. Here’s where we start to get to the ah-ha moments, and get closer to the real need. Let’s repeat and go deeper still.
- Another ah-ha – now this sounds like a need. Something concrete that you would do regardless of software. Notice how this user story isn’t about software, charts, or anything else technology related. The software is just the tool to solve the real problem.
- If we built what the customer explained – down to the way they wanted it designed – we’d end up with the result on the left. Notice that there’s no way to solve the actual problem with the information. What is the ratio? Has it gone up or down over time? Are my prevention measures working? The chart on the right answers the question at a glance. Uh oh, the ratio has gone down over the last month or two. We need to take action to increase preventative measures. Useful software to solve an actual problem.
- The comedian Louis C.K. has a great routine about his kid asking why until he reaches existential crisis. Part of the art of asking why is knowing when to stop asking why. There is definitely a point of diminishing returns. Don’t piss people off.
- Someone who doesn’t understand the problem CANNOT help you understand the problem. Many times you’ll hit a wall where a PM or other intermediary is not able to answer your questions because they don’t actually know the why. If you hit this point, STOP. Find the person who does know why. If you can’t find them – why the heck are you building the software?
- If you are perceived as being incompetent, you will not be effective. Reaching real reasons when you ask why takes skill and practice. If you are not a good communicator, you will make people very angry. Know your limitations, and get help when you need it.
- This can be the most insidious problem of all. Hitting a point where a person (the one asking for the software) doesn’t actually know why they need it? This is trouble. Sometimes there is no problem. Sometimes something other than software is needed. Sometimes you wake a sleeping giant. But it’s better to discover this now than delivering something that provides no value to someone who doesn’t understand what they need.