Agile is... Never Having To Commit To a Deadline?!
Vložit
- čas přidán 12. 10. 2015
- The world of business is full of deadlines. But deadlines and Agile don't seem to mix...
= = = = = = = = = = = =
New for 2024: my best-ever training:
"How Your Agile Teams Can Achieve Predictability and Productivity WITHOUT Burnout"
→ www.developmentthatpays.com/w...
= = = = = = = = = = = =
The world of business is full of deadlines. But deadlines and Agile don't seem to mix. Picture the scene:
- Location: a small conference room.
- Present: a Software Development Team, an Agile Coach and a Business Manager.
- Subject under discussion: the launch of a new website.
It was all going well until the Business Manager asked this question:
"When will the website be finished?"
Oh dear.
Enjoy the video.
Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186
-------------------
7. Agile is... Never Having To Commit To a Deadline?!
#DevelopmentThatPays
Are you responsible for a SOFTWARE DEVELOPMENT TEAM Is your team an AGILE Dev Team Have you ever had a “difference of opinion" with your team Or a full-blown argument Were you, by any chance, discussing an important DEADLINE The world of business is full of deadlines… but deadlines don’t necessarily “compute” for an agile team. But there may be a way of both sides to get what they need. Hi this is Gary, welcome to Development that Pays Picture the scene. A small conference room at the BBC in White City. In attendance, a development team our Agile Coach and a Business Manager. The subject under discussion: a new website for BBC Worldwide. My memory of the first part of the meeting is hazy. But I have a very clear recollection of what happened after the business Manager asked this question: When will the website be finished It was clear he wan’t looking for an answer like “ next Spring”. He was looking for a date. We turned to our Agile Coach for the official answer. But Mr Agile refused to answer the question. Mr Business was taken aback. Really Surely we had some idea After all, the people in the room had has previously build several similar websites. If anyone know how long it would take to create a site very-like-one-we’d built before it was is, But the Mr Agile would not be moved. He could not and would not commit to a date. Mr Business was incredulous. Didn’t we realise that launching a website is a bigger thing than just building a website: Editors need to be hired Copy needs to be authored Launch partners need to be engaged WE NEED A DATE! But Mr Agile would not be moved. The rest of sat in silence staring at our shoes…. The argument between Mr Business and Mr Agile troubled me. And not just because it was toe-curling awkward. Here’s my dillema: I agreed with Mr Business : I could see that there needed to be a launch date. I also agreed with the Mr Agile : launch deadlines and the agile approach don't really mix. Can the two really co-exist At the time, I really wasn’t sure that they could. But I think that maybe they can. Let’s take a look. I don’t know much about Mr Busenss' background, but it’s not much of a stretch to say that he was used to working to deadlines: he did, after all, work for a major broadcaster. Programmes go out at specific times on specific dates. There’s zero time flexibility. So he’s used to projects that start slowly… and ramp up… and things would ramp up again as the broadcast date arrived. That’s a graph of effort. But what about a graph of value More specifically, customer value. Well, for almost all of the project, the value to the customer is zero. It’s only towards the end of the project that all of the elements come together in a programme. In fact, it it’s a sign of good project management when things DON’T come together until the last minute. What about an Agile project What does the customer value curve of an Agile project look like It might be a while before anything worthwhile can be released, so the line starts at zero. But it’s not long before something is released*. A very base-bones website, for example. Now I’m not suggesting that a bare bones website is released to the public... But at this point, and at any point in time after this, we have something that could be released to the public. At this early stage the potential customer value - lets call it that - would be low. Say 10% The potential customer value increases as the team adds new features. One of the key tenets of Agile is to work on the most important features - the features that add the most customer value - early in the process. So the value curve increases quickly as this high value features are added. We then enter a phase of diminishing returns as low value features are added.
• Agile is... Never Havi...
• Agile Estimating and P... - Krátké a kreslené filmy
Great video Gary but a bit simplistic no ?
What happens when you do not have metrics and your client value chart is simply a generic chart ..
You business client wants factual data , how do you give that if there are not any ?
Live all the work you guys do .
Keep it up 👍🏼
you cannot specify a date where all requirements are met. But you can specify a date where at least the most important are in place. You can then always add more stuff later.
there is always a next release.
Think you put it better than i did 👍.
Great video! I wish a lot of the contracts I've worked on had that listed in the Statement of Work so the client understood they were getting "something close to what they want that was useable" by x-date that was updated based on our projections from burn downs. It seems many ignore that sweet spot and ask "When is it going to be done?" No one seems to ask back "Why don't we launch now?". For many clients it seems all 100% of identified features must be in, else the product is worthless to their customers, and not worth anything... which I struggle to identify with and solve.
+Jesse Warden - You're right: I've seen the "100% of identified features" situation on numerous occasions. There must be something in the human condition that makes people think "if we don't get it now, we'll never get it".
Development That Pays Given most release cycles for larger companies are in the months time frame vs. daily/weekly, I get the trepidation. Maybe they're just reinforced through horrible experiences and they assume a waterfall mentality of "tons of features followed immediately by tons of technical debt" so have lost their faith.
Okay, again, all my congrats for the video... I love to discuss. That deadline issue. What is the promise of agile software development over the waterfall? I understand it is that it will do away with all/most/some problems of waterfall, that agilists often call 'traditional' (is agile progressive then?). Okay, one of the problems of waterfall is that often enough the schedules and budgets are overrun. Fair enough. That is the case with hardware projects (an example from construction: Poya bridge in Switzerland, quite unbelievably) and software projects, and hardware+software projects (Airbus A380). So, agile is supposed to remedy that. And here, the agile team with a coach would not commit to a deadline. Consider the classical case a video games company that wants to put a new game on the shelf before X-mas, and the range of completion time makes it land somewhere between the 15th and 30th of December. Or a more serious example of a major equipment upgrade in a hospital. The hardware is all installed but the software is late, still in testing, and those tests don't seem to finish, so testing the whole system is postponed, and the hardware is idle for a few weeks. Perhaps, if the whole setup was operational as planned, some lives would have been saved or prolonged. In a programme context like this a deadline is a deadline, there is no flexibility for it whatsoever, because the different components of the programme must come out in sync. Back to the ideas and methods. There are the project triangles. In waterfall approach the triangle has a fixed scope and the time and budget often get flexible if risks materialise. The agile triangle is put upside down. The time and cost get fixed definitely and there is flexibility around the scope; some features must be there for the system to work at all, or be legal, or make sense economically, but others should be there, and others still are nice to have, and can be added later. Well, that’s at least how things are on the DSDM planet, which seems a little different from SCRUM (not better just different). On a different note, watching bridges being built a great. I recommend having a look at the construction of Millau bridge, over 2 km of length, 343 meters high, no deadly accident, and opened three weeks ahead of deadline.
Really enjoyed reading you comment.
I have to confess... that I'm a developer(!) That means I know something about Agile at an individual team level... but that's about it. Multi-team context? I know very little. Major infrastructure project context? Zero.
Your video game example is one I *can* comment on. The Agile "magic trick" is that the game won't be finished on the 15th... nor the 30th... nor on the 14th of February. It will keep evolving. Trace the line in the other direction: it's likely that it was "playable" sometime around mid November. From that point forward, it becomes a business decision when to launch. It's a question of "when", rather than "if".
Contrast with the waterfall equivalent. Mid-November: nothing. Early December: nothing. December 15th: nothing. Nerves are jangling. If it comes together on the 16th, you celebrate. If it's delayed by a week, you're screwed. In this case, it's less a question of "when" you'll be able to launch: it's a question of "if".
Would love to know your thoughts on that.
-----
Thanks for reminding my about the Millau bridge. A few years ago, I took my family on a lengthy detour drive over it. Going along beside us was none other than Sir Michael Gambon - better known to my kids as Professor Albus Dumbledore! He was driving a Bentley, as I recall. Very nice.
If burn-down charts were applied, the measuring time of the ideal tasks remaining could be used to determine deadlines I suppose.
I think Mr. Agile owes Mr. Business a clear answer. Afterall, the method is not as important as the result. So I am thinking if Mr. Business can freeze requirements after 2-3 sprints to make sure MVP requirements are in place, then Mr. Agile should be able to 'clearly' estimate a completion date. Now I know this might be against Scrum or Kanban core principles but this can work pretty well in my opinion.
Yes, I think I was too accommodating of Mr Agile! He does indeed owe Mr Business a clear answer - and your answer is a good one.
This is a good suggestion where the key phrase here is freezing requirements, which is always easier said than done. I would also add that having missing or incomplete requirements can make this task of estimating just as difficult, but that's another story.
Freezing requirments totally contradicts agile methodolgy where you have always to be responding to change. In my humbel opinion the correct question should be " after how many sprint we will have a good functional webstie that will be valuable to the customer " ? and since we know each sprint is about 2 weeks times, we will have a good estimate that way
The use of Agile for this project is just wrong. The requirements are well-known and of fixed scope, and the customer wants it on a fixed timeline. "Oh, Agile can't promise a particular date, blah blah blah", OK, don't use Agile. There's no need. Agile is for delivering the best possible solution to problems with unclear requirements while incrementally delivering value; it exists only for that purpose, no other. It's not a cure-all silver bullet that must always be used on every software project, and starting any project with "OK we're going to be Agile, what's the problem we're solving?" is stupid and wrong.
@@BittermanAndy I see your point, agile is not an objective, rather a method. Could/Should be used where required just like other methods.
Genius
How does Mr. Business respond when the unknown requires change in the deadline? It's a deadline after all. Release early and often. Customers and business folks are used to waiting for large batches. Once they experience small and frequent releases they generally embrace the empowerment of being involved without needing massive and infrequent acceptance periods.
That makes perfect sense to me... as someone who is familiar with agile. But imagine your meeting with someone for whom "massive and infrequent acceptance periods" is the norm. What do you say?
I usually start with asking them to outline the benefits (perceived and actual) and risks with business as usual. Then I present them with benefits, including risk management related to their concerns, of more frequent feedback. A metaphor that can be helpful, though not perfect (I'll take suggestions), is looking for sticks in a haystack. Being able to terminate early due to completion can also be a selling point. This is always an interesting topic to discuss, as this is certainly a common challenge. HTH
It does help: thank you your thoughts. It's a question that's central to what "Development That Pays" is intended to be about: the (hopefully successful) interaction of "technical" and "business" concerns.
Agile just confuses me 😪 i dont know what is a story and what is a task and if a new story should be born out from a task... uh sigh.
You know what, I'm hazy on that stuff myself!
There are no hard or fast rules, it's whatever works for you and your project.
Hi, Great video! My son, Paul, would be grateful if you would allow him permission to use 2 of your videos in his college project?
Sure - no problem at all 👍