To estimate or not to estimate 2013 ndc
•Download as PPTX, PDF•
0 likes•140 views
Talk from NDC conference in London December 2013
Recommended
Recommended
More Related Content
What's hot
What's hot (9)
Similar to To estimate or not to estimate 2013 ndc
Similar to To estimate or not to estimate 2013 ndc (20)
Recently uploaded
Recently uploaded (20)
To estimate or not to estimate 2013 ndc
- 1. TO ESTIMATE OR NOT TO ESTIMATE - IS THAT THE QUESTION?
- 3. Plans are useless, but planning is indispensible D.D. Eisenhower
- 5. 6
- 7. ESTIMATES HAVE SHORT SHELF LIFE
- 14. HOW DOES IT COME ABOUT? CRISIS BUDGET ≠ SOFTWARE DEVELOPMENT COST EXPERIENCE BASED DEVELOPMENT HIGH UNCERTAINTY
- 15. TRUST
- 16. Scrum Continuous feedback Feedback on delivery Detailed specification Mission statement Lean Startup Waterfall Old school product development
- 17. NEW PRACTICES?
- 18. AGILE CONTRACTS
- 19. TALK!
- 22. MVP
- 24. But wait a minute! Is a queue the best place to see the whole picture?
- 27. IF YOU HAVE TO ESTIMATE When Who How Why
- 28. TO ESTIMATE OR NOT TO ESTIMATE - IS THAT THE QUESTION?
Editor's Notes
- I hope you accept my slight homage to your great poet So, lets start by finding out who YOU are with regards to this topic How many of you do some sort of estimation? Hours/hard currency? Story points? T-shirt sizes? How many of you find it worth while? How many of you are good at it?
- This mornings show of hands told me I’m a rare species at this conference – a non-developer. My degree is in comparative literature Publishing – ebooks 2000 Interaction designer PM – industry conglomerate, telco, publ sector, education
- My stake in this – a customer - estimated, ended up discussing the numbers, optimizing for estimates - got them to change their stance – and the project changed - so, I’ve spent some time the last months researching projects and how they estimate – or don’t - my questions: 1 under what circumstances is it possible – or even valuable not to estimate- 2 and what does it do to a projects 3 and do we need other/new practices in their place
- Let’s define Estimates How – breaking down and discovering complexity (- Blink estimation – gut feeling - Analogous – on project level or on a slightly lower level (type of integration, type of UI)) Granularity – how detailed are you? Who – experts, entire team WHEN -Timing – how much up front? WHY - The use of the estimates? - to give a price - to make a go/no go decision - to build a business case - to measure performance
- -
- …and requirements docs And the more granular, the more expensive – but also (maybe) more accurate Good old agile practices tell us the entire team should be in on the estimating – being committed and all that. For me, who is of a good old-fashioned Norwegian social democratic mind, I love the idea of us all being in it together and reaching consensus. But it does indeed take time. Just think about your typical team of 6 developers sitting down for 3 hours every two weeks in order to estimate, that’s 18 hours, 36 hours a month, 360 hours a year, by Norwegian consulting rates over 400’ nok a year, ca 40’ Pounds. You could make some software for that sum And not only estimates. Before we even start thinking about estimating, someone else has spent hours, days, nights and weeks writing requirements documents.
- Often we estimate early, when we know little about the problem at hand We have these great conversations We try to be “not documentation driven” so we jot down as little as possible And then we wait 6 months And guess what – the great conversation is lost to us That conversation would have a lot more value if you had it just as you are starting to develop it
- Half of what you estimate will never – an should never be made And if the conversation is up front, you will not get a great value from the conversation either
- An oh, there’s the fact that we really aren’t capable of estimating - How many of you have read Kahneman’s Thinking fast and slow? He talk about us having two cognitive systems; on that is fast and intuitive and often acts without us even noticing. And one being slow, deliberate and almost painful to deploy. Vi er intuitivt gode på mange ting – men ikke på statistikk. Cognitive biases: Planning Fallacy Vi er mer over-optimistiske når vi estimerer noe vi skal gjøre selv We always think a task will take less time than it actually does Tasks that are far into the future seem more clear and less cluttery Hofstades law: ” Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law” Winner’s dilemma: lave estimater gjør det mer sannsynlig å vinne et anbud, men også mer sannsynlig å sprekke på estimater (over-optimisme) Fundamental Attribution error: tilskrive andres negative konsekvenser til deres personlighet, mens egne negative utfall til eksogene, utenforliggende faktorer. We’re strongly influenced by “irrelevant” informasjon, ancoring og priming Confirmation bias: we look after – and more easily see information that confirms our existing beliefs But then again Parkinson's law is the adage which states that "work expands so as to fill the time available for its completion”
- We do what gets measured! We game things So we start optimizing for reaching the most arbitrary goal – one that was set at a point where we knew the very least. Shading – you start adhering to the letter of the contract instead of its intention Jerntriangel – men arealet til triangelet er Kvalitet – hvis du er pressa på alt annet, er det kvaliteten som lider – og det kan fort være et ikke-tema. The elephant in the room – efficiency – deadlines tends to make us more productive without necessarily skimping on quality. Up to a certain extent. And estimates are probably not the best way to create that kind of pressure you’re looking for. Deadlines and timeboxes might be more adapt
- To borrow from Woody Zuil: estimates work as a hardening agent …vel, kanskje ikke estimater, men detaljert up-front planlegging som utelukker muligheter og dermed stenger det kreative rommet, mulighetsrommet Og når vi kan være kreative så lager vi bedre løsninger for kundene våre Og vi har en mer morsom, givende og motiverende arbeidsdag
- So estimates are problematic. Is this realization unique to software? Of course not. Well, lets look at what other similar businesses and research tells us (Drip funding? Start with a pace – what size team would be the best to give you the certainty you need – and that you as a customer could deal with the output from Focus on the co-creation)
- Research on other fields where uncertainty and complexity is high and creativity if not necessary, then at least sought after, show that there is indeed a correlation between these characteristics and the degree of Contractual incompleteness. It means that leaving requirements less complete and detailed then is “normal” or easily imaginable. You move “negotiating” to a point after the contracting, closer to executing instead of in the contract. And what is at the core of your good old software development contract? Requirements, exactly – and their estimates as a response. Cultural aspect, easier in cultures that are higher on trust than others. Høy usikkerhet Endring Kompleksitet Varierende grad av Tillit Domenekunnskap Modenhet hos kunde Nyutvikling vs forvaltning
- But even though you have these incidents, context or situations, you still need that magic, secret sauce for it to become an
- This all depends – and rests on TRUST And if you already have a client, they know you can deliver, then anything is possible – even quite easy And if you’re beyond Version One, then making decisions at the latest possible stage makes sense to most people But what if the client is new to you – and you as a vendor to them? Not so apparent We could say: live with a up front specified contract the first n months, build trust as you go and hope for better days ahead We could do even better, right? We have large – public (sic!) – clients in Norway that are testing another model. They are commissioning 3-4 possible vendors to do a controlled PoC. All from a few days to longer hauls. They do this in order to get a better idea of which vendor to choose – and to learn themselves. And to build trust in the actual team that are going to do the project. Other clients use an incentivized fixed price contract for a limited time in order to build trust and with the goal to have less formalia as trust (hopefully) builds
- Well, not only trust, you still typically need some control
- So in order to build trust, what do we do?
- Well, for one we need to have some formalia that gives us a framework – or at least some slack compared to the prior restrictive frameworks We see agile contracts showing up in Norway now – and they are indeed used also by the public sector. What’s agile about them is that they deliberately leave the scope – the requirements - out of the contract. What is specified is the kind of competency is required and a way to agree on scope and price.
- As I said; plans are useless, but planning is indispensable. Keep talking, don’t forget it in all the processes and queues
- And do the talking, especially about the details and the solution as close to implementation as possible The process of writing is certainly in itself a creative process, something happens when you formulate something – and it is that way with code as well, don’t you agree?
- A PO I interviewed said: “The point is to get something, some working software out to the users. That’s when they see what they need. And the old requirements aren’t that relevant anymore” This is good old Agile manifesto, right But it’s even more “open ended” then that. It’s about seeing software development as more of an organic growing process than a product under construction. The construction metaphor is indeed a poor one. The other thing about getting software out there, is that it “magically” builds trust. Several of the projects I have researched describes the control regime as being quite strict until they (the steering committee) see an actual working piece of the solution. And that does not mean “The Big Bang”, just a piece that is real and works. (But be ware of prototypes, it can build too much trust – they think you’re basically done and will wonder what the hell you’re doing the next 14 months)
- Are you familiar with the term? To test a hypothesis To deliver value at the earliest possible time
- I don’t know if this concept makes sense to anyone but me, but lets try it out on you. The first dimension – the MVP – the thread through the solution in order to test you hypothesis The second dimension - enriching the functionality – building something that is actually marketable and viable – so far it’s what’s been called storymapping, right? The third dimension – the richness of the user experience. This is also a choice and we need to be able to talk about that too. It’s not a all or nothing choice OVERGANG Queue – pull, prioritize, waste reduction – it’s starting to sound a lot like kanban, right?
- Let’s not throw the baby out with the bathwater. Lets not stop talking about the bigger picture – even if we don’t know the stories we are to make in 6 months, we know the mission and vision of what we’re making. Let’s not get buried in our queue an lose sight of that
- Let’s not forget to look at the big picture – together Not just the PO and the UX gal – but the entire team - motivation know what goal you are steering towards in order to make the small, minuscule choices and assumptions you make every day - seeing other possibilities
- But lets not limit ourselves to looking a The Big picture – maybe there are several bigger pictures. We know Forecasts are always wrong because they presuppose One Future, so let’s expand our view of the possible outcomes and futures
- IF YOU REALLY HAVE TO Estimate? (ask who a couple of times) WHY - The use of the estimates? - to give a price - to make a go/no go decision - to build a business case - to measure performance How – breaking down some, few things - build checklist - have a list of analogous projects/situations (- Blink estimation – gut feeling - Analgous – on project level or on a slightly lower level (type of integration, type of UI)) Granularity – keep it real Who – just the right amount WHEN -Timing – as close to development as possible?
- NO, MAYBE not, maybe it’s more about how you do it Not too lengthy Not too soon Not too many people JIT Use it if you must for making decisions – not to punish you team.