Home
Videos uploaded by user “Development That Pays”
Scrum vs Kanban - What's the Difference? + FREE CHEAT SHEET
 
05:32
Scrum and Kanban have much in common - and some striking differences. Watch the video... and grab your FREE CHEAT SHEET. Download your FREE CHEAT SHEET: http://bit.ly/scrum-vs-kanban-cheatsheet If you've been wondering about the differences between Scrum and Kanban, you've come to the right place. Scum and Kanban are perhaps the best known of a number of Agile software development. They have much in common - and some striking differences. And don't forget to grab your copy of the Scrum vs Kanban Cheat Sheet. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 68. Scrum vs Kanban - What's the Difference? + FREE CHEAT SHEET Scrum and Kanban are perhaps the best known of a number of Agile software development frameworks. Let's break that down: Software Development, in very broad terms, looks like this: The Product Owner decides what to build, The Development Team builds it, and Customers use it, experience it, benefit from it in some way. What makes software development Agile is that value is delivered to the customer in small increments. And - importantly - feedback is gathered from customers and fed back into the process. It's the Product Owner's job to take input from customers - and from various Stakeholders - and organise it into a prioritised list of features and User Stories. The list is known as the Product Backlog. What happens between the Product Backlog and the Customer is what distinguishes Scrum from Kanban. As we'll see, each has its own routines and rituals. It's this person's job (see below) to help the Product Owner and Development Team to adopt and maintain good habits. In Scrum, the role is known as the Scrum Master. In Kanban, the role is known as the Agile Coach. Something that Scrum and Kanban have in common is that both are PULL systems. Without getting into two much detail, a pull system ensures that work gets from Product Backlog to Customer in the shortest possible time. A pull system also helps to uncover bottlenecks in the process, which helps to ensure that work gets from Product Backlog to Customer in the shortest possible time! As you'll see in a moment, Scrum and Kanban implement the pull system in two strikingly different ways. Scrum ----- Scrum teams work in a series of Sprints, most commonly two weeks in length. Each Sprint it proceeded by a Sprint Planning Meeting, run by the Scrum Master and attended by the Product Owner and the Development Team. Together they select high priority items from the Product Backlog that the Development Team believe it can commit to delivering in a single Sprint. This is the "pull" I was talking about earlier. The selected items are known as the SPRINT BACKLOG. For the next two weeks, the Development Team focuses on working through the items in the Sprint backlog - and ONLY those items in the Sprint backlog: in all but the most exceptional circumstances, any new requirements that arise have to wait for the following Sprint. It's common practice for Scum teams to use a board to track the progress of the work. It's called a Scrum Board... or an Agile Board... or even (slightly confusingly) a Kanban Board. Each day during the Sprint there is a Scrum Meeting: it's a stand up meeting where the team takes a maximum of 15 minutes to discuss progress and identify any "blockers". At the end of the Sprint, the work completed during the Sprint is packaged for release, and any incomplete items are returned to the Product Backlog. The Sprint ends with two rituals: The Sprint Review, which is a demonstration of new functionality to Stakeholders. The Sprint Retrospective, which is an examination of what went well, what went badly and what could be improved. The aim of the Retrospective is to ensure that the next sprint is more efficient and effective than the last. And that's Scrum! Kanban ------ Kanban does a few things differently. There's no two-week sprint: Kanban is a continuous process. And there's no Sprint Backlog; the "pull" system in Kanban happens in a different way, via Work In Progress (WIP) limits. If an Agile Board is useful for Scrum, it's a necessity for Kanban. Each column on the Kanban Board has a Work in Progress limit related to the team's capacity. For example, a team with two developers might set a limit between two and four items. The lower the better. Let's see the pull system in action: When testing of a particular feature is complete, the corresponding ticket moves to the "Done" column. The empty column is a https://www.youtube.com/watch?v=rIaz-l1Kf8w&list=PLngnoZX8cAn8VEVJtgWUKyidEaV-mJKKe https://www.youtube.com/watch?v=https://www.youtube.com/watch?v=C3P44ZYXTBs
Views: 329511 Development That Pays
What is BDD? What is Behavior Driven Development?
 
04:06
61. What is BDD? What is Behavior Driven Development? // Grab your FREE TDD vs BDD Cheat Sheet: http://bit.ly/2lvse8U If you're looking for a non-technical introduction to Behaviour Driven Development (BDD), you've come to the right place!We'll start with the archetypal example of taking cash from a cash machine. Key take-aways: - The test is written in (more or less) plain English - The test made up of three distinct sections: Context, Event, Outcomes - Context is the "starting state" - Event is the thing that the user does - Outcomes are the expected results of what the user does - The test describes in a very direct way the set of the behaviours that the customer can expect from the system. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 What is Behaviour Driven Development Aka BDD I'm glad you asked. Let's jump straight in with an example of a Behavioural Test for a Cash Machine: Given the account balance is £100 And the card is valid And the machine contains enough money When the Account Holder requests £20 Then the Cashpoint should dispense £20 And the account balance should be £80 And the card should be returned The first thing to notice is that the test is written in - more or less - plain English. The second thing to notice is that the test made up of three distinct sections. In the BDD world they're referred to as Context Event Outcomes Context is the "starting state" Event is the thing that the user does and Outcomes are the expected results of what the user does. If you were with me two episodes ago, I did a test that could be called "Starting my motorbike." I could describe that test in Context / Event / Outcomes format as follows: Given the battery is charged And there is sufficient petrol in the tank And the petrol tap in in the on position And neutral gear is engaged And the throttle is open 1/4 When I operate the kick starter Then the engine should start Perhaps their greatest strength of Behavioural Tests is that they describe in a very direct way the set of the behaviours that the customer can expect from the system. The list behaviours taken together form a "contract" of the complete set of behaviours that the system is expected to exhibit. If all Behavioural Tests pass then the contract has been upheld; if any of the tests fail, the contract has been broken. Behavioural Tests can be written for a system at any time: before, during or after development. It can be very difficult to write unit tests for an existing system but writing behavioural tests for an existing presents no special difficulty. The case where the tests are written first is termed Behaviour Driven Development. The plain english nature of the Context / Event / Outcomes format means that the business people can focus on describing the behaviours that matter to the customer. When the Development Team begin their work, every one of the tests will be running and - in the absence of any code - failing. As more code is written the tests will begin to turn from red to green. When they're all green, the job is done. There's another benefit here that may not be immediately obvious. As a developer myself, I can confirm a tendency to write too much code Or code that does too much Or code that includes some degree of supposed "future proofing". BDD helps to rein me in. To keep me focused on getting the behavioural test to pass. Nothing less.... And, importantly, nothing more. If all of this sounds too good to be true, I should point out a couple of drawbacks: Behavioural Tests tend to be slower to run than unit tests - often by one or more orders of magnitude. Behavioural Tests, when they fail, indicate that something went wrong... but may give little or no indication of the root cause. If you saw the last episode, you'll recall that identifying the root cause is a key strength of Unit Testing Which is my clumsy way of trailing the next episode, where I'll be comparing and contrasting Unit Testing and Behavioural Testing And, of course, Test Driven Development (TDD) and Behaviour Driven Development (BDD) I hope you'll join me. https://www.youtube.com/watch?v=VS6EEUVZGLE https://www.youtube.com/watch?v=mT8QDNNhExg
Views: 39240 Development That Pays
Daily Stand-up: You're Doing It Wrong!
 
03:52
I’m a big fan of the Daily Stand-up. But I’m not such a fan of the way that most Stand-ups are run. There is a better way. Grab your FREE copy of "Daily Stand-up Words of Wisdom": https://www.developmentthatpays.com/cheatsheets/daily-standup-wisdom I’m a big fan of daily stand-ups. But I’m NOT a fan of the way that most stand-ups are run. There is a better way. Key take-aways: - The most common model for the Daily Standup is the “Yesterday, Today, Blockers” model: - "What I did yesterday" - "What I plan to do today" - "What (if anything) is blocking me" - The “Yesterday, Today, Blockers” model tends to make team members focus on themselves - and on making a good impression. - An altenative model is to "Walk the Board" (aka "Walk the Wall" aka "Talk to the Work") - The "Walk the Board" model puts the focus on the work. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 9. Daily Stand-up: You're Doing It Wrong! I’m a big fan of the daily stand-up. Even when they don’t work well, they work better than no stand-up at all. Having said that, the most common model for stand-up is, in my opinion, sub-optimal. There is a better way. Hi this is Gary, Welcome to Development that Pays. If your dev team does a daily stand-up, the chances are that it uses the “Yesterday, Today, Blockers” model: with each person taking their turn to talk about: What they worked on yesterday What they’re woking on today What - if anything - is impeding their progress - otherwise known as blockers It all seems very reasonable. And on the level of the individual, it is. But a stand-up is not an individual event. It’s a team event. Let’s run a quick stand-up using the yesterday-today-blockers model. The team gets up and forms a circle. Kevin starts He runs through what he did yesterday, what he plans to do today… and whether or not he has any blockers Fiona is next. She talks about what she did Yesterday, what she planing to do today Let’s freeze it right there. Question: Who’s talking Well, obviously it’s Fiona Who’s listening Well, everyone else If only! Let’s give Dave, the Lead Developer, the benefit of the doubt and say that he’s giving Fiona his full attention. Kevin has had his turn, to he might be listening. What about John Well, he’s HIGHLY unlikely to be listening. He’s up next. Most of his attention is on working out what he’d going to say. The same - perhaps to a slightly lesser extent - for Tim. You don’t need to have been in a stand-up to know that this is truth of this Ever been at a business event where people are invited to introduce themselves themselves around the table Before it was your turn, were you paying attention or were your creating your story in your head And did you breathe a sigh of relief after your’d taken your turn. And then - and only then - pay attention to what other people were saying Come on, admit it. I won’t tell. Believe me, the same thing happens in Stand-ups. For exactly this same reasons: We want to make a good impression. We want to tell a good story. We do NOT want to embarrass ourselves. And all this without notes. This is not easy. It takes concentration. It takes your full attention. Let’s look at a different way of running stand-up. The team gets up and they start… not with Kevin… nor with any member of the team. No, the starting point is this ticket. Tim knows about it. He reports that testing is nearly complete. On to the next ticket, which is marked as blocked. Is it still blocked Fiona reports that it is. On to this next ticket. Kevin knows about this one. He reports that he’d made some progress… and needs some help with one aspect of it. Dave offers to take a look immediately after stand-up. And so it goes on. This is called Walking the Board or Walking the wall. it takes the focus away from the individual and puts it where it should be: on the work. There’s no longer a need for anyone to use valuable brainpower to “come up with a good story”. The cards, in effect, provide the “agenda items" for the stand-up. And commenting on an agenda item is easy. This is just one advantage of the Walking the Board model. We’ll take deeper dive into some of the other advantages in the next episode Talk to you then. https://www.youtube.com/watch?v=H02BlTXpcto https://www.youtube.com/watch?v=_3VIC8u1UV8
Views: 35440 Development That Pays
3 Awesome Minimum Viable Products (MVPs)
 
04:54
What are the best MPVs of all time? I've absolutely no idea... but Buffer, Dropbox and Zappos are three of my favourites. Grab your FREE Lean Startup Cheat Sheet: http://www.developmentthatpays.com/cheatsheets/the-lean-startup 0:15 - Ground rules for a perfect MVP 1:00 - Buffer's MVP 1:58 - Dropbox's MVP 3:23 - Zappos' MVP LINKS - Steven Cohn: https://www.linkedin.com/pulse/death-minimum-viable-product-steven-cohn - Buffer: https://blog.bufferapp.com/idea-to-paying-customers-in-7-weeks-how-we-did-it - Dropbox: http://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/ - Zappos: http://www.bullethq.com/blog/lean-startup-zappos-how-zappos-validated-their-business-model-with-lean/ → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 35. 3 Awesome Minimum Viable Products (MVPs) Today, we're going to take a look at three of my favourite examples of Minimum Viable Products (MVPs). Before diving in. let's establish some ground rules for a "proper" MVP It's got to be Minimal It's got to be Viable And it's got to be a Prod... Actually No, it does not need to be a Product. (I'll be showing you a great example of a "non-product" in a minute or two.) Some have argued that the word "Product" in MVP is unhelpful. Steven Cohn has made a strong case for the word "Experiment". I agree. But for now let's stick with the "P" and temporarily re-define it to.... Pre-meditated. Meaning that the MVP must be a deliberate attempt to learn about the market. This rules out cases that look like MVPs in retrospect, but were really full products that - to everyone's surprise - developed into something big. Let's get going. No. 3 - Buffer ------ Buffer is a application that makes it easy to share content on social media. Here's what they put on the their site. A test, certainly. But it falls short of an MVP in my opinion. Their next test was better. They slotted this page in-between the other two pages. Now visitors to the website are not just saying "This is interesting" They're saying "I want to BUY this". Okay, there's nowhere to input your credit card details. But anyone who got this far was at least prepared to think about parting with their money. As co-founder Joel Gascoigne said: "After this result, I didn’t hesitate to start building the first minimal version of the real, functioning product." Minimal - certainly Viable - yes Pre-mediated - check Buffer's current valuation is something close to $400 million No. 2 - Dropbox ---- Dropbox, as I'm sure you know, is a file synchronisation service. Edit a file on your desktop... ... and seconds later its updated on all of your other devices. Rewind to the early days. The team - entirely composed of techies - had the basic synchronisation working. That was the easy bit. The hard bit was going to be to achieve the same trick on pretty well every platform: Mac, Windows, iPhone, etc. Given that the team was all techies, you'd have put money on them diving straight in. But CEO Drew Houston did something surprising. He made a video. The video - just three minutes long - demonstrated the synch process end to end. But it was more than just a demo: it was full of techie in-jokes... designed to appeal to early adopters. It worked like a charm In Drew's words: “It drove hundreds of thousands of people to the website. Our beta waiting list went from 5,000 people to 75,000 people literally overnight. It totally blew us away.” Minimal - Yes Viable - Not a product that could be used, but a product that could be demonstrated. Pre-Meditated - Yes Dropbox went on to do quite well. It's current value stands between $5 and $10 BILLION. No. 1 - Zappos ---- It's 1999. Co-founder Nick Swinmurn wanted to build an online store for shoes. But would people use it Here's how he went about finding out. He popped down to lis local shoe shops he went into the shops and... ... I sh!t you not... he PHOTOGRAPHED PAIRS OF SHOES! The photos were uploaded to a super-simple website. If someone clicked on the button to buy a pair Nick would pop down to the store and... BUY THE SHOES! Zero infrastructure. Zero inventory. Minimal - definitely Viable - This time it's not even up for discussion. Most definitely: real customers; real money changing hands; real shoes! Pre-meditated Check. Zappos went on to do quite well: it was acquired by Amazon in 2009 for a cool $1.2 billion. Your thoughts, please! ---- Buffer, Dropbox and Zappos. Three of my favourite MVPs. What do you think of my choices Any you disagree with Let me know in the comments. And I'd also like to he https://www.youtube.com/watch?v=xPJoq_QVsY4 https://www.youtube.com/watch?v=cjCCS3DxZRo
Views: 56824 Development That Pays
Scrum vs. Kanban - "You Talk. We Work."
 
05:11
Follow the fortunes of an Agile Team that splits in two: one side stuck with Scrum; the other side switched to Kanban. Will it all end in tears? Download your FREE CHEAT SHEET: http://bit.ly/scrum-vs-kanban-cheatsheet The first Agile team I joined was a Scrum Team. When the team split into two, I was surprised to see that my ex-team mates were doing things differently. I didn't know there was another way to "do Agile". This is a story of Two Agile Teams. More correctly, it’s the tale of one Agile Team that split into two Agile Teams. What makes the story interesting is that it was more than just an organisational separation. It was an Agile separation: - One team continued as before - with SCRUM - The other team dropped Scrum in favour of KANBAN → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 14. Scrum vs. Kanban - "You Talk. We Work." This is a story of Two Agile Teams. More correctly, it’s the tale of one Agile Team that split into two Agile Teams. What makes the story interesting is that it was more than just an organisational separation. It was an Agile separation. A New Team --------- I joined a team in 2012 It was, I was told, a team that 'did Agile'. At the time, I knew very little about 'Agile'. But I could see from the get go that they weren’t doing it by halves. There’d clearly been lots of training. They had all kinds of tools. They were doing all kinds of 'rituals'. We’ll get into the specifics of how the team worked in a minute. The Split ----- Fast forward a year and the company went through a fairly major reorganisation. My team was split in two. Although reporting lines changed, the seating plan didn’t. There was one outward indication of change: where there had been one agile board, there was now two. Oh, and we did two stand-ups every day , ours at 10:00am, theirs at 10:15. A New Flavour ----- Ever-observant, it took me a couple of weeks to notice that the other team was doing a different 'flavour' of Agile. I hadn’t realised that there was more than one flavour of Agile. What my team was doing was, called Scrum. The other team was doing something called Kanban. “Kanban”. Really This was a word I knew from way back. But I knew it in the context of manufacturing. I couldn’t immediately see how it applied to the process used by my (former) teammates. So I asked the Lead Developer of 'Team Kanban': 'What the difference between Scrum and Kanban ' He was ready with an immediate answer: 'You Guys Talk About Work. We Do Work.' Ouch! in that moment, I learned an important lesson about Agile: It can be an emotive issue. Beliefs can be deep-seated. the Team Kanban Lead Dev clearly thought that Kanban was better than Scrum. I held… the opposite view. My view was both strongly held… and completely without evidential foundation. I’m a little older now. And, I hope, a little wiser. Natural Experiment ---- I can now see that the team split was a perfect natural experiment, along the lines of: “Take two identical twins. Separate them at birth. Feed one Scrum. Feed the other Kanban. Observe the result.” So I hope you’ll join me on a little forensic investigation It’s going to take more than one episode to do it. But in this episode, we have juat enough tom to take a 20,000 feet view of the two teams and their processes. Team Scrum ----- Team Scrum worked on two week Sprints. On the Monday, we’d take ourselves off to a quiet part of the building for a Sprint Planning session. The Product Owner would select items from the backlog, we’d play “Planning Poker” to estimate the size each item. And we’d continue until we had roughly one “sprint’s worth” of cards. Sprint planning over, each developer would pick up a card and set to work Every morning there’d be a stand-up - 10 am on the dot. And so it would go on day after day, with the cards gradually making their way across the board. By the about the Tuesday of the second week, we’d expect all of the cards have moved at least one step. It’s then a race - a sprint - to get everything tested and ready for release by Friday. We didn’t always succeed in getting everything across the board. Any item that failed to make it would be “recycled” into the next Sprint. On the Friday morning, everything in the release column would be packaged and made ready for release. One last thing to round out the Sprint: a Retrospective. A chance for the team to get together… to reflect on what well, to discuss what could be improved… and to commit to one or two action items for the following sprint. Team Scrum - Evidence ---- https://www.youtube.com/watch?v=9Jgu1BlTlSc&list=PLngnoZX8cAn9xNunWcv7ujoD7o0AytVlT
Views: 152102 Development That Pays
Agile Scrum in Two Minutes + FREE CHEAT SHEET
 
02:33
Scrum is the best known of the Agile software development frameworks. Here's what you need to know. Grab your FREE Scrum vs Kanban Cheat Sheet: http://bit.ly/scrum-vs-kanban-cheatsheet Scrum is perhaps the best-known of the various Agile software development methodologies. In very broad terms, software development is a process where: the Product Owner decides what to build; the Development Team build it; customers use it, experience it, benefit from it in some way. What makes software development AGILE is that value is delivered to customers in small increments, and feedback from the customer is "fed back" into the process. The Product Owner takes input from various sources to create a prioritised a list of Features and User Stories: the Product Backlog. What make Scrum "Scrum" is how things happen between Product Backlog and the Customer: - Scrum teams work in a series of SPRINTS, most commonly two weeks in length. - Each Sprint it proceeded by a Sprint Planning Meeting, the outcome of which is a SPRINT BACKLOG. - Each day during the Sprint there is a Daily Scrum Meeting, - At the end of the Sprint, the work completed during the Sprint is packaged for release. - The Sprint ends with two rituals: the SPRINT REVIEW and the SPRINT RETROSPECTIVE. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 49. Agile Scrum in Two Minutes + FREE CHEAT SHEET Scrum is one of many Agile software development methodologies In very broad terms... The Product Owner decides what to build The Development Team build it Customers use it, experience it, benefit from it in some way That's software development. What makes it AGILE is that value is delivered to customers in small, regular increments and any feedback from the customer is "fed back" into the process. It's the Product Owner's job to take input from customers - and from a range of other sources and use it to create a prioritised a list of features and user stories. The list is known as the Product Backlog As it stands, this picture could apply to a range of different Agile methodologies. What make Scrum "Scrum" is how things work in here. As we'll see, there are a number of routines and rituals that go along with Scrum, and it's the job of the SCRUM MASTER to help the Product Owner and Development Team to develop and maintain good habits. Scrum teams work in a series of SPRINTS, most commonly two weeks in length. Each Sprint it proceeded by a "Sprint Planning Meeting." - attended by the the Development Team meets and Product Owner Together they select HIGH PRIORITY items from the product backlog that the Development Team believe it can commit to delivering in a SINGLE Sprint. The selected items are known as the SPRINT BACKLOG. For the next two weeks, the Development Team focus on working through the items in the Sprint Backlog. Each day during the Sprint there is a Daily Scrum Meeting, where the attendees take turns to say what they did yesterday what they plan to do today and whether they have any blockers At the end of the Sprint, the work completed during the Sprint is packaged for release. The Sprint ends with two rituals: The Sprint Review, which is a demonstration of new functionality to Stakeholders. and the Sprint Retrospective, which is an examination of what went well, what went badly and what could be improved. The aim of the Retrospective is to ensure that the next Sprint is more efficient and effective than the last. And that's Scrum on two minutes. https://www.youtube.com/watch?v=1PBln3dyaPs https://www.youtube.com/watch?v=XU0llRltyFM
Views: 40384 Development That Pays
Kanban: Toyota to Software Development in 2 Minutes
 
02:31
48. Kanban: Toyota to Software Development in 2 Minutes // Kanban - an Agile Software Development Methodology - can trace its roots to the factories of Toyota. It's now found favour in Agile software development. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Key take-aways: - In a perfect factory everything runs like clockwork - In a real factory, the Work in Progress (WIP) builds up - Work in Progress can hide a multitude of sins. These are issues that must be addressed if WIP is to be reduced - We need a mechanism for one machine to tell the PREVIOUS machine that it's ready to receive more widgets. - The Kanban Card is the SIGNAL sent from one process to another to request more "widgets". - The Kanban Card turns a PUSH system into a PULL system. - Although Kanban was born in the factories of Toyota, it has found favour in the world of Software Development. - In Software Development, We don't have machines, but we do have processes. We don't process widgets, but we do process tasks (stories) - With low Work in Progress (WIP) come the advantages of shorter cycle times, faster throughout, and less wasted time Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Today, I'm going to attempt to "do" Kanban in 2 minutes or less. Back to the factory floor ----- Here's a super simple factory: just two machines. In ideal world, the machines operate at the same pace, and work flows smoothly from "To do" to "Done". But what if Machine 1 is faster A pile of widgets builds up in front of Machine 2. This "Work in Progress" pile is a problem. There are obvious costs: there's money tied up in each of these items. and the physical space that this "queue" takes up also has to be paid for. And there are less obvious costs. Like a high tide over a rocky shore, a generous helping of work in progress can hide a multitude of sins, including: machine downtime set-up time and quality issues Reduce the Work in Progress, and these hidden issues become issues that can be - need to be - addressed. Kanban Card ------- But how By having Machine 1 process items ONLY when Machine 2 is ready to receive it. Machine 2 needs to signal to Machine 1 that it's ready; the signal is in the form of the now-famous "Kanban card". No longer are widgets PUSHED through the factory. The are now PULLED. The Kanban system was born in the factories of Toyota but has found favour in software development: We don't have machines, but we do have processes. We don't process widgets, but we do process tasks. And we can represent the processes and tasks on a board. In this case, the PULL system is implemented without the need for a Kanban Card: an empty (or nearly empty) column is the SIGNAL to the previous column to "send more tasks". With low Work in Progress come the advantages of: Shorter cycle times Faster throughout And less wasted time https://www.youtube.com/watch?v=5izyN66PTxs https://www.youtube.com/watch?v=R8dYLbJiTUE
Views: 86829 Development That Pays
Agile vs Waterfall: Waterfall Wins! + FREE CHEAT SHEET
 
04:19
It's easy to fall into the trap of thinking that Agile is better that Waterfall. What needs to be be true for Waterfall to win over Agile? Grab your FREE Cheat Sheet: http://bit.ly/waterfall-vs-agile In the previous episode - https://www.youtube.com/watch?v=tCbeLauIKew - my 19 year old self took on my dad in the classic DIY challenge of hanging a shelf. - My process was Waterfall - My dad's process was Agile My dad's Agile process won by a landslide. But why did it win? And are there cases where Waterfall would be victorious? → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 40. Agile vs Waterfall: Waterfall Wins! + FREE CHEAT SHEET Previously... My 19 year old self took on my dad at the classic DIY challenge of hanging a shelf. To no one's surprise, my dad won. It was not just a victory of experience over enthusiasm. It was also a victory of Agile over Waterfall. Was Waterfall destined to lose Or could it have claimed victory What has to be true for Waterfall to win Shelving ----- If you missed the last episode... ... you may decide that you were glad that you missed it. Because we spent the entire time attaching this shelf... ... to this wall. Not once... but twice. My method of hanging the shelf - very much a Waterfall approach - scored high on efficiency: I measured everything marked everything drilled everything screwed in all the screws But it scored badly in effectiveness: the result was a wonky shelf. My dad's process was was much more iterative - much more Agile. He marked one hole He drilled ONE hole He fitted one plug He fitted one screw [And so on...] He checked for level multiple times, so it came as no surprise that the end result was also level. It was a fair fight: my dad's method won fair and square. But it did make wonder: why did it win And could there be situations where a Waterfall approach would be victorious Let's change the parameters a bit: instead of the challenge being to hang a shelf, the challenge now is to hang 20 identical shelves. My dad's process is awesome for a single shelf, but for 20 shelves it's far too much work. His process is bespoke. I need something more "cookie cutter". I've come up with this jig; I think it's going too make all the difference. Match this mark to the centre mark on the wall Adjust for level... using the built in spirit level. Press it firmly against the wall: the rubber backing keeps it in place. The drill guides ensure that the holes are in exactly the right location. It also ensures that the hole is drilled at right angles to the wall. Drill all 4 holes. Remove the jig 4 plugs in Offer up the shelf In go the screws - but not too tight. Final check for level. Tighten the screws all the way. Not just a job done well. But a job done quickly. Waterfall just beat Agile. Why did Waterfall win Clearly, the jig was the enabler here. But in order for the jig to work as expected, at least two things must be true: All of the walls must be reasonably flat if they're not, then the jig won't "stick" to the wall. All of the shelves are identical if they're not, the holes drilled in the wall won't line up with the holes on the shelf. Notice that neither of these conditions is necessary for my dad's process to work: his process will always work: on flat walls; on bumpy walls; with shelves of all shapes and sizes. So it would appear that it's all about predictability. If the steps can be predicted with a high level of confidence for example, if it's an activity that we've completed many times before - then a Waterfall process is likely to be the best choice. Conversely, if the level of confidence is low for example, if we're attempting something for the first time - then an Agile process is going to pay dividends. Agile and Waterfall. Horses for courses. Many thanks for watching. Talk to you next time. https://www.youtube.com/watch?v=8Nrw8pho6cY https://www.youtube.com/watch?v=_U7Py7W-Qng
Views: 52083 Development That Pays
Minimum Viable Product: You're Doing It Wrong!
 
02:01
34. Minimum Viable Product: You're Doing It Wrong! // The concept of Minimum Viable Product (MVP) is not new, but it didn't 'click' for me until I saw one perfect image. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Henrik Kniberg's beautiful sketch powerfully illustrates where we've been going wrong: creating products that are MINIMAL, but not VIABLE. LINKS -- Frank Robinson: http://www.syncdev.com/minimum-viable-product/ -- Henrik Kniberg: http://blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 The best definition I've seen for "Minimum Viable Product" is not a set of words. It's a sketch. A sketch that encapsulates the concept so perfectly... ... that it went viral. Frank Robinson -------- Frank Robinson coined the term "Minimum Viable Product" in 2001. The idea - at least at a superficial level - is simplicity itself: Get a version of the product in front of a customer early as possible. Not with the aim of generating early income - though that is no bad thing - but with the aim of LEARNING. The chances are that you've heard of Minimum Viable Product before today.. ... and that when you heard it, you immediate "got it". As Frank himself said: “When I first said ‘minimum viable product’ I never had to repeat myself. The words went viral right before my eyes.” BUT... Is it Viable ------- Just because something is easy to grasp, doesn't mean it's easy to do. It's not easy. Far from it. Here's the problem: We - development teams, lead developers, product owners... even business owners - usually have an idea of what the "ultimate" product might look like. Ask us to come up with a minimum version and we'll hack off a feature here and a feature there. What we end up with will certainly be MINIMAL: that's the easy part. But will it be VIABLE That's the tricky part. Enter Henrick Kniberg ----- A gentleman by the name of Henrick Kniberg captured the difference between the two perfectly in his (now viral) image: In the top line, we have minimal, but not viable (until we get the final step). In the bottom line, we have minimal AND viable every step of the way. In a recent blog post, Henrik said that he was surprised that his image went viral. I'm not surprised at all. I think it's genius. Next time. ------- Next time we'll take a look at some "real world" Minimium Viable Products. https://www.youtube.com/watch?v=rmGOBzpn_98 https://www.youtube.com/watch?v=xxjbxk8dUqI
Views: 8165 Development That Pays
Scrum vs. Kanban - "Kanban Chaos"
 
05:19
Team Kanban seemed to be working EFFICIENTLY. But are they working EFFECTIVELY? (Spoiler: No.) Grab your FREE CHEAT SHEET: http://bit.ly/scrum-vs-kanban-cheatsheet Out of Team Scrum came Team Kanban. Did my ex-team mates go on to great things? Or have they thrown the Agile baby out with the bathwater? Team Kanban has bought itself some time by dropping a couple of Agile rituals. But it's also dropped... Kanban! Key take-aways: - Team Scrum worked in two week Sprints - Team Kanban worked in a continuous fashion LINKS -- Part I: https://youtu.be/9Jgu1BlTlSc → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 15. Scrum vs. Kanban - "Kanban Chaos" Last time, I told the tale of an Scrum team that split into two. One team continued with the Scrum. The other team abandoned Scrum in favour of Kanban. (If you missed the last episode, I'd encourage you to check it out. There should be a link somewhere around this video.) Did Team Kanban set the world on fire. Or did it crash and burn Taking notes --------- We learned a few interesting from our 20,000 foot view of the two teams. As good forensic investigators, we should take a few of notes: We know that Team Scrum works in two week sprints. Team Kanban works in a continuous fashion. Team Scrum has a formal Sprint Planning session. Team Kanban must have some process to choose items from the backlog... but we don't have any details. Team Scrum does Retrospectives. We're not sure if Team Kanban has anything similar. Between Sprint Planning and the Retrospective, team scrum loses around half a day of development time a fortnight. The two week period doesn't mean anything to Team Kanban, so let's convert the number of days into percentages. One last piece of data to record: Team Scrum releases once every two weeks; Team Kanban releases 2 to 3 times in the same period. Q&A -- I had a couple of great questions come in after the last video - both of them relating to Team Scrum. "Why is your Scrum Sprint length 2 weeks " (The sense of the question being why was the sprint length as long 2 weeks.) I can tell you that from the team felt they were "cutting edge" for having a Sprint of just two weeks. At the time, sprits of 3 or 4 weeks were not uncommon. Any suggestion of moving to a one week sprint would have been strenuously resisted, because it would have meant doubling the frequency of the the two things we hated most: sprint planning, and packaging for release Which leads on nicely to the second question... "Why does your Scrum Team wait for 2 weeks before releasing software " This is such a great question. I say that, because it's a question that would have never occurred to Team Scrum. For us, a Sprint was something that started with Sprint Planning and ended with a Release. The Release was part of the very definition of Scrum! How's that for a limiting belief! Is Team Kanban Effective ---- Looking at the two lists, it's clear that Team Kanban is doing more work. It's also releasing more often. But is it performing are well as the evidence suggests No photographs from the time have survived, but we have been able to piece together a couple of images from eye witness accounts. Exhibit 1 is Team Scrum's board. Nothing out of the ordinary here. Given the position of the cards, I'd guess we're looking at the state of the board from somewhere close to the end of a sprint. Exhibit 2 is Team Kanban's board. Blimey. A bit crowded, it's it And if I zoom out a little bit... there. Have you ever seen anything like it Your eyes don't deceive you: the column of cards goes all the way to the floor. (And it's not that we've caught it on a bad day. the board looked like this for at least a year.) If I tell you that Team Kanban had four developers, you'll start to get an idea of the scale of the problem. There must be 20 cards in this column. Even if we assume that half of them are blocked, it still means that each developer is working on multiple tickets at the same time - never a good thing. Kanban Fail ---- What's gone wrong here Team Kanban are missing two things that are essential to the success of an Agile team: An effective transition from Backlog to Development A hard limit on Work in Progress.- the number of items bing worked on at any one time With so many blocked cards on the board, it's clear that they are not doing a good job of transitioning from backlog to development. And it looks like they're on a quest to maximise their Work In Progress! Natural Consequence ---- Team Scrum, on the other hand, are doing a good job in both areas. N https://www.youtube.com/watch?v=n2ZrUQNwrUk&list=PLngnoZX8cAn9xNunWcv7ujoD7o0AytVlT
Views: 68524 Development That Pays
What is TDD? What is Test Driven Development? + FREE CHEAT SHEET
 
04:48
60. What is TDD? What is Test Driven Development? + FREE CHEAT SHEET // Grab your FREE Cheat Sheet: http://bit.ly/tdd-vs-bdd-cheatsheet Welcome to a stricty non-technical introduction to Test Driven Development - aka TDD. We'll be digging into Unit Tests, test isolation and the myserious world of mocking. Key take-aways on Unit Tests: - Writing Unit Tests for existing code can be difficult... or impossible - A Unit Test is a test of a component in isolation - In order to test is isolation, any external dependencies must be "mocked" - An example of something that is frequently "mocked" is a database connection - Units Tests tend to be very fast to run. Key take-aways on Test Driven Development: - It's an iterative process: write a small test... write just enough code to get the test to pass. Rinse and repeat. - The tests and the code that the tests "cover" are born and grow together. They are intertwined. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 What is Test Driven Development Aka TDD I'm glad you asked! Unit Tests... can be hard ---------- First things first. If we're going to talk about Test Driven Development, we first need to talk about the particular type of test that underlies TDD: Unit Tests. I first came across Unit Testing in about 2008. By that point, I'd been developing full time for a few years. I thought I had it down. But I found writing unit tests to be hard. Damn hard. 10x harder than writing code. Depressing. I eventually discovered that it wasn't my fault. Much of the stuff that I thought was impossible to test .... ... really WAS impossible to test. It wasn't me after all! Why were the tests impossible to write I was trying - and failing - to write a test for something that... ... wasn't like a spark plug. Test Isolation ------ Remember in the last episode we talked about testing the gap of the spark plug That's a perfect example of a Unit Test. Another perfect example would be a test of its resistance. With the right equipment, we could even perform a unit test to confirm that it sparks. All of these tests are possible because there's something special about a spark plug It's... TESTABLE! By design, it can be removed from the engine. It's one of the few things in the world that has a (more or less) standardised tool for removing it. My guess is that spark plugs weren't designed specifically to be testable. I think it's probably the case that spark plugs were designed to be replaceable and test-ability came as a very useful side effect. It's been my experience that things rarely evolve naturally to be replaceable/testable. They are replaceable/testable by design. Or not at all. Nowhere is this more true than with software. I can say with a high level of confidence, that if your codebase does not have unit tests, then your codebase consists largely of UNTESTABLE code. Test Driven Development ----------- Which brings us nicely on to Test Driven Development. Test Driven Development, as the name suggests, is a process by which the tests are written BEFORE the code. This doesn't mean writing all of the tests and then writing all of the code. it's more subtle than that. You start by writing just one test. A very small test. Then you write some code. Just enough code to get the test to pass. Then you write another small test. Rinse and repeat. The code and the tests are born and grow together. The test-ability of the code is "built in". Mocking -------- Writing Unit Tests is easier for new code than for existing code. But that's not to say that it's trivial. There is a complication. The key to a unit test is to test the "unit" in isolation. If you saw the previous episode, I performed the following test: I removed the plug cap, unscrewed the spark plug, plugged it back into the plug cap and operated the kick starter. This was a test for spark, but it was NOT a Unit Test. Because it's not a test of the spark plug in isolation. (It's actually a test of a whole host of components working together.) A Unit Test is possible. It just needs some additional equipment. This device takes the place of the battery and a whole array of electrical equipment. The device is assumed to be working, so if there's no spark, we know that it's the spark plug that's at fault. The software equivalent of providing this "additional equipment" is called "faking" or "mocking". Mock example ------- To give you a quick example: if I write a function to determine if the current year is a leap year, I'm going to want to mock the date. That way I can feed in a whole series of dates And check/test that I get the right result. Alas, mocking isn't always so easy. There are many real world https://www.youtube.com/watch?v=H4Hf3pji7Fw https://www.youtube.com/watch?v=QCif_-r8eK4
Views: 14261 Development That Pays
Scrum: Everything Wrong With The Scrum vs Kanban Cheat Sheet
 
05:14
Scrum pointed out SIX issues with the Scrum vs Kanban Cheat Sheet. Five of them are excellent. One of them... Grab your FREE Scrum vs Kanban Cheat Sheet: http://bit.ly/scrum-vs-kanban-cheatsheet Scrum got in touch. He had a few things to say about the “Scrum vs Kanban Cheat Sheet”. Scrum suggested six changes: five... I implemented immediately; one… I have a problem with. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 96. Scrum: Everything Wrong With The Scrum vs Kanban Cheat Sheet This is the “Scrum vs Kanban Cheat Sheet” Issue 1.5 of the “Scrum vs Kanban Cheat Sheet” to be precise. It’s been downloaded 3,085 times. And it's been through a bunch of iterations. I thought I'd got most of the kinks out it. Then, three days ago, I received a message. A message containing a whole list of corrections. When I saw who it came from, I sat up and took notice. It came... from Scrum! The message contained six points in all. Shall we take a look One - Sprint Planning --- ‘Sprint Planning is part of each Sprint: "A new Sprint starts immediately after the conclusion of the previous Sprint."’* I confess I was never clear on this; I’d assumed that the Sprint started after Sprint Planning. On this one, I stand corrected. Two - Lead Developer ----- ‘There is no Lead Developer role or title in the Scrum framework.’ True. (Although, there’s no Lead Developer role - or any role at all - in Kanban.) But I do take the point. The “Lead Developer” role appears on the Cheat Sheet in a few places. In most - if not all - cases, swapping “Lead Developer” for “Development Team” would make more sense. Three - "Facilitate", not "run" ----- ‘Neither it nor any other event is "run by the Scrum Master" as he is not a manager/boss though he may facilitate the event.’ Scrum’s right: there’s a world of difference between “is run by” and “may be facilitated by”. Four - Continuous Delivery -------- ‘Continuous delivery is permitted and often encouraged.’ This is a good catch. My first Scrum team wouldn’t have dreamed of releasing more than once a week - such was the pain of releasing at this "major broadcaster". But in more recent times, I’ve been in Scrum teams that were comfortable with multiple releases per sprint. And even with continuous delivery. Five - More than a Demo ------ ‘There is a Sprint Review which is much more than a Demo.’ I went straight to The Scrum Guide to check it out. Turns out, the term “Sprint Demo” isn’t in the Scrum Guide. Never was. And what appears under “Sprint Review” is more that a demo. Much more. Far more! And finally ---- Five down. One to go: ‘WIP limits do not "ensure that items move across the board in the shortest possible time." It can affect cycle time due to increased focus and decreased context switching.’ Ah. Now. Here’s where I have to disagree with Scrum. Focus and context switching are certainly factors. (We’ve gone into detail about context switching before here on Development That Pays.) But they’re second order factors. Let me see if I can show you. Three cups. WIP limit of three. Move each in turn. After three moves, all three have moved... a little. Let’s run that again, this time with a WIP limit of one. This time, one cup moves a long way - all the way across the board. Ready for release. We have a winner. Context Switching was not a major factor. Bottlenecks ---- I should mention that Scrum went on to say this about WIP limits: ‘One of the biggest benefits is identifying bottlenecks in the pipeline’ And on that point, Scrum and I are in complete agreement. New Improved Scrum vs Kanban Cheat Sheet ----- My thanks to Scrum for making this episode possible, and for helping me to improve the “Scrum vs Kanban Cheat Sheet” If you’re yet to grab your copy, what are you waiting for ! It’s better than ever! https://www.youtube.com/watch?v=MuCIUxP_Upo
Views: 14948 Development That Pays
Agile is... Never Having To Commit To a Deadline?!?
 
05:17
7. Agile is... Never Having To Commit To a Deadline?!? // The world of business is full of deadlines. But deadlines and Agile don't seem to mix. Picture the scene: → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe - 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 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. Overall we have an s-curve We’ve ended up with two very different value curves. But can we reconcile them Can we present a picture that Mr Business and Mr Agile can live with Let’s superimpose the lines. Clearly this is bad news: the launch is happening way to early What https://www.youtube.com/watch?v=MeYrV_Xm2rI https://www.youtube.com/watch?v=jaqiXSp-D8E
Views: 6064 Development That Pays
Agile Estimating & Planning [2018] Fibonacci Series = Accurate Estimates?
 
05:36
Does the use of the Fibonacci Series - in Agile Estimating and Planning - lead to more ACCURATE estimates? Download your FREE CHEAT SHEET: https://www.developmentthatpays.com/cheatsheets/agile-estimating The Fibonacci Series is in common use in the Agile world. In this video, we'll look at how it helps with RELATIVE estimates... ... and we'll try to answer the question: "Does the use of the Fibonacci Series lead to more ACCURATE estimates?" → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 123. Agile Estimating & Planning [2018] Fibonacci Series = Accurate Estimates? Estimating is hard ----- If you've been following along with this series on agile estimating you'll have got the message by now that estimating is hard. But some estimates are much easier then others. We've talked previously about estimates of absolute size versus estimates of relative size. "How heavy is this " is a hard question. "Which of these is heavier " is an easy question. Why is it an easy question Well, it's because there's a large difference you assume in the weight of these two. When I say difference is that the absolute difference or the relative difference Which of these two coins is heavier Which of these two bridges is heavier I hope that answers the question. It's not the absolute difference that's important, it's the relative difference. The Fibonacci Series ----- Hold on a second. Wasn't this supposed to be an episode on the Fibonacci Series I think it's time we rolled it in. Actually, let's build it from scratch. The first two numbers are zero and one. To get the third we add the first two together: Zero plus one is one. We carry on adding pairs of numbers: 1 + 1 = 2 1 + 2 = 3 2 + 3 = 5 and so on: 8 13 24 34 55 89 It's in the spaces ---- What's interesting in this series is the gaps between the numbers. Not the absolute gaps: the relative gaps. 0, 1 - The relative gap between these two is, oh, that's infinite. Yeah. That ones a little bit large. Let's move on. 1, 1 - the relative gap is zero 1, 2 - The relative gap between these two is 100%. Okay. 2, 3 - 50%. 3,5 - 66.6666667% 5, 13 61 and a bit percent. 13, 21 almost 62%. 21, 34 - 61.8%. 34, 55 -61.8% After some craziness at the beginning of the series the relative gap between he member of the series settles down to around 61 and a bit percent. Let me see if I can demonstrate that to you a little more visually. Here are the first few. Zero, one, one, two, three, five, ah, yeah now we're up to space. I'm going to zoom out around about 60%. There's the eight. Zoom out another 60% there's the 13. Zoom out again, 21. Zoom out once more, 34. Zoom out again, 55. Zoom out one last time, 89. I hope you can see that although the bars are getting skinnier as we zoom further and further out the relative size between this one and this one stays pretty well constant. Fibonacci for estimating ----- The reason that this scale works so well for estimating is that it encourages us to stay in the realm of easy estimates. It encourages us to stay with relative estimates. To say in slightly different terms if we are estimating two things and their sizes, their relative sizes are not sufficiently different then we consider that they both have the same size, which brings us right back to the question that we started with today. "Does the Fibonacci Series lead to more accurate estimates " I think the answer has to be no. If anything what it does is protect us from attempting to make accurate estimates. It keeps us in a realm of making rough or broad estimates. https://www.youtube.com/watch?v=iZYSapFCg4A&list=PLngnoZX8cAn-9tWYxyQQPGoHW7DETBCjK
Views: 3529 Development That Pays
The Lean Startup - 5 Keys to a Successful Minimum Viable Product Launch
 
05:20
A month ago I launched a new product - a new Minimum Viable Product. I learned a lot: here are the 5 things you need to know. Grab your FREE Cheat Sheet: http://bit.ly/lean-startup-cheatsheet In today's video, five keys to a successful Minimum Viable Product Launch: - 1. Launch before _____ _____ - 2. There are more ______ _____ than you think - 3. Launch to a _______ _______ - 4. Be ready to make _______ ______ - 5. Remember that it’s an ________ → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 108. The Lean Startup - 5 Keys to a Successful Minimum Viable Product Launch So you’re planning to launch a product A Minimum Viable Product Excellent. A New Course ------- Just over a month ago, our adventure into Lean - that’s “Lean” as in “The Lean Startup” - reached an interesting stage. I launched a product. A Minimum Viable Product. The “Course of Some Kind” crystalised into “Scrum vs Kanban - the Mini-course”. Here are FIVE things that I learned along the way: 1: Launch before you’re ready ----- Are you the kind of person that hears "Done Is Better Than Perfect" or “Shipping beats perfection” and thinks: “Really Are you sure ” If so, you’re in good company. “Hello. My name is Gary. I’m perfectionist.” October was hell for me. My task was take existing material and to repurpose it into a mini-course. That doesn’t sound like a recipe for torment. But the more I worked on the course, the less I liked it. I wanted to rip it up and start again. If this sounds like you, then take a note from Reid Hoffman, founder of LinkedIn "If You're Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late" So pick and date. And launch. Before you’re ready. Bonus Tip: Set things up so that the date can’t be moved. I wrote the launch into an episode of Development that Pays. At that point, I was committed! 2: Remember that there are more moving parts than you think. ---- Your focus will the on the product. That’s only natural. But a product won’t launch itself. You’re going to need plumbing. I had my three videos. I also had an email service capable of sending time-delayed emails. Three videos. Three emails. Simples. But it’s probably not a great idea to send people direct to the video: each should be on its own page... And I’m going to need a form - so that people can sign up... And the form is going to need page to “live on”... And…. I think you get the message :) 3: Launch to a limited audience ---- Although it’s important to launch before you’re ready, you don’t have to be damn fool about it; not everyone has to see your “warts and all” version. So launch… but make it a soft launch. Wikipedia defines a soft launch as “a preview release of a product or service to a limited audience prior to the general public”. In the case of the “Scrum vs Kanban the Mini Course”, I “hid” the announcement in a “regular” Development That Pays episode: only people that watched one particular episode all the way to the 4 and half minute mark got the link. 4 - Be ready to make running repairs ----- Launch day rolls around. You push the Big Green Button, and breath a sigh of relief. But don’t relax too much! To paraphrase Mickey Rouke’s character in Body Heat: “You got fifty ways you're gonna * up. If you think of twenty-five of them, then you're a genius... and you ain't no genius.” Well you may be you are a genius. I am not. A genius would not have…. wasn’t expecting to told that one of my videos had TWO audio tracks. - A genius would not have I wasn’t expecting requests for the second lesson on day one. So expect things to go wrong… and be at the ready to make running repairs. 5 - Remember that it’s an experiment ---- It bares repeating: Remember that it’s an Experiment*. This one cuts two ways: It’s a reminder not to over-egg the pudding. This is a Minimum Viable Product, not a Final Perfect Product. It’s also a reminder to measure. Your Minimum Viable Product is part of the Build Measure Learn loop. And if you don’t measure, you won’t learn. Recap ---- In summary: Launch before you’re ready There are more moving parts that you think Launch to a limited audience Be ready to make running repairs Remember that it’s an experiment https://www.youtube.com/watch?v=ark3b6d5i6A&list=PLngnoZX8cAn_vCE1plk4xhTWfJfvKEWs8
Views: 7920 Development That Pays
What is Kanban? Kanban System Basics in just Two Minutes.
 
02:32
50. What is Kanban? Kanban System Basics in just Two Minutes. // Kanban is one of a number of Agile Software Development Methodologies. Let's break that down: Software Development, in very broad terms, looks like this: → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe - The Product Owner decides what to build - The Development Team build it - Customers use it, experience it, benefit from it in some way What makes Software Development AGILE is that value is delivered to the Customer in small increments. And, importantly, feedback is gathered from customers and fed back into the process. The Product Owner takes input from various sources to create a PRIORITISED list of features and user stories: the PRODUCT BACKLOG. The Kanban system, as we'll see, consists of a very particular way of working. The team is helped to develop and maintain good habits with the assistance of an Agile Coach. Central to the Kanban system is the Kanban Board, which helps to track the progress of a strictly limited number of cards or tickets. It's important to stress that agile Kanban is a PULL SYSTEM: a empty (or nearly empty) column is a signal to preceding processes to send more work. This "pull" of tickets through the system helps to keep the Work in Progress (WIP) low, which in turn ensures that tickets move across the board in the shortest possible time. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Kanban is one of a number of Agile Software Development Methodologies Let's break that down. Software Development, in very broad terms, looks like this: The Product Owner decides what to build The Development Team build it Customers use it, experience it, benefit from it in some way What makes Software Development Agile is that value is delivered to the Customer in small increments And, importantly, feedback is gathered from customers and fed back into the process. It's the Product Owner's job to take input from customers - as well as from stakeholders and the Dev Team itself - and to organise it into a PRIORITISED list of features and user stories. The list is known as the Product Backlog. Kanban, as we'll see, consists of a very particular way of working. The team is helped to develop and maintain good habits with the assistance of an Agile Coach. Central to the Kanban process is the Kanban Board, which helps to track the progress of a strictly limited number of cards or tickets. It's important to stress that Kanban is a pull system. When testing of a particular feature is complete, the corresponding ticket moves to the Done column The empty column is a signal to the previous column to send another ticket. When this column runs low, it's a signal to the Dev Team to select another ticket from the To Do column. And when the To Do column is almost empty, it's a signal to the team to select another high priority item from the Product Backlog. This "pull" of tickets through the system helps to keep the Work in Progress (WIP) low which in turn ensures that tickets move across the board in the shortest possible time. Another thing to note about Kanban is that is a continuous process. This is one reason that it has fewer rituals that some other methodologies. What it does have is a Daily Stand-up Meeting. The Daily Standup is attended by the Agile Coach, the Product Owner the Development Team. And that's Kanban in two minutes. https://www.youtube.com/watch?v=LyS53-0jkok https://www.youtube.com/watch?v=CKWvmiY7f_g
Views: 13124 Development That Pays
Test Driven Development vs Behaviour Driven Development + FREE CHEAT SHEET
 
05:25
Can the principles of Test Driven Development (TDD) and Behaviour Driven Development (BDD) be applied to a simple DIY challenge? Grab your free TDD vs. BDD Cheatsheet: http://bit.ly/tdd-vs-bdd-cheatsheet Can the principles of Test Driven Development (TDD) and Behaviour Driven Development (BDD) be applied to a simple DIY challenge? In a previous episode, I employed a Waterfall approach to hang a shelf - and I made a right mess of it. In this episode, I repeat the process, this time adopting a "test first" approach. - 0:44 - Test Driven Development (TDD) - 2:55 - Behaviour Driven Development (BDD) → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 41. Test Driven Development vs Behaviour Driven Development + FREE CHEAT SHEET I tried to hang this shelf on this wall. I made a mess of it. The shelf was wonky. Could Test Driven Development - or even Behaviour Driven Development - have saved the day Shelving ----- A couple of episodes ago, I went through the process of hanging a shelf in what looked suspiciously like a Waterfall process: I did all of the measuring all of the transferring all of the drilling popped in all of the wall plugs and brute-forced the screws in. Alas, the end result was not good: the shelf was not level. But it got me thinking. Could tests have saved the day Is it possible to hang a shelf in a test-driven way Is it possible to hang a shelf in a behaviour-driven way I think we should find out. Test Driven Development (TDD) ---- Here's me hanging a shelf in my waterfall-like style. Let's stop it... there. Here's an opportunity for a test: I could come back at any time and check that the line really is level. That could be the first unit test. More marking and measuring. Stop there. Lots of opportunities for unit tests here: one for each of these measurements. What happened next Oh yes... I drilled all the holes. I popped in all the wall plugs. Stop. This is certainly a point where the unit tests could - and should - be performed. But it's actually a few steps too late. I've done far too much work between tests. Lets rewind a bit. Drill one hole (only). And perform the "unit tests" to ensure the hole went in in the right place. If the test fails - if the hole has gone in the wrong place - now's the time to fix it: there's no point in continuing until all the tests pass. Once the tests are passing, we can move on. Drill another hole. Run the tests. Correct as necessary. And so on until we have all four holes drilled - and tested. In with the four plugs. No harm in repeating the "unit tests"... but it's most likely that all would pass. And we're now in a position to finish the job. In go the screws. Unfortunately, it's no longer trivial to run our unit tests. But there is another test we can run: we can check for level. And given that we've had "green lights" up to this point, the chances are that this test will pass too. And it does. The shelf is perfectly flat. Behaviour Driven Development (BDD) --- So much for Test Driven Development; what about Behaviour Driven Development A shelf is a bit passive. It doesn't have have much in the way of behaviours. But if we are generous with our definitions, we could say that a desirable behaviour is that anything that are put on it should not slide off. Or put it another way, the shelf should be level. It can be argued, then, that testing the shelf for level is not only a unit test; it's also a behavioural test. In the sequence we've been through, this "behavioural test" was the last thing that we did. AFTER all the work had been done. The very opposite of "behaviour driven". Is behaviour driven development even possible in this case Turns out that the method my dad used to hang a shelf looks a lot like a behaviour-driven process: First step is marking the centre of the shelf. We could have a test for that - to verify that the mark really is in the centre of the shelf. That would be a unit test. (It's the first and last time we'll come across a unit test in the sequence.) Moving on... Check for level. That's the behavioural test. There it is again. This time it fails. Again, no point in continuing until "all the tests are passing". A quick tap with a mallet. Run the tests again - this time passing. Which means we can move on. There's the behavioural test again. And again one final time. Success! --- Would you believe it: It is possible to hang a shelf in a test-driven development way. AND its also possible to hang a shelf in a behaviour-driven way. Which is better I have my opinion... but I'd much rather he https://www.youtube.com/watch?v=4QFYTQy47yA https://www.youtube.com/watch?v=mT8QDNNhExg
Views: 56495 Development That Pays
The Wizard Of Oz Minimum Viable Product (MVP)
 
03:22
36. The Wizard Of Oz Minimum Viable Product (MVP) // Minimum Viable Products come in all shapes and sizes. Today we'll throw back the curtain (geddit?) on the Wizard of Oz MVP. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Key take-aways: - Zappos is the best example I know of a Wizard of Oz MVP - Zappos began in 1999 - They needed to know if people would by shoes online - They visited shoe shops and photographed shoes. These photos went on to the website - If someone ordered a pair of shoes, they would return to the shop, buy the shoes, and ship them to the customer - Note that from the customer's point of view, everything appears to be fully functional. - Other example of the Wizard of Oz MVP include Aardvark and Cardmunch Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Minimum Viable Products come in a range of shapes and sizes. Today we going to look at the one with the coolest name. Join me as we throw back the curtain on the Wizard of Oz MVP. 1999 ---- Its 1999. You're thinking about selling shoes online. You know that people buy shoes. What you don't know is whether people will buy shoes online. (It's never been tried before.) You devise a cunning plan. You go into town. You go into shoe shops. And you ... err... take photographs of shoes! Later, you upload the photographs to a website. What happens when someone buys a pair of shoes No problem. You pop back into town. You pop back into the shoe shop. And you buy the shoes! You then ship them off to the customer. Did you spot it ----- This, as you might have spotted, it the story of Zappos. It's the best example I know of a Wizard of Oz MVP. So called, because from the customer's point of view, everything appears to be in place. The customer has no idea that behind the scenes it's a little bit... manual. in Zappos case, all of the going to town, going into shops, taking photos... .... going back to town, going back into shops, buying shoes... is hidden behind the curtain. From the customer's point of view, the Zappos business looked and operated like a fully functional eCommerce operation. Different world ----- I love the Zappos story, with one teeny weeny reservation. It's not directly applicable to my world. For one thing, it's a long time since I dealt with a physical product. Perhaps you thought the same thing Let's look a couple of other examples. In each case, see if you can guess what's behind the curtain. Aardvark ---- Aardvark was about connecting people with questions to people with expertise. Behind the curtain Perhaps a neural network of stunning complexity No. A bunch of Interns! Cardmunch ------ Cardmunch is an app that scans business cards and converts them into contacts. It somehow managed to transcribe blurry photos of business cards better than any other Optical Character Recognition (OCR) system at the time. A technological breakthrough Nope. Behind the curtain Amazon’s Mechanical Turk! Amazon’s Mechanical Turk has a curtain of its own. What's behind the green curtain People! Minumum vs. Viable ----- One final thought before we click our heels together and head back to Kansas: David J Bland says the hard part about MVPs is that ... you decide what’s Minimum... ... the customer determines if it is Viable. A Wizard of Oz MVP all but guarantees a high 'viability' rating: the 'minimal' (usually manual) process is hidden behind the curtain. The customer, has no idea that corners have been cut. https://www.youtube.com/watch?v=VPVec5eupTY https://www.youtube.com/watch?v=xxjbxk8dUqI
Views: 8634 Development That Pays
Work On One Thing At A Time. Here's Why.
 
04:00
21. Work On One Thing At A Time. Here's Why. // I seem to be hard-wired to try to work on more than one thing at a time. It's one of the reasons I like to work in a Scrum or Kanban fashion - I'm forced to work on one thing at a I time. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe But is working on one thing at a time really such a big deal? In this video, we'll look at three reasons to avoid multi-tasking: 1:20 - Financial 2:01 - Learning 2:25 - Context Switching Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 I seem to be hard-wired to try to work on more than one thing at a time. It's one of the reasons I like to work in a Scrum of Kanban fashion - I'm forced to work on one thing at a I time. But is working on one thing at a time really such a big deal You have two jobs ----- Let's set this up. You have two things to do. Each requires five day's work. You have two choices basic choices. You can work on both tasks together. Or you can pick one, work on it until completion... then start on the other task. Let's get a little more scientific and add some numbers. Each task requires FIVE day's work. Each block here represents half a day - 10 blocks in total for each task. For the concurrent let's say that you work on one task in the morning, and the other task in the afternoon. For the sequential case, we'll work on task A for 5 days, then on task B for 5 days. Those are our two basic cases. What's the same --- The first thing we can say is that - one way or the other - you have completed two tasks in 10 days. That's what's the same. The are THREE ways that the two approaches differ - and I'd be surprised if you've thought of all of them: Financial ---- Let's attach some value to the work you're doing. Each of the task provides you with income of one thousand pounds. Which means you get £2000 at the end. Or £1000 here and here. These are very different financial positions. While you're working , you're likely to be spending money. Your working capital declines for 10 days, then gets topped up at the end. Compare that with the sequential case. That's half the working capital. Discovery and learning ---- It sounds a little counter-intuitive, but working on two tasks together limits the opportunities for one to benefit from the experience of doing the other. But if you take Task A and work on it until completion, EVERYTHING that you learned from the experience can be carried over to task B. In the extreme case, you may discover that Task B is no longer required. Context Switching ---- So far, we've been looking at an idealised case, where a 5 day task takes 5 days. I'm going to come right out and say it: I can't do a 5 day task in days. That's because it take me while to get warmed up. To get going. Truth be told, it takes me a while to get going every day. But what if I'm working on two tasks Every day, I'm coming back to a task that I haven't worked on for a significant period of time. Worse, my mind has been occupied with something entirely different. It's going to take a while to work out where I'd got to... and to get going again. Adding in all the time for these "context switches" we can see that under real world conditions, it takes less time to work on one task at a time that to work on two tasks concurrently. Chime in --- Those are three reasons to work on one task at a time. Do YOU have any others Or perhaps you have a good reason to work on two or more task at the same time. Either way, let me know in the comments. https://www.youtube.com/watch?v=CgbM4c8GJa8 https://www.youtube.com/watch?v=BCeGKxz3Q8Q
Views: 7191 Development That Pays
TDD and BDD - What Are The Key Differences? + FREE CHEAT SHEET
 
03:22
59. TDD and BDD - What Are The Key Differences? + FREE CHEAT SHEET // Grab your FREE TDD vs BDD Cheat Sheet: http://bit.ly/tdd-vs-bdd-cheatsheet When I try to start a motorbike, that's an example of a System Test. And a Blackbox Test. It's also an example of a Behavioural Test: it's a test of a behaviour that an end user cases about. If the motorbike doesn't start, I might check for a spark. That's an example of a Functional Test. It tests a collection of components working together. And if there's no spark? Perhaps there's a problem with the spark plug. Or the battery. Or the wiring between the two. To determine the root cause, we need to test each component in isolation. Testing a spark plug in isolation is an example of a UNIT TEST. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 If you're looking to a great - NON-TECHNICAL introduction - you've come to the right place. Kickstart ------ This is the motorbike I owned as a teenager. (Same model anyway. This one looks new. Mine was very, very secondhand.) It wasn't the most reliable machine. I had one key test that I'd do every time I came to ride it. I'd try to start it. I'd then go on to test... Nothing. Nothing at all. Of course not! UNLESS, of course, it didn't start. Then I'd do other tests. It became second nature for me to pull off the plug cap, unscrew the spark plug, push to back into the plug cap, and jump on the kick started to check that I was getting a spark. If the spark didn't look very healthy, I might check the spark plug gap. Unit Test --------- Checking the spark plug gap is a great example of a UNIT TEST. It's a test of individual component of a complex system. Importantly, it's a test of that individual component in ISOLATION. (After all, the gap doesn't depend on anything else.) Blackbox Test ------------- Compare that with the test of "starting the engine". Starting the engine is a great example of a Blackbox Test. I don't have to unscrew anything to perform the test. Indeed, I don't have to know anything about the inner working of the motorbike to perform it. All I need to know are the inputs to supply... fuel on neutral gear little bit of throttle operate the kick starter ..and the output to look out for: the sound of the engine running. It's a particular kind of blackbox test: it's a direct test of a BEHAVIOUR that any end user would expect of their motorbike. (The behaviour being: "a running engine".) It's a BEHAVIOURAL test. Functional Test --------------- What about the other test I mentioned: pull off the plug cap the plug cap, unscrew the spark plug, push to back into the plug cap, and jump on the kick started to check that I was getting a spark. It's neither a Unit Test, nor is it a Behavioural Test. It sits - somewhat uncomfortably - between the two. It's an example of a Functional Test: the expected "function" being the production of a spark. A function, by the way, that depends on a whole host of components working in concert: the battery, the spark plug and all the electrical components in between. As a test type, it's slightly unsatisfactory: A pass doesn't guarantee that the engine will start. We'd need a behavioural test for that A |fail doesn't indicate the root cause of the problem. We'd need a SERIES of unit tests do that. Those are reasons enough, I think, to eliminate functional testing from our enquiries. Leaving us - rather conveniently - with the very building blocks of Behaviour Driven Development and Test Driven Development. We'll go deep on the latter in the very next episode. https://www.youtube.com/watch?v=fsSMuqIpu_c https://www.youtube.com/watch?v=mT8QDNNhExg
Views: 16496 Development That Pays
How to Spot a Sick Agile Board At Twenty Paces
 
04:44
19. How to Spot a Sick Agile Board At Twenty Paces // Can you tell if your Agile team is in trouble - just by looking at the Agile Board? From a distance? While a healthy-looking board is no guarantee of a healthy and productive team, a sick-looking board can be strong indicator that something is wrong. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe In this video, we look at a selection of Agile boards, good and bad: 1:37 - Exhibit A - Kanban, healthy 1:50 - Exhibit B - Scrum, healthy 2:17 - Exhibit C - Development Dire Straits 2:49 - Exhibit D - Testing Times 3:14 - Exhibit E - Please Release Me 3:45 - Exhibit F - Stuffed Turkey CHIME IN: If you've seen an "interesting" Agile board, I'd love to hear from you: leave a comment below. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 This is you. This is your glass-walled office. From the comfort of your executive chair you can see your Dev team's Agile board. Question: without getting up and with no other information, can you tell if the project is in trouble It's staring you in the face ----- Not too long ago, I worked at a start-up. It was one of the most high pressure environments I've ever worked in. One things that added to the DISPLEASURE of working there was that the Dev Team was required to provide daily status updates. (This was in addition to daily stand-ups.) To cut a long story short, we all hated doing it. I remember thinking to myself "The bosses only need to look at the state of our Agile board to see what trouble we're in". I've since became a collector of dodgy-looking Agile boards. And I'd love your help to add to my the collection. More on that at the end. Healthy ---- First things first. let's remind ourselves what a healthy board looks like. Starting with a Scrum board. As we've seen before, Scrum starts by selecting a Spirit's worth of tasks... And then getting to work. The cards flow across the board. And by the end of the sprint , most - if not all - of the cards should have made it from one side to the other. Ready to be released. The process then repeats, with a new set of tasks being selected firm the backlog. A Kanban board has a different shape. it doesn't have the "periodic" property of the Scrum board: cards move across the board in a more or less continuous fashion. Snapshots ---- When we go spotting Agile boards in the wild, we won't be able to see them in motion. So let's just check that we can identify snapshots. First of all: Scrum or Kanban Well, the cards are quite evenly spread, so it's likely to be a Kanban board. There are not too many cards on the board, so the work in progress (WIP) here is nice and low. I'd be happy to give this board a clean bill of health. What about this one. Most of the cards are to the left, so it's most likely that we're looking at a Scrum board - and we're looking at the early stages of a sprint. (If it's a Kanban team - or if it's a Scrum team in the late stages of a sprint - then something is very wrong.) As before, not too many cards on the board, and not too many cards in one column. So again, I'd give this one a clean bill of health. Now that we're warmed up, let's have a look at come stinkers. Stinker No. 1 - Problems Developing ----- We've come across this one in an earlier episode. Not sure we can say much about Test or Release, but there's something very wrong with the Dev column. I suppose it's possible that this team has 20+ developers... but if they do, why are 20+ developers working in the in the same Agile team It's likely that many of the cards in this column are blocked, which is a symptom of starting development work on a task too early. This team might benefit from a bit more design work, before they dive into Dev. Let's move on. Stinker No. 2 - Testing Times ----- In this case, it looks like the dev team has been playing a blinder, with the result that things are piling up in the Test column. Now, I wouldn't say this was a project team in trouble, but what I'd like to see happen at this point is that the Devs would STOP developing and START lending a hand with some testing. (Your devs aren't too "big" to test. Are they ) Let's move on again. Stinker No. 3 - Please Release Me ----- Here we have a project team that's having all kinds of problems getting things released. Possible causes Perhaps Release is the hands of an over-zealous systems admin, who's not willing to share his keys. Or it might just be that we've caught this board at a bad time. I know that there are companies that have have release freezes at certain times of the year (for example, Xmas). It might be that if we saw this boa https://www.youtube.com/watch?v=CmU-g2hRO24 https://www.youtube.com/watch?v=W_V69q6CLPs
Views: 4230 Development That Pays
In Praise of the (Agile) Product Owner
 
04:48
43. In Praise of the (Agile) Product Owner // Who has the toughest time "Being Agile"? Is it the Dev Team? Is it the Lead Developer? What about the Business Owner? Or is it... the Product Owner? → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Arguably, it's the Product Owner that has the toughest job "being Agile". Building software in small, iterative cycles is easy to "sell" to a development team. But it takes nerves of steel on behalf of the Product Owner to trust that product features will build over time. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 You've seen these guys before. Question. Who has the toughest time being Agile Is it the Dev Team Maybe The Lead Developer Possibly. The Business Owner Could be. Or is it... (and I think it might be...) The Product Owner. Boxes and Walls ---- Hi this is Gary Welcome to 'Development That Pays'. I wanted to turn the spotlight on the Product Owner. But I could't decide what to talk about Then Vlad came to my rescue with this great comment that gets right to the heart of one of the hardest aspects of being a Product Owner. "Problem now is that some of them do not upgrade, and continue to use the “boxes” to climb the wall…" Clearly, that's going to need some context. A recurring theme here on Development That Pays are the twin concepts of do the right thing, and do the thing right Way back in Episode 2, i used the metaphor of two walls Each wall is a potential business opportunity. And each ladder represent is a product. What more important: building a great ladder or, picking the right wall Well, any old ladder will get you up the wall But... the walls lead to very different places. So we can say that: Picking the right wall is more important than building a great ladder. Doing the right thing is more important that Doing the thing right. HOWEVER... There's a fatal flaw in the argument And that's what we went on to talk about in Episode 3 From this point, both of the walls look the same. From this point you can't see what's on the other side So you've no choice but to climb up there and take a look. It's Catch 22. You need to pick the right wall... But you can't pick the right wall until you've climbed the wall which you can't do without... picking a wall! One thing is for sure: If we’re going to have to climb a wall that may turn out to be the wrong wall Then this is no time for Do The Thing Right. No, this is the time to get there quickly and cheaply Certainly not an escalator Nor a staircase. A ladder would be a good choice Or even - dare I say it - a pile of boxes. Getting Stuck with the Boxes ----- We now have the context we need for Vlad's comment. Vlad's concern is that we get stuck with the pile of boxes ... even after we've found the perfect wall. Come with me now to a meeting. The meeting was called by the Product Owner She has an an idea for a new product. She's invited the entire dev team. to come and discuss a new product idea. She walks up to the whiteboard and draws something that looks a lot like an escalator A discussion follows. The dev team is clearly concerned about the scale of the task At a certain point, the lead dev walks up to the whiteboard and says What about if we start by building this... ... then we can come back and build this ... then this ... then this From there it should be easy to build what you've asked for. Quick aside ---- At this point, I'd like you to take a moment and notice how you feel about this plan of action. Are you comfortable with it Do you have concerns Back to the Meeting ---- My guess is that these guys [the developers] like the idea For them, it's an easy sell: This thing [the escalator] looks like a nightmare to code. This thing [the pile of boxes] looks straightforward. Could be live by the end of the week. Bish bash bosh. What about the Product owner How does it look from her point of view The picture isn't nearly as rosy. First of all, there's a big different between what she asked for and what she's going to get - at least in the short term Then there's the "challenge" that version two is CONDITIONAL on the success of version one (And version one looks so ropey that it's hard to see it being a success!) And if the first version is a success, what then How long will it be before it can be built The Dev team have spare capacity now... but will they have spare capacity a month from now Hard to say. And we haven't even talked about stakeholders. If the Product Owner agrees to this course of action, her next job - when she leaves the meeting - will be to 'sell' the approach to various internal stakeholders. None of which https://www.youtube.com/watch?v=D0Ax7eJuNX8 https://www.youtube.com/watch?v=502ILHjX9EE
Views: 6852 Development That Pays
Agile Daily Stand-up - 5 Basic Rules
 
03:12
70. Agile Daily Stand-up - 5 Basic Rules // Grab your FREE copy of "Daily Stand-up Words of Wisdom": http://bit.ly/dtp-wisdom Doing Daily Stand-up *well*... is easier said than done. But doing it *well* starts with getting the fundamentals right. As you'll see, I've distilled things down to five very straightforward rules. And I'd be curious to know: - Are these the rules you would have chosen? - What additional rules would you add? CREDITS: TM & © Fox (1999) Courtesy of Twentieth Century Fox Film Corporation Cast: Edward Norton, Brad Pitt Director: David Fincher Producers: Ross Grayson Bell, John S. Dorsey, Arnon Milchan, Cen Chaffin, Art Linson Screenwriters: Chuck Palahniuk, Jim Uhls Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Looking for Daily Stand-up Meeting Rules Start with these five The Daily Stand-up. There's so much I could I say about the Daily Stand-up. So many tips. So many anti-patterns. But not today. Today, it's just the basics. The 5 "must-do" Daily Stand-up Meeting Rules. Brad, could you get us started First Rule of Stand-up ------ “Welcome to Stand Up." Thanks. Do you have any rules for us "The first rule of Stand Up is: 'You must to do Stand-up.'" Okay. Yeah. Sounds straightforward. Another one Second Rule of Stand-up --- "The second rule of Stand-up is: 'You MUST do Stand-up!'" Ohhh. Okay now I get what you're saying. Brad's right. Daily Stand-up is much more important - much more powerful - than most of would give it credit for. My experience is that even when it's done badly, the benefits outweigh the, err, dis-benefits So just do it. Get up. Stand up. Third Rule of Stand-up ---- The third rule of stand up is: "Same time every day." You want it to become a habit. Like brushing your teeth. So pick a time that works for your team and stick to it. Can't decided on a time Try 10am. Forth Rule of Stand-up ----- The fourth rule of Stand-up is: "Stand-up goes on for as long as it needs to." Err. Not quite, Brad. Daily Stand-up does NOT go on as long as it needs to. Unless, that is, it needs to got on for 14 minute and 59 seconds or less. If your Stand-up is taking more than 15 minutes, then it's a sign that something's not right We'll get into that another time. For now: stop at 15 minutes. Fifth Rule of Standup ---- Brad, can you help me one last time "The fifth rule of stand-up is: if your going to do Stand-up, you have to stand." He's right. You do have to stand. Let's not over-complicate this: meetings held standing up tend to be shorter than their seated counterparts. So get up. Stand up. Besides, if you follow this rule, it will be abundantly clear to you to the team to the rest of your organisation that you're following the other four rules: You stand up every day at exactly the same time for a maximum of 15 minutes and then you get on with your day. Got more -- So there you have it, the eight rules of Fight... err Stand up. Oh crap, I'm three short. Can you help me out What are YOUR top Daily Stand-up Meeting Rules Let me know in the comments below. https://www.youtube.com/watch?v=Hv8xtMgGGRg&list=PLngnoZX8cAn8NZIjKCfWOP3FaBTD6RcNN https://www.youtube.com/watch?v=1394SVz9MAw
Views: 14199 Development That Pays
Scrum vs Kanban - An Agile Battle of Olympic Proportions + FREE Course
 
16:29
The recipe for a perfect Natural Experiment: take an Agile team. Split it in two. Feed one half Scrum. Feed the other half Kanban. Observe the result. The recipe for a perfect Natural Experiment: take one Agile team. Split it down the middle. Feed one half Scrum. Feed the other half Kanban. Observe the result. Sounds unlikely? Well that's exactly what happened to my first Agile team. And I had a front row seat for the whole thing. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 116. Scrum vs Kanban - An Agile Battle of Olympic Proportions + FREE Course Scrum or Kanban Which is better How could you find out What if you could take an agile team Chop it right down the middle Have one half do Scrum Have the other half do Kanban And sit back and observe the result. Well, that's exactly what happened In the building right BEHIND me And I had FRONT row seat for the whole thing. ~ And if your interested in scrum or Kanban And ESPECIALLY if your interested in both Stick around until the end and I'll tell you how to get your hands on a free mini course. The Scrum vs Kanban mini course. Bumper My name is Gary Straughan Welcome to development that pays And welcome to the site on the 1908 Summer Olympics. A stadium once stood on this very spot. But now that all remains is this plaque. A plaque I didn’t notice on my first day with this… err… major broadcaster. I was about to join a team that I was told “did agile” And I could see from the get go that they weren’t doing it by halves. There’d clearly been lots of training. They had all kinds of tools. They were doing all kinds of 'rituals'. But at the time, my attention was elsewhere. I’d never worked with so many talented developers. So I had my head down/… focussing on the code. On trying to keep up. It wasn’t until I’d been there about a year that something happened To shine a spotlight on “that Agile Stuff”. The department reorganised. My team was split in two. Although reporting lines changed, the seating plan didn’t. There was one outward indication of change: where there had been one agile board, there were now two. And we did two stand-ups every day: ours at 10:00am, theirs at 10:15. Ever-observant, it took me a couple of weeks to notice that the other team was doing a different 'flavour' of Agile. I hadn’t realised that there was more than one flavour of Agile. What my team was doing was, called Scrum. The other team was doing something called Kanban. Kanban Really This was a word I knew from way back. But I knew it in the context of manufacturing. I couldn’t immediately see how it applied to the process used by my former teammates. So I talked to the Lead Developer of 'Team Kanban' about it. 'What the difference between Scrum and Kanban ' I asked He was ready with an immediate answer: 'You Guys Talk About Work. We Do Work.' Ouch! In that moment, I learned an important lesson about Agile: It can be an emotive issue. Beliefs can be deep-seated. The Team Kanban Lead Dev clearly thought that Kanban was better than Scrum. I held the opposite view. My view was both strongly held and completely without evidential foundation. I’m a little older now. And, I hope, a little wiser. I can now see that the team split was a perfect “Natural Experiment”. You know the kind of thing: “Take two identical twins. Separate them at birth. Feed one Scrum. Feed the other Kanban. Observe the result.” So I hope you’ll join me on a little forensic investigation Starting with a 20,000 view of each team's processes. My team - let’s call it "Team Scrum" - worked in two week Sprints. At the beginning of s Sprint, we’d take ourselves off to a quiet part of the building for a Sprint Planning session. The Product Owner would select items from the backlog, and we’d play “Planning Poker” to estimate the size each item. We’d continue until we had roughly one “Sprint’s worth” of cards. Sprint Planning over, each developer would pick up a card and set to work. Every morning there’d be a stand-up - 10 am on the dot. And so it would go on day after day, with the cards gradually making their way across the board. By the about the Tuesday of the second week, we’d expect all of the cards to have moved at least one step. It was then a race - a "Sprint" - to get everything tested and ready for release on Friday. We didn’t always succeed in getting everything across the board. Any item that failed to make it would be “recycled” into the next Sprint. On the Friday morning, everything in the release column would be packaged for release. Oh, and one last thing to round out the Sprint: a Retrospective. A chance for the team to get together to https://www.youtube.com/watch?v=yUKYgotEEj0
Views: 7938 Development That Pays
Scrum vs. Kanban - "Kanban For The Win!"
 
05:26
How will Team Scrum cope with the loss of their fearless leader? And who is the mysterious "Agile One"? Grab your FREE Cheat Sheet: http://bit.ly/scrum-vs-kanban-cheatsheet How will Team Scrum cope with the loss of their much-loved Scrum Master? And who is the mysterious "Agile One"? Quick recap: - An Agile Team Split in two. - One stuck with Scrum. - The other changed to Kanban. - Team Kanban thought they were hot stuff... but their board told a different story. LINKS - Part I - https://www.youtube.com/watch?v=9Jgu1BlTlSc - Part II - https://www.youtube.com/watch?v=n2ZrUQNwrUk → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 16. Scrum vs. Kanban - "Kanban For The Win!" Previously on Development that Pays... --- I joined a new team. It was a team that “did Agile”. It was doing all the rituals. It had all the artefacts. There was a reorganisation. The Team Split in two. One team stuck with Scrum…  (working in two week sprints) One Team moved to Kanban (working in a continuous fashion) Team Kanban thought they were the hot stuff… … but its board told a different story. Then one day, our Project Manager come Scrum Master come all round superstar, resigned. Back to the story -- Hi, this is Gary, Welcome to development that pays. And welcome back to the concluding part of our Trilogy. If you missed Parts one and two and you'd like to catch up, there should be links in or around this video. A New Hope ---- It was a dark time for Team Scrum. We'd just lost our awesome project manager. News came in that an external "Agile Coach" was going to be “parachuted in”.  Someone looked him up online.  Very high profile. Very expensive, we guessed. And very, very… KANBAN. As I said back in Part I, people who “do Agile” often have strongly held views about how things should be done. And our ongoing grudge match with Team Kanban had only served to entrench our view that Scrum was awesome and Kanban was rubbish. So we were ready for him. We’d expected him to be pushy and directive. And we intended to push back. Hard. As it turned out our new Coach - let’s call him The Agile One - was neither pushy nor directive.  Lesson One ---- At our first meeting he said that he had a new (Agile) board that he’d like us to try. But only if we wanted to to. He unrolled the A2 paper that he’s brought with him.  The key to it, he, explained, it that each column is just wide enough for a single post-it note. And high enough for just five. That's it. “This is important. By limiting the number of cards in each column, we make sure that things get across the board as quickly as possible.” A couple of team members raised concern whether a post it would stick long enough,… and whether it might be necessary to bring some BluTak into play.  I smiled to myself. If our “resistance” centred around the relative adhesive properties of Postits and BluTak, The Agile One had already won. And so our Kanban journey began. The paper board - together with our winning combination of postits AND bluTak - taught us to to keep our work in progress under control. We had learned our first lesson. Lesson Two --- At the time of his arrival, a number of cards on the board were blocked.  The Agile One asked about one of them. "We're waiting for so-and-s0 to get back to us” I said. Superstar Agile Coach would say: “What can we do to move that along ” I’d say: “ I’ll email him today”. WRONG ANSWER! Where’s his office In the next building.  "Let's go and talk to him." “When " "Right now” And off we walked off together.  And we found the person. And we had a relaxed conversation. The Agile One asked questions. And what was blocked became unblocked. Effortlessly. None of us could match The Agile One’s ability to make problems disappear, but we did - in time - learn the value of talking to people face to face to get issues unblocked. And - in the case of new cards - to make sure that they didn’t get blocked in the first place.  That was our second lesson. Lesson Three ----- One morning, The Agile One brought a guest to stand-up. It transpired that The Agile One was moving on to bigger and better things. The new person was his replacement. If The Agile One was a little bit Obi Wan Kenobi, the new guy was more Yoda: a little bit annoying, and very into "basic training”. Where the teaching of The Agile One had been effortless, with the New Guy it was more the school of hard knocks.  "Release more often, you must”. (He didn’t really talk like that.) We explained that it was a painful process https://www.youtube.com/watch?v=sOlFPi5xJqQ&list=PLngnoZX8cAn9xNunWcv7ujoD7o0AytVlT https://www.youtube.com/watch?v=Kc4fTryN8Nw
Views: 59922 Development That Pays
Kanban: from Toyota Corporation to Software Development
 
03:22
25. Kanban: from Toyota Corporation to Software Development // The system that we know as "Kanban" can trace its roots back to the late 1940's. Has modern-day Kanban stayed true to its roots? Or have we thrown out the baby with the bathwater? → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Key take-aways: - Kanban originated in the world of manufacturing. - WIP - Work in Progress - represents a cost to the busines: there's money tied up in each item; each item takes up floor space, etc. - Mr. Taiichi Ohno of Toyota set out to solve the problem of excess WIP - He changed the production system from "push" to "pull" - The emabler for the pull system was the Kanban Card - The Kanban Card signals to the previous process to "send more stuff" - Kanban is a Japanese word that roughly translates as signboard or billboard Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 This is a Kanban board. How many Kanban cards do you see Keep that number in mind. Back to the factory floor ---- As you may know Kanban originated in the world of manufacturing. Here's a machine for processing... err... Things! Thinks arrive from the left, are processed through the machine And then move off to the right. So far so good. But what if things arrive at a greater rate Slowly but surely things start to back up to the left of the machine. Excess Work In Progress (WIP) is expensive ---- This build up is a problem. There's more work in progress that there needs to be. And that represents a cost to the business in a couple of ways: There's money tied up in each of these Things The Things are taking up floor space... which also has to be paid for. Mr. Taiichi Ohno --- This is the problem that Mr. Taiichi Ohno of Toyota set out to solve. He borrowed a trick that he spotted in an american supermarket. Mr Ohno observed that store shelves were stocked with just enough product to meet consumer demand. The inventory would only be restocked when there was a visual signal - in this case, an empty space on the shelf. To transfer this to the factory, Mr. Ohno needed a way for one process to "ask" the previous process for more stock. The Kanban Card ----- Enter, you guessed it, the Kanban card. Our machine processes a thing... and despatches a Kanban card to the previous process. Kanban roughly translates as signboard or billboard. The Kanban card is a signal to the previous process to send a Thing along. Naturally, what's good for the goose is good for the gander. Our original machine is subject to the same rule: It should only be processing in response to demand. Meaning... another Kanban card. As thing stand, the work in progress is just about as low as it can be... ... but it's also slower than it might be. We can speed things up by allowing a - strictly limited - bit of Work In Progress. Notice that the additional things are held to the right of the process that's just processed it. That's important, because it means that each process is in control of its own Work In Progress. Kanban for Softwar Development ---- Can you see how this relates to the (software development) Kanban Board The processes... are columns. The Things... are the tickets The Kanban cards are... nowhere to be seen! Have we thrown the baby out with the bathwater Not quite. The Kanban cards are with us in spirit if not in body The important part about the Kanban system is the signalling. This column signals its need for a ticket by virtue of its... err... emptiness. Much like the empty space on the supermarket shelf. https://www.youtube.com/watch?v=aeo1JcdHjGU https://www.youtube.com/watch?v=R8dYLbJiTUE
Views: 3731 Development That Pays
From Scrum to Scrumban in 6 Steps + FREE CHEAT SHEET
 
17:05
Here's your roadmap for the journey from Scrum to Scrumban. And remember to grab your FREE CHEAT SHEET! https://www.developmentthatpays.com/cheatsheets/scrum-to-scrumban In 2009, Corey Ladas gave us Scrumban. He presented it - not as an alternative to Scrum and Kanban - but as a PATHWAY from Scrum to... something more "kanban-like". In this episode, we'll walk that pathway: Six steps that take SCRUM and add layers of KANBAN and LEAN. Along the way, we’ll step outside of the boundaries of Scrum... but you may be surprised at how we get before we “break out”. Which means that even if you have no plans to move from Scrum to Scrumban… this episode is a must-watch. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 126. From Scrum to Scrumban in 6 Steps + FREE CHEAT SHEET Last time I introduced you to this man, Corey Ladas, and his invention, I guess you could call it that, Scrumban. If you missed that episode and you'd like to catch up, you can find a link to it over here. As I said in that episode, Corey didn't so much position Scrumban as a midway, halfway house between Scrum and Kanban, rather as a pathway from Scrum to ... well, to something else. This I think was a super shrewd move, given the level of adoption of Scrum, and the fact that Scrum is often the first step that teams take when getting in to Agile. So how easy is it to follow this pathway from Scrum to Scrumban Well, I think we should go and find out. And as we travel, keep your eyes open for the moment that we break, or breakout, of Scrum. I think you might be surprised at just how far we get before we do so. Step one, visualize the work. Oh, you thought this journey was going to be difficult If you're like most Scrum teams, you probably already have a board. And the board is just one of the things that Scrum doesn't mandate. In Kanban though, a board is mandatory. It's one of the key tenants of Kanban that we must visualize our work. So if you have a board, even one as simple as this one, then you've already taken your first step toward Scrumban. Congratulations. At this point I'd like to introduce you to the team we're going to be working with today. I'm going to ask them to take themselves off for a super quick sprint planning session. And I do mean super quick. Thank you very much, team. Eight items, let's call them tickets, in the to do column. As this is Scrum, we could also call the to do column the Sprint Backlog, they're effectively one and the same. Time to set to work starting each day, of course, with a daily standup. One thing that every developer knows, but few will admit, is that it's much easier to start a job than to finish it. So if we check in with this team again after a couple of days, there's every chance that their board will look like this. And this where visualize the work starts to pay us back. It's very clear that the three developers are attempting to work on eight tickets simultaneously. I could spend a whole video, a whole series of videos, talking about why this is undesirable state of affairs, starting with the cost of context switching. But for now, I think we'll just move on quietly to step two. Step two, impose work in progress limits. If you know anything at all about Kanban, you'll know that one of the things it does is to impose work in progress limits. So let's give that a go. I'm going to rewind to the beginning, and this time each developer is allowed to work on a maximum of two tickets at any one time. Ideally, it would be just one ticket, but we know that things happen, and tickets can get blocked. So, we're going to give people just a little bit off leeway. So two tickets maximum. Let's see how that plays out. Fast forward a couple of days, and oh, it does seem now that we have all three developers working on exactly two tickets, we've given them the opportunity to work on two, and they haven't been slow to take us up on our offer. They've stayed within the letter of the law, but the spirit of the law, not so much. I think we should try a different work in progress limit, something a little more Kanban style. And I'm going to do that, not by applying a limit to a person, but by applying a limit to the process. The process here is the in progress column, and I'm going to squish it so there's only room for one ticket in the column. And I'm going to draw a hard limit at five tickets. It's hard to overstate the impact of what that simple change will have on this team. Starting with what happens when this occurs, which it will. Now if a ticket gets blocked, the developer no longer has the option of reaching for a https://www.youtube.com/watch?v=fgT4AaKcBUA&list=PLngnoZX8cAn_niM2ehLsFGPh33DGU5it9
Views: 5810 Development That Pays
What is Agile? Agile Explained... with a PENCIL!
 
04:36
Need a powerful demonstration of Agile that you can perform almost anywhere? Grab a pad and a pencil - I have a treat for you! What is Agile? Today, I’m going to demonstrate Agile. By playing FOOTBALL. With a PENCIL. Oh - and stick around to the end because I have a favour to ask! → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 102. What is Agile? Agile Explained... with a PENCIL! Football ------ This is St James Park: home of Newcastle United Football Club. I was born in Newcastle, and grew up a few miles out of town. In Newcastle, they say that football isn’t life and death: it’s more important than that. Alas, my football skills were sadly lacking. But there was this game we’d play in class - when the teacher wasn’t looking. Football. Kind of. I’m sketchy on the rules; I guess we’d take turns to get across the pitch to score a goal. Agile Analogy ----- It struck me recently that the game is a rather lovely demonstration of Agile: We have value delivered in small increments as the “ball” makes its way up the pitch. And we have the opportunity to “course correct”: it’s easy to recover from a wayward first "kick". Special Pencil ------ Hold on a second. I think I’ve just figured out how to play this game. Where did I put my special pencil Ah here it is, My turn: Ready. Aim. Aim some more. Fire! I mean: Shoot! As I'm sure you've guessed, this big-ass pencil represents a Waterfall Approach. It’s an eggs in one basket approach: we design, build and test this leviathan. And launch it into the world. It’s either a big hit. Or it’s a big miss. No second chances. If our aim is true. If the playing field is flat. If the goalposts don’t move. We’re on to a winner. For me, that’s an awful lot of “ifs”. An awful lot of RISK. In an uncertain world, the big ass-pencil starts to look less like an unfair advantage, and more like an enormous liability. In an uncertain world, we need a pencil that’s more…what a good word here Agile. With this small but perfectly formed Agile pencil: our aim doesn’t have to be true. The playing field doesn’t need to be flat. The goal posts don’t need to stay put. All we have to do, is keep kicking. Can you do better ------- So what did you make of the What is Agile pencil analogy Perhaps you hated it.You thought that it didn’t work at all. Perhaps you really liked it, and are wondering where you can your hands on an enormous pencil. Either way, I’d like your help with something I’m planning: I’m on a mission to collect the best “Agile Analogies”. So if you have a good one… or have heard of a good one… or can think of a good one Please let me know. If it helps to answer the question: “What is Agile ” I want to hear about it. Let me know in the comments below. I very much look forward to reading them. And I’ll feature the best ones in a future episode - or episodes - of Development That Pays. https://www.youtube.com/watch?v=k_ndH7B-IS4&list=PLngnoZX8cAn-a2Yh1XUanjK3z7n4qD2PR
Views: 66004 Development That Pays
Agile Estimating & Planning [2018] - The Planning Fallacy
 
06:33
When will it be finished? Seems like a reasonable question. It isn't. Today we'll meet Daniel Kahneman. (He's a Nobel Prize winner, so he's kind of a big deal.) His work help us to understand why estimates are so often wrong. Really wrong. This Part 2 of an Agile Estimating mini-series. If you missed Part 1, start here: https://www.youtube.com/watch?v=NPIKAvjuJXc&list=PLngnoZX8cAn-9tWYxyQQPGoHW7DETBCjK → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 119. Agile Estimating & Planning [2018] - The Planning Fallacy I am terrible at estimating. But I take comfort from the fact that you’re terrible at estimating too. Welcome to Development that Pays My name is Gary Straughan And welcome back to this “mini-series” on Agile Estimation and Planning. If you missed the first episode this link will take to you to in and deliver you automatically right back to this point. It’s a while since we’ve seen the Lego team. Let’s bring them back in, Our hero, the developer in blue Is working on an important feature. Not an improvement to an existing feature. A brand new features. A feature that - with a bit of luck - will be a game-changer for the business. And then it happens. A sequence of events… that may be familiar to you. The Boss asks the Product Owner a question: “When will it be ready ” The Product Owner seeks out the blue developer. And asks him a question: “When will it be ready ” The Blue developer thinks about it for a moment and says... We’ll come back to this in a moment. This is Danny Kahneman Nobel Laureate, no less. Early in his career, he was part of a team working on a new textbook a new university curriculum. A year in, and the the project was going well. Kahneman had the idea of asking the team a question. The question was, more or less “When will it be ready ” He didn’t ask the question in open forum; Each of the team wrote their answer on a piece of paper. When Kahneman read the responses He found they were in broad agreement Everyone thought it would take 18 months to 2.5 years to complete the project. Now, one on the members of the team was the Dean of the School of Education. And it occurred to Kahneman to ask him another question. He asked if he could think of other teams that have done what we’re trying to do And he said that he could How did they get on Well… not all of them succeeded. About 40% of them… gave up. And those that succeed The Dean couldn’t think of ny that took less than 7 years. Khanman realised that something funny was going on here: The Dean had all the information he needed to make a much better estimate. But he - like the others - had estimated between 18 months and 2.5 years. Khanman went on - with long-time collaborator Amos Tversky - to study this phenomenon in detail. And in 1979 they proposed the Planning Fallacy. As Wikipedia puts it: “a phenomenon in which predictions about how much time will be needed to complete a future task display an optimism bias and underestimate the time needed.” So when the Boss asks the Product Owner “When will it be ready ” And the Product Owner asks the Developer “When will it be ready ” The answer that the developer gives is high likely to be wrong. It’s likely to be far too optimistic. Even if the developer knows that similar tasks performed by others have taken longer. Indeed… even if the developer knows that similar tasks performed by HIMSELF have taken longer. (Or herself,. I do try to me gender- neutral around here. But this one looks like a guy to me.) So this sequence of questions is, at the very least, not helpful Just pause for a moment and think about how you feel about that. Perhaps you think that this question is more than reasonable. That you need some measure of predictability to do your job. Or perhaps your in this position - the Product Owner. Perhaps you’re feeling just a little bit insulted, because you’d never ask a developer for an estimate - at least, not in this way. Or perhaps you’re thinking something else. If so, I’d love to know what it is. Let me know in the comments below. // Add in the end Is there a way to give each of these people what they need I’m not sure… but we’ll take a step in that direction in the next episode. If you enjoyed this epsiode, please give it thumbs up. Share it with your network. And hit the logo right here For a new episode every Wednesday. Cheers for now. https://www.youtube.com/watch?v=rvkv1k3mpKg&list=PLngnoZX8cAn-9tWYxyQQPGoHW7DETBCjK
Views: 3639 Development That Pays
Agile Daily Standup - How To Walk the Board (aka Walk the Wall)
 
05:24
10. Agile Daily Standup - How To Walk the Board (aka Walk the Wall) // Last time we looked at the most common Agile Stand-up model and compared and contrasted it with the "Walk the Board" model. ("Walk the Board" is also known as "Walk the Wall", "Talk to the Card", and "Talk to the Work".) → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe This time, we'll be Walking the Board - side to side in 5 minutes or less. LINKS -- Episode 8: https://www.youtube.com/watch?v=aFLgG8cduiI Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Last time we looked at two ways of running stand-up: The round-robin yesterday-today-blockers model The Walking the Board model - otherwise known as Walking the Wall, Talking to the Card, Talking to the Work Today we’re going to be Walking the Board - end to end in 5 minutes or less Hi, this Gary. Welcome to Development That pays. Here’s the board we’re going to be walking. Today I’m going to lead stand-up. I’m not the scrum master, I’m not the lead developer… I’m just a Plain Old Developer. (If you watched Episode 8, you’ll know that I’m a big beliver in 'sharing the love' when it comes to stand-up) I get things going by pointing to this card Why do we start at the top right This is a whole discussion in itself… but I’ll give you two short answers for now The first is financial The items to the right of the board are closest to being live. Which means that they are the closest to providing value. (As you know, I’m very keen on the VALUE side of software development) If you’ve come across the concept of net present value, you’ll know that income now beats income later… and income tomorrow beats income next week. If you imagine a board where the features are of roughly equal value, then the items to the right of the board have highest net present value. It’s fitting then that we talk about them first. A second reason for starting at the right it purely practical: We’re going to moving the cards across the board from left to right. By starting at the right, we create space for the cards to move into Where were we Oh yes, I’m standing at the board pointing at this card. It’s assigned to Development Dave - our fearless leader. He’s in charge of releasing this week. He says that this card, and indeed all of the cards in this column, will be released today. Excellent news. We’re done with the release column, so I move on and point to only card in the Test column. The card is assigned to Tim. He reports that he’s having trouble a bit of trouble with it. Kevin - the developer who did the work on the ticket - asks what the problem is. Before we know it, Tim and Kevin are involved in a deep discussion about the card. Stand-up is not a place for deep discussions. The team comes to the rescue. One by one they raise an arm in the air. Tim and Kevin get the message… and agree to take the discussion offline. (In plain english, this means that they are going to have a chat about it after standup.) We’re done with the Test column, so over to the Development column. I point to the card here at the top Fiona is assigned to this one. She says that she finished it yeserday and it’s now ready for test. 'Excellent', I say. And I move the ticket over to the Test column. I’m going to freeze it right there... Because something important just happened. Fiona completed the task yesterday, but she didn’t move the ticket on the board. Perhaps she forgot to move it. Perhaps she couldn’t be bothered to move it. But what if she didn’t move it on purpose What if she wanted to wait until stand-up to move the card How interesting. It’s actually quite satisfying to move a card across the board; And it’s easy to see that is could be even more satisfying to move the card across the board in front of the entire team. You might argue that the Board should be up to date at all times. that Fiona should have moved the card yesterday. But that would have robbed Fiona of her moment of glory. And that, in my opinion, would have been a mistake. I’m all for moments of glory. Next card is this one. It’s Dave’s. He reports that he’s just started, but so far it seems to be going well. Good enough for me. The next card is Kevin’s. More good news - he completed the work just before stand-up. He moves the card over to the Test column Hold on just one minute. He moved the card ! Isn’t that supposed to me my job After all, I’m leading stand-up today. Not at all. If moving a card is a moment of glory, then walking up ro the board and moving the card can only add to the experience. As the person running the standup., I’m happy to move the cards around. But I’m even happi https://www.youtube.com/watch?v=316qdj10j9M https://www.youtube.com/watch?v=_3VIC8u1UV8
Views: 19489 Development That Pays
Are You Killing the Daily Stand-up?
 
04:51
The Daily Stand-up is a cornerstone of Agile Software Development. And you may be undermining it... without even knowing it. Grab your FREE copy of "Daily Stand-up Words of Wisdom": https://www.developmentthatpays.com/cheatsheets/daily-standup-wisdom Product Owners, Product Managers, Scrum Masters, Agile Coaches, CTOs and Business Owners: I'm talking to you. It's all too easy to undermine the Daily Standup (aka Daily Scrum). That's the bad news. The good news it that it's very easy to fix. Key take-aways: - Stand-up should start at the same time every day - Stand-up should not depend on every team member being present - Every member of the team should be capable of running Stand-up → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 8. Are You Killing the Daily Stand-up? The daily stand-up - also know as the Daily Scrum or “Huddle” is a key element of Agile Development. What if I told you that you - yes YOU - could be undermining the daily stand-up without even knowing it Not by HOW your doing it - but by WHEN your doing it. Hi this is Gary. Welcome to Development That Pays. It’s 9:50am. Your development team is already hard at work. Sorry, couldn’t resist. It’s 9:50 am John and Sarah have been in for a while. Both have their headphones on. John is checking email. Sarah is trying to to get some code to pass one last test. With a bit of luck she’ll being able to commit the code before Stand-up. 10:55 John gets up to go and make himself a cup of tea. Kevin strolls in, Costa Coffee in hand. Dave - he’s the Lead Developer - is heading up in the lift. He’s cutting it fine. As usual. The entire team is gearing up - each in their own way - for the 10 o’clock stand-up. The clock ticks around to 10 am. And the entire team rises as one. Let’s run that again. The clock ticks around to 10. But no one stands up. They’re waiting for something. They’re waiting for someone. They’re waiting for you. But you’re not there. You’re in a meeting. You’re always in a meeting. But it’s no biggie, you think. You’ll be finished in 5 mins. You have no idea of the damage you’ve done. Lead Developer Dave is not amused. As usual, he’s had a nightmare commute. It’s tough for him to get in by 10. But most days he manages it - even if it is by the skin of his teeth. He made the effort. Why didn’t you Kevin is starting to feel anxious. He spent a good part of yesterday afternoon wrestling with a piece of code without success. Inspiration did not strike overnight. He was going to ask for help during stand-up. But it doesn’t look like stand-up is going to happen. Should he wait Should he start something else He’ll give it another 5 minutes. John is just about to start a new ticket. But he wasn’t planning to actually start until after stand-up. Is there any point starting now Probably not. Facebook. Only Sarah is grateful for the delay: the extra couple of minutes were enough to get the test to pass and the code committed. At the same time, she can’t help thinking that “management” doesn’t seem to hold the dev team in very high regard. You escape from your meeting and you stride into the room at 10:07 precisely. "Let’s do stand-up” you say brightly. The Dev Team rise as a single unit. And clubs you to death. In just seven minutes, the minds of your dev team have wandered into all sorts of places. Very few of them positive. That’s all it took. 7 minutes. Let’s fix this right now. With two very simple rules around Stand-up. Rule Number One Stand-ups happen every day at exactly the same time. Rule Two In cases where you... have a meeting, something comes up, you’re delayed getting in to work... SEE RULE ONE Who’s going to make sure this happens You are. But not directly. You’re way too much of a meetings person. In any case, the problem it not you. The problem is that everyone else is waiting for you. So let your team know that stand-ups need to happen every day at 10am (Or at what ever time you choose. But pick a time and stick with it.) And make sure that it becomes everyone’s responsibility to call for standup. You need to get to a point that you KNOW the standup will happen whether or not you’re there. And I’d encourage you to test it out. Go into hiding just before 10am. Walk in at five past ten. If stand-up is in progress, join it. And at the end, congratulate the team for going ahead without you. If it isn’t in progress, ask how it went. You EXPECT to hear that is went ahead. You’ll be DISAPPOINTED to hear that it did not take place. If you can get stand ups to happen with this relentless regul https://www.youtube.com/watch?v=aFLgG8cduiI https://www.youtube.com/watch?v=q_R9wQY4G5I
Views: 20311 Development That Pays
Agile to Waterfall 2. Waterfall Bites! + FREE CHEAT SHEET
 
06:07
My new Waterfall process was more efficient. No doubt about about. But there was a problem. When things went wrong, they went BADLY wrong. Grab your free WATERFALL vs AGILE Cheat Sheet: http://bit.ly/waterfall-vs-agile Last time, I told the tale of an Agile process that morphed into a Waterfall process. The new Waterfall process was more efficient. No doubt about about. But there was a problem. When things went wrong, they went BADLY wrong. NEED TO CATCH UP? - https://www.youtube.com/watch?v=P8IUVC_ldc0&list=PLngnoZX8cAn8O7-_srINlYZFSp5NDWGjs&t=83s → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 75. Agile to Waterfall 2. Waterfall Bites! + FREE CHEAT SHEET Previously.... My process evolved over a period of months from Agile to Waterfall. The new process was more efficient. But it wasn't long before I learned a hard lesson. Waterfall ... can bite. Wisdom ------ This is Professor Professor David Myddelton of Cranfield University. What little I know of accounting and finance I owe to this man. His classes were borderline terrifying: woe betide anyone who failed to prepare for a lecture. But Professor Myddelton was not without a sense of humour. Like the time he said that is was trivial to make a fortune on the stock market. Really He had our attention. He told us the that it was so trivial, that only two things had to be true. Number 1: you have do to something different from the the rest of the market. We couldn't think what the second thing would be. Some of the Investment banking types were brave enough to take a stab at it. He waved each suggestion away. Finally he put us out of our misery. You have do to something different from the the rest of the market. And, you have to be.... You have to be right! Hmmm. Great. Thanks professor. Agile to Waterfall ----- In the previous episode, I described how the process I use for making videos has changed over time: Man makes videos in an iterative fashion. Let's call it an Agile Process Man is unhappy: each video takes 10-20 hours to make Man optimises process Man ends up with something that looks like a Waterfall process. Mike Jones had a much more eloquent review: "You have shown us how to apply lean principles by reviewing your end-to-end value stream and removing waste and rework." Mike, you're absolutely right: my process has come a long way since those early days. My new Waterfall process works well. Really well. Except when it doesn't And when it doesn't... Well, let's just say that those are the weeks my family still talk about. Let's change this a bit. Some brighter colours. Make the circles into labels. And change the length of the bars. Writing the script is the longest battle: it develops over the course of several days. Recording the audio is quick. Visuals. And then editing it all together. Yeah. That looks about right. On good week, that's more or less how it pans out. On a bad week, the visuals takes waaaaay longer I'm not taking it taking 10% more work. I'm talking 100% more work. I don't have the luxury of taking my sweet time about it. The videos go out on Wednesday at 3pm come hell or high water. I've got myself a cast iron, fur-lined, ocean going HARD DEADLINE. I'm committed. I have to find the time. Even if it means getting up at 4am. I'm sure you can guess what this does to my mood. I never need to tell my family when I'm in this situation. They know. And the worst thing about the whole sorry situation It's that I'm acutely aware that this ugly pile didn't happen by accident: there's a clear cause and effect here. Some bloody idiot wrote something into the script over here... ... that led to all the extra work over here. I am, quite literally, the author of my own destruction. (literally the AUTHOR. Not quite literally destruction. Although sleep deprivation makes me feel pretty destroyed.) Fighting back ------ It turns out that fixing this is trivial. So trivial in, in fact, that only two things need to be true: The script has to be completed in a timely fashion. And... anyone anyone it has to be... It has to be RIGHT! Right for what Well, right in and of itself: a half-decent story with a start, a middle and an end. That kind of thing. But also "right" in a less obvious way: right for the next process. Scriptwriter Gary needs to be aware of the visual implications of what goes into the script. If he puts something in there that requires a ton of video work, then Designer Gary is going to have a bad week.. Now, ScriptWriter Gary is about as well-positioned as it https://www.youtube.com/watch?v=9AbVL_jInPY&list=PLngnoZX8cAn8O7-_srINlYZFSp5NDWGjs
Views: 2495 Development That Pays
Scrum vs Kanban - The Cheat Sheet Episode
 
03:58
69. Scrum vs Kanban - The Cheat Sheet Episode // Download your FREE CHEAT SHEET: http://bit.ly/scrum-vs-kanban-cheatsheet Did you see the previous episode? Seems it was very well received: more than 3000 views in its first week. (If you missed it, you can find it here: https://www.youtube.com/watch?v=rIaz-l1Kf8w) Embarrassingly, the Cheat Sheet that went with it was awash with typos. I was inspired to create a brand new version. Hope you like it. Video credit: https://www.youtube.com/watch?v=3bO-lP4pric Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Previously... A well-received episode on the differences between Scrum and Kanban. Today... Agile Inception. And a Cheat Sheet. Scrum vs Kanban ------ Did you see the last episode It was on the subject of the Differences between Scrum and Kanban. I wouldn't be mentioning it today... but for two things: The video did rather well. Not quite "Viral", but getting there. This video came with an accompanying Cheat Sheet. Let's just say... it wasn't my best work. Inception ----- What has any of this got to do with Inception Rewind a fortnight or so, and the video and the cheat sheet on the subject of Kanban and *Scrum ... were themselves backlog items. Backlog items in what is, I suppose, a Scrum system. I publish a new video every Wednesday, so my Sprints are a week in duration and run from Wednesday to Wednesday. Two weeks ago on Wednesday, this episode joined the Sprint Backlog. And I set to work. On the Video. By Sunday, I knew I was in trouble: there was a ton of work still to do on the video - and I'd given no thought to the Cheat Sheet. Monday... no Cheat Sheet Tuesday... no Cheat Sheet. Wednesday: decision time. The easy options would have been to remove all reference to the Cheat Sheet from the video. But I was curious to see how well it would be received. Would anyone even download it I decided to go for it: The video was uploaded before I left for work. The Cheat Sheet was created - from start to finished - in my lunch break. As I said earlier, the video did quite well. As did the Cheat Sheet: so far, it's been downloaded 55 times. Which is (a) Amazing and (b) Mortifying. 55 of you have a document from me containing... spelling mistakes! (I don't usually do spelling mistakes.) At emotionally challenging times like this, I'm often comforted by Three Letter Abbreviations: I'm classifying my cheat sheet as an MVP, a Minimum Viable Product. It was was certainly minimal. It was also viable - just. And it did what every good MVP should do: it informed: The moment I saw that people were downloading it, I started work on a new version. And I've really gone to town with it. Pictures and everything. It's even got half-decent spelling! The "Unfortunate 55" have already received the upgraded version from me by email. For everyone else, you can get your copy from my blog via a link that you'll find somewhere around this video. Minimum Viable Product ------- Now, before you go and grab your copy, there's something you need to know. Don't tell anyone, but this new shiny version is also... an MVP. Less minimal and more viable that the previous one. But an MVP nonetheless. I'm already working on the next version. But this time I'm going to need your help. So when you get your copy, I would be SUPER GRATEFUL if you could come back here and let me know your thoughts: -What works What doesn't work What could be worded more clearly Thanks in advance for your help! https://www.youtube.com/watch?v=edJKu6p4LEw&list=PLngnoZX8cAn8VEVJtgWUKyidEaV-mJKKe https://www.youtube.com/watch?v=https://www.youtube.com/watch?v=C3P44ZYXTBs
Views: 4974 Development That Pays
Agile Estimating & Planning [2018] - 3 Keys to Better Estimates
 
07:56
When it comes to estimating, the odds are stacked against us. (Think: Planning Fallacy.) But we can tip the balance in our favour. Here are 3 ways. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 122. Agile Estimating & Planning [2018] - 3 Keys to Better Estimates Key #1: Get multiple estimates from different people ----- Get multiple estimates. Ideally, from different people To err is human; but we can average out the “errs” by estimating in a team. I think this makes sense intuitively: If we ask a group of 5 people to estimate the weight of a locomotive and get these results: 60 140 120 120 80 We could average them out (60 + 140 + 120 + 120 + 80)/5 = 104 Which isn’t far off. But things don’t always work out so cleanly. Now that this group is warmed up, let’s test them again: “How long does it take to get from Paris to Brussels ” (it’s a question we’ve asked before. And if you saw last week’s episode, you know that I am - quite literally - asking for trouble.) Here are the estimates: 4 hours 1 hour 2 hours 2 hours 4 days Whoa… that’s quite a range: 1 hour to 4 days! 4 days is 96 hours. That’s a range of very nearly 2 orders of magnitude. Huge! What’s wrong with these people What’s going on inside their heads Let’s take a look: The person that said 1 hour was thinking of going by aeroplane. The person that said 4 days was thinking of going by bike 4 hours: driving. 2 hours: train. Makes sense 2 hours: aeroplane. Interesting: this person has factored-in the time to get to the airport which is sits north of Paris. 5 people estimating... 5 entirely different things! Which brings us to the second key: Key #2 - Use Objective Measures ------ What if we asked them a different question: “How FAR is it from Paris to Brussels ” The results are in: 150 miles 200 miles 260 miles 180 miles 220 miles This time the answers are in board agreement: they all of the same order of magnitude. An estimate of 2,000 would be one order of magnitude different; 2 orders of magnitude would be 20,000 miles. Which will get you most of the way around the earth! If we look inside their heads... Looks like everyone’s looking at the problem in the same way: everyone is using the same basis for their estimate. It’s an OBJECTIVE measure. That’s In contrast to the SUBJECTIVE measure we started with: travel time. When we’re estimating in software development, we want to avoid “development time” - which is a SUBJECTIVE measure. Instead, we want an OBJECTIVE measure. And the unit of measure of this “objective measure” is the Story Point. Here’s a definition from Mike Cohn: “Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.” So it’s a measure of the effort required to build, test and release the Feature or story. Mike goes on to say: “Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort. That could include: The amount of work to do The complexity of the work Any risk or uncertainty in doing the work At the risk of stretching an analogy to breaking point… we could say similar things about a map. The amount of work to do… is like distance The complexity… is like the terrain - which is another thing And uncertainty or risk… Okay… now I’m struggling… areas of political unrest. Let’s move on… We’ve still one more key to get to. As we touched on last time, the originators of Story Points felt the need to bring a new unit of measure into the world because other non-time unit of measure candidates - lines of code, function count, number of commits - were too easy to fake. But they’ve given us a measure that is ABSTRACT - you can’t look up the size of a Story Point. However… the absolute size of a Story Point doesn’t matter. The reason for that is a consequence of our third and final rule. Key #3 - Use Relative estimates (if possible) ------ Sorry people; maps again! The team we started with did a pretty good job of estimating the distance from Paris to Brussels. But everyone on the the team was either from France or Belgium. And none of them have been to the USA So this time I’m going to take them right out of their comfort zone: “How far is it from San Francisco to Los Angeles ” They are going to struggle. Would it help to see a map Yes, but only if they can figure out the scale. We’re not going got get much joy out of these guys Let’s give them one last try: “The distance from San Francisco to Los Angeles is ______ the distance from San Francisco to Fresno.” Chance https://www.youtube.com/watch?v=Gxf76eGyG5c&list=PLngnoZX8cAn-9tWYxyQQPGoHW7DETBCjK
Views: 4479 Development That Pays
Work in Progress: Get a Grip on Your WIP
 
03:33
26. Work in Progress: Get a Grip on Your WIP // Limiting work in progress (WIP) is one of the cornerstones of Agile. It helps to reduce multitasking, improve feedback, and makes sure that errors are caught early. In this video we look at practical steps to help you to bring your WIP down. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe LINKS -- Jira WIP limits: https://www.atlassian.com/agile/wip-limits -- Kanban WIP for Trello WIP: https://chrome.google.com/webstore/detail/kanban-wip-for-trello/oekefjibcnongmmmmkdiofgeppfkmdii Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Limiting Work In Progress (WIP) is one of the cornerstones of Agile. When WIP is low: Multitasking goes down Feedback goes up Errors get caught sooner Today we'll look at practical steps to bring your WIP down. Back to the factory floor ----- Many of the systems we apply today in software development can trace their origins back to the factory floor. In many ways, we have it easy. If we want to change the layout of our "factory", we can do so with a white board marker. Or the click of a mouse. For example, it's easy to split a column into two columns. Splitting a machine in two. Not so easy. But the factory floor does have some advantages. When partly-processed stock builds up, it's obvious. In a factory, when you want to reduce the WIP, you could reduce the space available for WIP. Do it right, and it's a hard limit. Fill up the space here, and this machine has to be stopped. There's no if or buts. Practical steps ---- In our Agile teams, we don't have such hard physical limits. But there are couple of things we can do to keep ourselves honest. And make teams responsible for their own WIP - more on that in a moment. Impose WIP limits --- If you're using a physical board, make the columns shorter. Less space for cards. If your using Jira, set a WIP limit. If you're using Trello: as far as I know, Trello does not support WIP limits. But there is a Chrome extension that adds the capability. Distinguish between "In progress" and "waiting" ------ The first Kanban board I used in anger made a clear distinction between "waiting" and "in progress" Each column had a "buffer zone" on the left and an "in progress zone" to the right. It certainly does the job of distinguishing between waiting and in progress, but it's not perfect. Take a look at this board. There's a ton of work in the Test Team's buffer column. An un-enlightened observer might be forgiven for thinking that the Test Team is out of control. You and I know that the Test Team has done nothing wrong: it's the Dev Team that's out of control! We can make this explicit by swapping the "buffer" and "in-progress" zones. Same cards, same situation, slightly different board. But it's now obvious that it's the Dev Team has created the excess WIP. Buffer zones for Jira and Trello ---- We mentioned Jira and Trello earlier. I confess that I've only used "buffer zones" on physical boards - never on an electronic board. If you're have experience of adding buffer zones to a Jira or Trello , I'd love to hear from you. https://www.youtube.com/watch?v=p-cBY4L_y_s https://www.youtube.com/watch?v=W92wG-HW8gg
Views: 3544 Development That Pays
TDD vs BDD. Giants of Test Go Head-to-Head + FREE CHEAT SHEET
 
05:26
62. TDD vs BDD. Giants of Test Go Head-to-Head + FREE CHEAT SHEET // Grab your FREE Cheat Sheet: http://bit.ly/tdd-vs-bdd-cheatsheet Watch as Test Driven Development (TDD) and Behaviour Driven Development (BDD) square off in a gruelling 7-round bout. Will Test Driven Development win on points? Or will Behavior Driven Development land the knock-out blow? - 1:12 - ROUND 1: Focus - 2:18 - ROUND 2: Writer and Reader - 3:03 - ROUND 3: Speed of execution - 3:57 - ROUND 4: Specificity *** CORRECTION *** At 3:00 I call a round for "TDD". I should have called it for "BDD". PREVIOUS EPISODES: - TDD and BDD - https://www.youtube.com/watch?v=fsSMuqIpu_c - What is TDD? - https://www.youtube.com/watch?v=H4Hf3pji7Fw - What is BDD? - https://www.youtube.com/watch?v=VS6EEUVZGLE Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Previously.... I tried to start a motorbike That's a System Test. And a Black Box Test. It's also a Behavioural Test: a direct test of a behaviour that I - as the user of the motorbike - care about. When my Behavioural Test failed, I checked for a spark. That's a Functional Test. No spark Perhaps the battery is flat. Or the wiring is faulty. Or the spark plug has failed. Checking the sparkplug in isolation is an example of a UNIT TEST At this point, the poor old Functional Test... Got squeezed out. Leaving us with the building blocks of today's main event. In the blue corner: Test Driven Development And in the green corner: Behaviour Driven Development. Let's have a good clean fight. Welcome to Development That Pays I'm Gary Straughan Today, we continue a journey that started three episodes ago. If you missed any of them, you might want to watch them first - You'll find links somewhere around this video. Now that we've looked a TDD and BDD individually, I thought it might be useful to take a look at them side by side. This bout is scheduled for at least 7 bruising rounds. Round one: Focus ------ Test Driven development is an inside out process. It starts with a developer writing a single test.. and then write some code - just enough to get the test to pass Then another test and then write some code and so on an so forth. The tests and the code grow and develop together. They're intertwined. The testability of the code - is built in. As is the quality. Behaviour Driven Development, on the other hand, is an outside-in process. The desired BEHAVIOURS of the finished system - the things that the end user will actually experience - are described up front. And they're described by a set of Behavioural Tests. All of which can, if desired, be written before a single line of application code. When development begins, the focus is on getting the Behavioural Tests to pass And since the tests relate directly to the Behaviours that the end user will experience, the development focus is actually on delivering VALUE. If TDD is about doing the thing right, then BDD is about doing the right thing. Round 2: Writer and Reader ---- Who writes the tests For unit tests - which are written in code - the answer is clear: it's the developer For behavioural tests, the plain english test format means that the tests can be written by the person that understands the customer best: the Product Owner. Or the Product Owner and the Development Team. Flipping the coin, who is likely to read the tests For units tests, a developer. A tester at a stretch. For behavioural tests, it's almost anyone: developer, tester, product owner, business owner, stockholders. Round 3: Speed ----- Unit Testing requires that components are tested in isolation. In many case this will necessitate "faking" - or mocking - dependencies. This can be the trickiest part of unit testing. But there's an upside to testing in isolation - with our without mocked dependencies. The upside is that Unit tests tend to be super-quick to run. With Behavioural tests we're always testing the system as a whole The challenge here is putting the "putting the system into the correct state" in order to be able to run the test. Everything in the "Context" section. This setup - which may require a whole series of teardown and setup steps - has to happen before each and every test. Not particularly difficult to do. But not quick either. If a suite of Unit Tests take seconds to complete, expect the suite of Behavioural Tests for the same code base will take minutes to complete. A clear win for TDD Round 4: Specificity ---- Is that a real word We've covered this one before so I'll keep it brief. When the motorbike doesn't start, I know something is wrong. But I don't know what is wrong. When I test a spark plug in isolation - and the tes https://www.youtube.com/watch?v=4sgTIVLGPAk https://www.youtube.com/watch?v=mT8QDNNhExg
Views: 11138 Development That Pays
Agile Estimating. Why Bother? IV
 
03:52
58. Agile Estimating. Why Bother? IV // So far, it's all been very neat. Very precise. But what happens when the estimates... are wrong? → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Software Development is uncertain. (If it wasn't uncertain, then an Agile approach wouldn't be necessary.) So it's possible - indeed, it's likely - that our estimates will be wrong. This .may leave us wishing that we hadn't tried to be clever. LINKS - Part 1: https://www.youtube.com/watch?v=SCGgNdZBuXo - Part 2: https://www.youtube.com/watch?v=Djkg8pPoW1s - Part 3: https://www.youtube.com/watch?v=u3ba11IN9hg Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Previously... We stripped things right down. Right back to first principles. To see what happens if we take an item from the top of the product backlog, and get straight to work. Without Estimating. And to see happens if we do some estimating, and use that information to make more intelligent decisions about the build order. It's been all very clean. All very precise. But real life isn't like that. In the real world, estimates can be wrong. We've come a long way... --------- This is uncharted territory for me. I've never made a "Part 4". I almost brought things to close at the end of Part 3 ... but I thought it was important to cover just one more thing: what happens when estimates turn out to be wrong. Which is, of course, almost all the time. 1, 2, 3 ------ I want to put yourself in the place of the Product Owner. You've decided - perhaps unwisely - to build these three features in this order: 1, 2, 3 The development team sets to work. Time passes.... And at this point, the Development Team runs into a problem. It's going to take longer to build than originally estimated. This much longer. How do you - as Product Owner - feel about that Perhaps you're feeling that had this feature been correctly estimated at the outset you might have chosen a different feature to build first Hold that thought. We'll be coming back to this picture in a moment. 2, 3, 1 ------- In a parallel universe, you're also a Product Owner. And in this universe, you've decided to build the features in this order: 2, 3, 1 Make sense: features 2 and 3 together deliver more value that feature 1, and they can be delivered in the same time. The Dev Team sets to work. Time passes. The estimate for Feature 2 was spot on: it's delivered right on time. Ah now. It seems that things can go wrong in this universe too. The Dev Team reports that Feature 3 is going to be delayed - by about this much. Again, Take a moment to thing about how you feel about this Your big value item - Feature 1 - has just been pushed back. That's not ideal. Sunk Cost ---------- Two situations. Two delays. But which is better Are you familiar with the concept of Sunk Cost In economics, a sunk cost is any cost that has already been paid and cannot be recovered. Put it another way, we should be making decisions based on the present and the future ONLY. Easily done. I'll just rub out everything in the past. Does that change your feeling about either of the two cases In the first case, your highest value feature is also your smallest feature. Had you been planning work today, you'd have picked it for development in a heartbeat. So the fact that it's already in progress is amazingly good news! What about this case. Item 3 is a relatively low value feature. If you were planning now, there's no way you would have scheduled item 3 ahead of Item 1. Can you pick Feature 1 now Alas no. In all but exceptional cases, the I've-started-so-I've-finished Directive trumps the Sunk Cost Directive. You're committed to continue with the development of Feature 3. You'd be invoking the wrath of the agile gods to even THINK about putting it on hold. Epilogue -------- It's been a game of three halves. Building in order of value - without estimating - worked reasonably well. Adding in a touch of estimating gave us the ability to re-order the features to provide more value more quickly But real-world delays may have left us wishing that we'd hadn't tried to be clever with our ordering. https://www.youtube.com/watch?v=VS74eqc8uFQ https://www.youtube.com/watch?v=7nTxdl29ePY
Views: 1985 Development That Pays
The Eisenhower Matrix - aka The Time Management Matrix
 
07:39
The Eisenhower Matrix has the power to change your day, your week. It even has the power to change your life. The Eisenhower Matrix - aka The Time Management Matrix. Has the power to change your day, your week. It could even change your life. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 114. The Eisenhower Matrix - aka The Time Management Matrix Orthogonal ------- ORTHOGONAL. The dictionary definition is: “of or involving right angles; at right angles.” But it has a related meaning; when two things are independent, they are considered to be othogonal. There’s a second meaning: “statistically independent.” When it comes to a 2 x 2 matrices, a 2x2 matrix is orthogonal - in the sense that the axes are at right angles. But the factors that the two axes represent, are not necessarily orthogonal. The matrixes that we started with last time were a mixture. If we’re talking about food: food can be healthy; food can be delicious. The two are independent. Or a partner. A partner can be smart; a partner can be attractive. But what about this one: for a car, we might have performanceand price. But performance tends to come at a price. The two are not independent; the two are not orthogonal The Eisenhower Matrix ----- What about today’s main event, The Eisenhower Matrix Actually, it does pass the orthoganality test: If I tell you that a task is important, I’ve told you nothing about its urgency. If I tell you a task is urgent, I’ve told you nothing about its importance. Urgent and important are orthogonal. But I’m getting ahead of myself. Stephen Covey’s Time Management Matrix. ------- One or two of you mentioned that the Eisenhower Matrix reminded you of Stephen Covey’s Time Management Matrix. There’s a good reason for that: They’re one and the same! Covey gave the quadrants numbers: Quadrant 4: Not urgent, not important ----- Back in my day the classic example would be watching too much TV. The modern equivalent is surfing the web, or checking Facebook or Instagram or Snapchat every two minutes. In a word: Avoid! We’re going end up with 4 “D”s, So I’m going to swap “Avoid” for “DUMP IT!” Quadrant 3: - Urgent and NOT important ----- These are distractions and interruptions. Such as phone calls. These are things that we should DELEGATE! Which leaves us with the two quadrants we focused on last time, when we took to the high seas. Quadrant 1: Urgent AND Important ----- The boat is sinking. You gotta bail and you gotta bail now! The “D” here is “DO FIRST” Quadrant 2: Important and NOT urgent --- In our boat, it was the act of diving down to attempt to repair the hole. The act that - eventually - saved the day. “Dump”, “Delegate”, “Do first”. What exciting “D word” will we find behind this powerful quadrant Ready. Steady. “D” is for… DECIDE! Decide Really is that it Yep. that’s it. “Decide” when to do it. In other words “Schedule it”. To me, this hardly does it justice. Perhaps now you see why I dragged you off to the middle of the ocean, rather than just going through the quadrants one at a time. Because the words “Decide” and “Schedule” do little the impart the IMPORTANCE_ of this quadrant. Day… week… year ------ Remember our little chat about the orthogonal nature of theses axes The axes may be independent. But the quadrants are not. In any day… in any week… in any year, you have a fixed amount of time. Your degree of success will depend largely on how you divide your time between these four quadrants. Can we agree that it would be beneficial for you to spend as much of your time as possible on the IMPORTANT No problem: stop doing - DUMP - the not urgent and not important And find a way to DELEGATE urgent and not important That’s a great start: you’ve maximised quadrants one and two. But you’re not there yet. If you’re like most people, you’ll find the “urgent” will overshadow the “important and not urgent”. If you think about it, that’s not surprising. Quadrant 2 items require planning and scheduling. Whereas Quandrant 1 items turn up all by themselves! At the most inopportune moments! Like hitting something in the middle of the ocean that punches a hole in the boat. It isn’t perfect ----- I like the boat thing as a mental model, because it carries an important message: The secret to reducing the size of this quadrant 1 often lies in quadrant 2. But there’s something about the boat mental model that isn’t perfect: the hole in the boat was … unavoidable. And it’s true: Quadrant 1 items often are unavoidable. Like when the school calls to tell you that your child is ill, and you need to rush out of the office to go https://www.youtube.com/watch?v=DX4LStJGny4 &list=PLngnoZX8cAn8BlnmpbWevEkuc01q55NjS
Views: 5988 Development That Pays
Agile is Not Efficient; Agile is Effective. But is it Cost-effective?
 
04:09
Agile, with all its iterations, can hardly be described as efficient. Agile is NIOT efficient. What it is, is EFFECTIVE. But is it COST-effective? It's not the first time we've talked about efficiency and effectiveness in the context of Agile. It's not the first time you've heard me say that Agile isn't effective. Perhaps you were disappointed? Don't be: effectiveness trumps efficiency. And I can prove it. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 103. Agile is Not Efficient; Agile is Effective. But is it Cost-effective? Mathe-Magic ------ Today I’m going to do some mathematical magic I’m going to show you that 1 + 1 = 3. At least. Two tasks, each of similar size: each likely to take a week. To keep the maths simple, I’m going to say that each is ONE unit of work. I have two basic choices: I could work on them concurrently Or I could work on them sequentially (To the annoyance of some of you, I'm going to ignore factors such as context switching. Again, I want to keep the maths simple.) The maths we need right now is the speed of working. In the concurrent case, it’s two units of work divided by two weeks. That's a speed of 1 unit of work per week. In the sequential case, it's two units of work divided by two weeks. Also a speed of 1 unit of work per week. Hmm. I was rather hoping that a 3 might appear. Another viewpoint ------- Perhaps I need to look at this from a different angle. Perhaps I need to look at it from a different point of view: the point of view of the customer. The customer doesn't know - nor care - about how long a particular chunk of work took to do. She's only interested in - she can only see! - the value that it provides. And she can only see the value that it provides when it's complete. When it's live. The things I make provide zero value while I’m making them. And then they go live. Now the customer is able to receive the value. What's great is that the thing that took just a week or two to build will provide value for much longer than that. But I want to focus on theee three weeks. For the concurrent case, it’s two units of work in, two units of value out. I think you’ll find the second example more interesting: The first item delivers a chunk of value in week two. Item two comes on stream in week three - and its value “stacks up”. Oh look! Two units of work in. THREE units of value out. 1 + 1 = 3. But I’m just getting warmed up: More! ----- What if I have not two but ten tasks Ten units of work. If I wait until they’re all done and dusted, all of the value appears in week 11. 10 units of work in, 10 units of value out. But if I release as I go along, the picture looks very different. The value stacks up. I’ll save you the trouble of counting the squares: 10 units of work in. 55 units of value. That’s what I call cost-effective. https://www.youtube.com/watch?v=8UEPyFaXlYg&list=PLngnoZX8cAn95Z6jcaNkJUXnxBwQZBVsK
Views: 3004 Development That Pays
The Lean Startup - Build, Measure, Learn + FREE CHEAT SHEET
 
05:53
85. The Lean Startup - Build, Measure, Learn + FREE CHEAT SHEET // Grab your FREE Cheat Sheet: http://bit.ly/lean-startup-cheatsheet Last time, I laid out my Cunning Plan to combine two ideas - "The Lean Startup", and "a course of some kind" - into a collaborative experiment. Truth be told, it hasn't gone quite as I expected: which makes it far more interesting :) In today's episode, I'll introduce you to a cornerstone of "Lean": the Build Measure Learn loop. As you'll see, it's a more powerful model than it appears to be at first sight. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Previously… I asked for your help to put into action a "Cunning Plan" to create a COURSE in a LEAN way. (That’s “Lean” as in “The Lean Start-up”.) Today… I’ll bring you up to date with developments. Rather surprising developments. Build, Measure, Learn ----- If you do a Google image search for for “the Lean Startup”, you’ll find no shortage of pictures of Eric Ries’ book, “The Lean Start Up”. You'll also find this: the Lean Start-up “Build-Measure-Learn” loop. As tends to happen, there's been some Interpretation: Most versions emphasise the verbs - the doing words One or two emphasise the nouns - the things Some give them equal billing. I'm going to use this version, with the emphasis where it should be, on the “doing words”: Build, Measure, Learn If this model is new to you, take a moment to gauge your reaction to it. I know, I know. It’s stunning. Earth-shattering. Revolutionary. A game-changer. Oh. That’s not what you’re thinking Wanna know what my first thought was It’s no different to Plan, Do, Check, Act; a model that I heard about 30 years ago. But, as is often the case, there is more to this model than meets the eye. What if I told you that we’ve already fallen into TWO traps that is this model was designed to help us to avoid. 'Course of Some Kind' ------ Last time I gave you a terrifying insight into the workings of my mind: The twin ideas of “Lean” and “developing some-kind-of a course” that coalesced into the notion of developing a "Course of Some Kind" in a Lean fashion. With your help. The episode went out… and your comments started to come in. As I read them I got concerned. Many of the suggestions, were about the CONTENT of the course itself. This is the first trap. Now hear me clearly: I TOTALLY understand. Because it’s EXACTLY what I would have done. It’s what we’re programmed to do. Given an outline, we like to fill in the gaps. More than “like”: compelled! Did you just fill in a triangle People love to build ----- One of the Build Measure Learn images I found expresses this just about perfectly. It’s spot on: “People love this part!” There’s a STRONG drive to “get on and build it”. It’s a very HUMAN drive. It’s a drive that we would do well.. to RESIST! “Hold on just one minute” I can hear you say. “It Is says Build Measure Learn. And you’re giving us a hard time for wanting to build “What Are just going to magically Measure ” “Why not cut out the middle man and go straight to LEARN ! “ You raise an excellent point. As I’m sure you’ve noticed, the flow here is in a clockwise direction. Of course it is. It would be weird if it wasn’t. Anyway. It’s a flow of doing. A flow of action. What’s clear if you read the book, is that there’s also an anti-clockwise flow. It’s a flow that you’ll struggle to find in a Google Image search - although I did find one eventually. Check this out: Assumption, Metric, Experiment Notice that it’s a flow of “thinking” rather than a “doing”. A flow that comes - just case it’s not 100% obvious - before the “doing” The hidden anti-clockwise / counter-clockwise flow is, in my opinion, the key that unlocks the power of the Build Measure Learn model. Rather than speaking in the abstract, let’s apply if directly to our project - the “5 Day Mini-course”. What’s the assumption I guess it’s that people, will, you know.. like it. This is no time for woolly thinking. How about: ASSUMPTION: “The 5 Day Mini-course will help to grow my audience” Hmm… okay. Not sure that’s specific enough… but let’s see where it leads us. What’s the metric YouTube viewers YouTube subscribers maybe I’d actually like to throw the net wider than YouTube. How about email subscribers: Email opt-ins Let’s change this. “The 5 Day Mini-course will result in more email opt-ins.” And the metric is: email opt-ins. Next time ------ All we need to do now is to come up with an EXPERIMENT Which is where I fell into a second trap. I tell you all about that next time. https://www.youtube.com/watch?v=L_6xU71Q-lY&list=PLngnoZX8cAn_vCE1plk4xhTWfJfvKEWs8
Views: 2133 Development That Pays
Agile Software Development = Business + Code + PEOPLE
 
04:01
4. Agile Software Development = Business + Code + PEOPLE // Business Objectives don’t appear spontaneously, and code doesn’t write itself: we’re going to need some PEOPLE. AND we’re going to need them to work together EFFECTIVELY. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe LINKS -- Episode 1: https://www.youtube.com/watch?v=JkVr2DJM3Ac -- Episode 2: https://www.youtube.com/watch?v=8Yx7zF7kjs8 -- Episode 3: https://www.youtube.com/watch?v=om0_KvdaJTg Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Hi this is Gary Welcome back to Development That Pays. In Episode 2 we talked about the importance of business objectives: how it’s more important to satisfy real business goals than to craft beautiful code. Then in episode 3, we talked the importance of code itself: how we can’t know for sure that our business objectives are sound without first writing some code. Unfortunately - or fortunately, depending upon your viewpoint, we don’t have a business objectives picking machine and we don’t have a code generating machine. If we did, we could plug them in and watch super-profitable software pop out of the other side. No, we’ve going to need some people. So let me introduce you to a couple of friends of mine: Business Bob and Development Dave Business Bob is the product owner. In our walls and ladders model, Bob has responsibility for picking walls. Development Dave is the Lead Developer. Dave has responsibility for stacking boxes… building ladders… and building staircases. Roughly speaking, Bob decides what to build… and Dave (together with his dev team) builds it. The quality - and profitability - of the software that Bob and Dave produce… depends on how well they do their individual jobs. It also depends - to a surprisingly large extent - on how well they work TOGETHER. It’s been my experience that the Bobs and Daves of this world don’t work well together, at least not as well as they might. To illustrate this, let’s look at what happens when they DON'T work together. Bob has an idea for a new feature - "Feature X”. He’s spec’ed it out in detail, and hands it over to Dave Dave and his team set to work. After 4 long weeks, it’s complete and it goes live. Only then does Bob see the awful truth. Feature X is a failure. Dave, as you can imagine, is furious. A month’s work down the drain. It’s not a happy ending. Let’s play out this story again. Bob has an idea for a new feature - "Feature X”. Dave comes up with a “minimal” version of X - let’s call it “little x” It takes just 2 days for Dave and his team to get "little x" live. Bob can see straight away that “little x” isn’t really working. So he suggests a change. Dave doesn’t have a problem making the change: after all, “little" x only took a couple of days to build The next day, “little y” is live. The initial results are promising. Dave has an idea for an improvement. Bob likes the sound of it. It’s live the next day. And so it goes on, with Bob and Dave working together to refine the feature, one small step at a time. Bringing this story to very happy ending. Okay - we don’t need Bob and Dave to fall madly in love. But I hope you get the point. Talk to you next time. https://www.youtube.com/watch?v=dP1imJeAwt8 https://www.youtube.com/watch?v=-zDct5d2smY
Views: 1909 Development That Pays
Sh!t Software Developers Say: "We Need More Tests!"
 
03:52
22. Sh!t Software Developers Say: "We Need More Tests!" // Grab your FREE TDD vs BDD Cheat Sheet: http://bit.ly/2lvse8U Team falls foul of nasty bug. Team spends frustrating week tracking it down. Team calls timeout: "We Need More Tests!" Your Development Team have asked you if they can stop development for two weeks to write some tests. The decision is yours. What will you decide? This is the tale of TWO software development teams: - In one case, the team was given permission to take a fortnight to stop development and write tests. - In the other case, permission was REFUSED. In BOTH cases, the decision was... WRONG! Watch the video to find out why. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Your Software Development Team has had a rough time of it. They've spent the best part of a week tracking down a nasty bug. And now they are feeling exposed. They want to stop developing. They want to s start writing tests. They reckon it will take at least a fortnight. The decision is yours. What do you say. Yes. Or No Not just hypothetical ------ This isn't just a hypothetical question. I've been part of not one but two teams that said "enough is a enough", and asked for the time and space to put things right. One team got a Yes. The other team got a No. BOTH decisions were, in my view, wrong. The Art of Motorcycle Maintenance -------- This is the motorbike I owned as a teenager. Is wasn't the most reliable machine. It seemed I spent about as much time fixing it as riding it. I had one key test that I'd do every time I came to ride it. I'd try to start it. I'd then go on to test... Come to think about it: that was about all I'd test. UNLESS it didn't start. Then I'd do other test: I might remove the spark plug and check that t I was getting a spark. If the spark didn't look very healthy, I might check the spark plug gap. Unit Tests ---- Checking the spark plug gap is a great example of a Unit Test. It's a test of an individual component of a complex system. Like all good unit tests, it's independent of the rest of the system. (After all, the gap between here and here [the spark plug electrode gap] doesn't depend on anything else.) System Test --- Compare that with the test of "starting the motorbike". A running engine requires a huge number of components including the spark plug - to work together to produce a result. The result being a running engine. It's a great example of a "System Test". It could also be described as a Behavioural Test. A running engine is one of the behaviours that the "User" of a motorbike expects it to exhibit. It could also be described as a Blackbox Test: we didn't have to gain access to the innards of the engine to perform the test. Indeed, we didn't have to know anything a bout the inner working of the motorbike to perform it. All we need to know are (1) the inputs that need to be supplied.... fuel on neutral gear little bit of throttle operate the kick starter ..and (2) the output to look out for: the sound of the running engine. Functional Tests ----- Note that the very first test I mentioned - unscrewing the spark plug to check that I was getting a spark - is neither a Unit Test... ... nor it a System Test / Behavioural Test / Black Box Test. It falls somewhere between the two camps. Because I've unscrewed something, it's no longer a System Test (a test of the system as a whole). Nor can it be described as a Black Box Test. (We've "entered" the black box.) It's an example of a Functional Test: the expected "function" being the production of a spark. As a test it's slightly unsatisfactory: A pass doesn't indicate that the engine will start. A fail doesn't indicate the root cause of the problem. So a pass would lead us on to a System Test / Behavioural Test / Black Box Test. A fail would lead us to a (series of) Unit Test. Back to the Teams ---- I still haven't told you about the two teams - the teams where one team got permission to write tests and the other didn't I'll reveal all in the next episode. But I will give you a big clue. One team asked to write Unit Tests The other team asked to write Behavioural Tests. Talk to you next time. https://www.youtube.com/watch?v=jrus212djPs https://www.youtube.com/watch?v=dWayn0QsJr8
Views: 4143 Development That Pays
Software Development: a Source of Frustration?
 
02:20
1. Software Development: a Source of Frustration? // I've been lucky enough to work with the software development teams of some amazing companies. But too often I found that the software development process was... broken. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Chief among the causes: - Building things that somehow... miss the mark - Building the right things... but taking too long about it. If either - or both - of these things are true of software development in your organisation, you won't need me to tell you that it's incredibly frustrating. Not just for you, but for everyone involved. It's time to change the record. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Are you a Lead Developer Or a Product Owner Or a Business Owner If so, I have question for you: Is your software development function a well-oiled machine Or is it... ever so slightly... dysfunctional Hi. My name is Gary Straughan. I've been lucky enough to work with the software development teams of some amazing companies But too often I found that the software development process was... broken :( Chief among the causes: Building things that somehow... miss the mark Building the right things... but taking too long about it. If either - or both - of these things are true of software development in your organisation, you won't need me to tell you that it's incredibly frustrating. Not just for you, but for everyone involved. It's time to change the record. I don't pretend to have all the answers, but there are a couple of key themes: Do the thing RIGHT Do the right THING Doing the thing right is about helping the entire team - Developers, Lead Developer, Product Owner, and Business Owner to pull in the same direction, so that the whole software development process is aligned. Aligned around what aligned around doing the right thing! Creating software that is useful Creating software that fulfils a real customer need Creating software that is profitable That's what 'Development that Pays' is all about. Every week - in 5 minutes or less - we'll dive into some aspect of software development. Not the technicalities of writing code, but the practicalities of what it takes for teams to create profitable software. If you've ever wondered how things are done at Sainsbury's The Economist or BBC Worldwide you won't want to miss an episode. Click the big red button and I'll get a new episode to you every Wednesday. Already in the pipeline are episodes on Recruiting Training Software Testing Some gentle Finance even a spot of Agile All designed to help you and your team to do the right THING and to do the thing RIGHT Click the big red button, and I look forward to seeing you on the other side. https://www.youtube.com/watch?v=JkVr2DJM3Ac https://www.youtube.com/watch?v=-zDct5d2smY
Views: 3271 Development That Pays
Scrum vs Kanban - Two Agile Teams Go Head-to-Head + FREE CHEAT SHEET
 
17:17
This is the tale of two Agile teams. It wasn't just an organisational separation: it was an AGILE separation. Download your FREE CHEAT SHEET: http://bit.ly/scrum-vs-kanban-cheatsheet This is a story of Two Agile Teams. More correctly, it’s the tale of one Agile Team that split into two Agile Teams. What makes the story interesting is that it was more than just an organisational separation. It was an Agile separation: - One team continued as before - with *Scrum* - The other team dropped Scrum in favour of *Kanban* Will it all end in tears? → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 100. Scrum vs Kanban - Two Agile Teams Go Head-to-Head + FREE CHEAT SHEET This is a Tale of Two Agile Teams. More correctly, it’s the tale of one Agile Team that split into two Agile Teams. It was more than an organisational separation. It was an Agile separation. Act One It was 2012 when I first walked into the offices of the BBC. The same time and the building as these guys… Never saw them. Which is strange. The software team I joined was one, I was told, that 'did Agile'. At the time, I knew very little about 'Agile'. But I could see from the get go that they weren’t doing it by halves. There’d clearly been lots of training. They had all kinds of tools. They were doing all kinds of 'rituals'. We’ll get into the specifics of how the team worked in a minute. The Split ----- Fast forward a year and the department reorganised. My team was split in two. Although reporting lines changed, the seating plan didn’t. There was one outward indication of change: where there had been one agile board, there were now two. Oh, and we did two stand-ups every day: ours at 10:00am, theirs at 10:15. A New Flavour ------- Ever-observant, it took me a couple of weeks to notice that the other team was doing a different 'flavour' of Agile. I hadn’t realised that there was more than one flavour of Agile! What my team was doing was, called Scrum. The other team was doing something called Kanban. Kanban Really This was a word I knew from way back. But I knew it in the context of manufacturing. I couldn’t immediately see how it applied to the process used by my (former) teammates. So I went to talk to the Lead Developer of 'Team Kanban'. 'What the difference between Scrum and Kanban ' I asked He was ready with an immediate answer: 'You Guys Talk About Work. We Do Work.' Ouch! in that moment, I learned an important lesson about Agile: it can be an emotive issue. Beliefs can be deep-seated. The Team Kanban Lead Dev clearly thought that Kanban was better than Scrum. I held… the opposite view. My view was both strongly held… and completely without evidential foundation. Natural Experiment ---- I’m a little older now. And, I hope, a little wiser. I can now see that the team split was a perfect Natural Experiment. You know the kind of thing: “Take two identical twins. Separate them at birth. Feed one Scrum. Feed the other Kanban. Observe the result.” So I hope you’ll join me on a little forensic investigation, starting with a 20,000 view of each team's processes. Team Scrum ----- My team - let’s call it "Team Scrum" - worked in two-week Sprints. At the beginning of s Sprint, we’d take ourselves off to a quiet part of the building for a Sprint Planning session. The Product Owner would select items from the backlog, and we’d play “Planning Poker” to estimate the size each item. We’d continue until we had roughly one “Sprint’s worth” of cards. Sprint Planning over, each developer would pick up a card and set to work Every morning there’d be a Stand-up - aka a Daily Scrum - 10 am on the dot. And so it would go on day after day, with the cards gradually making their way across the board. By the about the Tuesday of the second week, we’d expect all of the cards to have moved at least one step. It was then a race - a "sprint" - to get everything tested and ready for release on Friday. We didn’t always succeed in getting everything across the board: any item that failed to make it would be “recycled” into the next Sprint. On the Friday morning, everything in the release column would be packaged for release. Oh, and one last thing to round out the Sprint: a Retrospective: a chance for the team to get together to reflect on what well, to discuss what could be improved, and to commit to one or two action items for the following Sprint. Taking stock of the evidence: There’s a Product Backlog, the Agile Board, and a Done Pile. There’s a two-week Sprint with a Sprint Planning session at the beginning. Each day after that, a Daily Scrum Meeting - aka a Daily Stand-up. At the end of the process, all those cards that https://www.youtube.com/watch?v=HNd1_irOL5k
Views: 12213 Development That Pays
The Product Owner Is Not The Problem II
 
04:57
46. The Product Owner Is Not The Problem II // The relationship between team members is important. But which relationships are the MOST important? Those between the individual Developers? Those between the Lead Developer and the Developers? Or is the most important relationship... somewhere else? → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Last time, we talked a lot about step-changes, boundaries and discontinuities. This time, we'll look at a specific team and the quality of their relationships. Question: are all of the relationships equally important, or are some more important that others? I'd be interested to know which relationship YOU consider to be the most important. Here are some options: - Developer to Developer? - Lead Developer to Developer? - Business Owner to Lead Developer? - Business Owner to Product Owner? - Product Owner to Lead Developer? LINKS - Part 1: https://www.youtube.com/watch?v=0z5ExmD4fM0 Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Recap --- Last time... Light passed from air to glass. Some was reflected. Not all of the light made it through An electrical signal passed from one electronic component to another. Some was reflected. Not all of the signal made it through. This time... A "signal" will pass between a Product Owner and a Lead Developer. How much will be reflected How much will make it through And welcome back to the second part of our investigation into step changes and boundaries. All this talk of light passing through glass and signals passing through electronic components was all about making two points: Step changes , boundaries, discontinuities - call them what you will - are everywhere. They are everywhere in nature. So we shouldn't be surprised to find them alive and well in our teams. Whenever there is a step change, you can expect reflections. You can expect that not all of the signal will get through. You can expect... issues. My team --- Let's bring these guys back Rather then talk in generalities, I'll talk specifics. The specifics of the team I had in mind when I first drew this sketch. Let's start with the developers. These two got on reasonably well. Not much of a step change between them. I'll use this symbol to indicate the (small) step change between them. These two had a tougher time getting along. I'll indicate that with s bigger version of the symbol. And these two: not great... but not bad either. On to the Lead Developer. This guy had many superpowers, but perhaps most impressive was his ability to get on well with every member of his team. Very little in the way of a step change between him and the members of his team. The Business Owner and the Lead Developer had their moments. Nothing too terrible or dramatic. But enough to merit a symbol of about this size. The Business Owner and the Product Owner had worked with each other for a very long time, so the had a very good working relationship. What about the relationship between The Product Owner and the Lead Developer You'll be shocked to learn that it was not good. Really not good. Shocker --- This picture shocked me. I'd gone looking for problems here [the Development Team] ... and found them here [the Business Owner/Product Owner/Lead Developer triangle]. Not what I'd expected. At this point I felt I'd discovered something profound. But the cynical side of brain wouldn't let me celebrate: it popped up with the "SO WHAT " question. Do the "discontinuities" between these people actually matter Are they a big deal My partial answer is that I think that some relationships matter more than others. So let's talk about importance. Starting with theses guys [the Developers]. It's great if they get on. And it's crucial that they get on if they are, for example, pair programming. Let's say ...medium importance. I'll indicate the importance with this smallish symbol Next up, the relationship between the lead developer and the the individual developers. These are relationships that are more important. Which brings us to the relationships between these three players [Business Owner/Product Owner/Lead Developer] For my money, the relationship between the Product Owner and the Lead Developer is the big one. The communication must be of a high quality - with a minimum of "reflection". Not just from the the product owner to the lead developer, but also from the lead developer to the product owner. Last but by no means least are the relationships between the Business Owner and the Product Owner and Lead Developer respectively. These are tricker to pin down. I've seen more than one team where the pro https://www.youtube.com/watch?v=IVDW-2lFidM https://www.youtube.com/watch?v=502ILHjX9EE
Views: 2553 Development That Pays
The Eisenhower Matrix: Untangling Urgent and Important
 
06:59
The Eisenhower Matrix might just be the most powerful thing I’ve learned. I bet you've seen it before. But did you get it? Did you REALLY get it? The Eisenhower Matrix might just be the most powerful thing I’ve ever learned. The chances that you’ve come across if before. But did you get it? I mean *really* get it? There’s real power here. Power you may have overlooked. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe ------------------- 113. The Eisenhower Matrix: Untangling Urgent and Important Today I’m going to talk to you about a 2x2 matrix. But this is no ordinary matrix. This is the Eisenhower Matrix. Is it applicable to Agile Yes it is! Is it applicable to Lean Yes it is! And does it have the power to change your life I think it does. The world of the 2x2 Matrix --- This is a two by two matrix. I’m sure you know how they work. If we’re talking about a car, the axes might be performance and fuel economy We’d like it to fast; we’d like it to be economical. We’d really like it to be fast and economical. Or a partner. We’d like a partner that’s smart; we’d like a partner that’s attractive. But we’d really like a partner that’s smart and attractive. Or food. We like food that’s delicious; we like food that’s healthy. But food that’s delicious and healthy: that’s got to be good. Same old same old --- It’s always the same: This square - this quadrant at the bottom left - is to be avoided. These two are good. But this one, here at the top right: that’s where the real power lies. The Eisenhower Matrix ----- What about this one: urgent and important. (The context being the things on your to-do list.) No-brainer: urgent and important! Right Wrong! This matrix is a version of ( - I’ll say more about that later) the Eisenhower Matrix. That’s Eisenhower as in US President Dwight D Eisenhower. Mental model ----- Now, we could go through the matrix quadrant by quadrant. And I’m sure you’d get it at an intellectual level. But I want you to get it at a deeper level. I want to burn this thing into your skull. Imagine you’re on a boat. You look out across the ocean onto a beautiful sunset. And you think to yourself that life doesn’t get better than this. Suddenly, there’s a loud bang. What the heck was that ! Whatever it was it’s damaged the hull. The boat is taking on water. Without a moment’s hesitation, you start to bail. As if you life depended on it. (Because, you know, it kinda does.) Bailing ---- Freeze it there. This act of bailing; where do you think it falls on this matrix Is it important Yes: if you don’t do it, the boat sinks. Is it urgent Could you, for example, put it off until tomorrow No! You have to do it now! It’s clear: bailing the water out of the sinking “ship” is urgent and important. Slap bang in this quadrant. So you keep bailing. But after 15 minutes, it’s clear that you’re not getting anywhere: the level of water isn’t getting any higher… but it isn’t getting any lower either. There must be something else you could do. You need to repair the hole. Repairing ----- Where does repairing the hole fit into this matrix I hope I don’t have to convince you that it’s important. Without a repair, this boat doesn’t have much a future. And neither do you! Is it urgent Actually, you could put it off. You could continue to bail. Forever :) Repairing the boat is important, but it it’s not urgent. At least not when compared with bailing. It lives in this quadrant. You’re caught in an excruciating conflict between these two quadrants: You’d love to be able to repair the hole… but if you stop bailing, bad things will happen. The important thing if being held to ransom by the important important-and-urgent thing. Salvation ----- Then you realise what you must do: with a super-human effort, you bail at double speed. Then you attempt to repair the hole. You manage to effect a partial repair. But the water level reaches a dangerous level: you’re forced to return to bailing. With the hole partially closed, you’re able - eventually - to take a break from bailing, and return to the important task of repairing the hole. And so it goes on until the repair is complete. Important-and-not-urgent ---- Interesting, isn’t it The important-and-not-urgent task was the cure - the antidote - for the important-and-urgent task. The most powerful quadrant turns out to be this one. Redrawing the matrix ---- If you’ve come across the Eisenhower Matrix before, you’ll know that it’s usually drawn with the Urgent axis reversed. Which has the merit of putting the most powerful quadrant top right. It’s in this quadrant that the big stuff happens: the major transformations; the huge leaps for https://www.youtube.com/watch?v=u_cdLRc_Hos
Views: 4176 Development That Pays
Minimum Viable Product FAIL!!!
 
02:59
51. Minimum Viable Product FAIL!!! // There are some amazing MVP examples out there. Alas, this isn't one of them! When I made this cup holder, I told myself is was a Minimum Viable Product (MVP). Now I'm not so sure. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Let's break it down: 1. Is it a PRODUCT? It is in the sense that it was produced for a specific end user (Me!) And it's more than a prototype: it's been primed and painted and varnished. 2. Is it MINIMAL? Not really. This part is made of oak. If you know your timbers, you'll know that oak is a hardwood. Hardwood means that it's (a) expensive and (b) difficult to work. 3. Is is VIABLE? It's not terrible. It's easy to "park" a cup. And it holds the cup securely. But it has problems: difficult to pick up without spilling; no dust protection. Here's the thing: I could have discovered these shortcomings without making a not-so-minimal not-so-viable MVP. A quick and dirty PROTOTYPE would have done the trick. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Minimum viable Products. There are some great examples out there. but today we're going to look at a really bad one. Hi this is Gary Welcome to Development That Pays I like to think that I know a fair bit about working in an AGILE way. I even know a little bit about working in a LEAN fashion. But I don't always DO what I KNOW. And today I want to show you a perfect example of me NOT doing what I KNOW. It's in my shed. And that's where we'll be heading... just as soon as I've made a nice cup of tea. All done. Let's go. Here we are. Not as untidy as usual - I must have been expecting you ;) Just pop my tea here. It's actually this cup holder that I've brought you to see. When I made it, I told myself is was an MVP. Now I'm not so sure. Let's break it down. Is it a PRODUCT It is in the sense that it was produced for a specific end user (Me!) And it's more than a prototype: this back panel has been primed and painted. And this bit has been varnished. That's more work than I would ever do for a prototype. What about Minimal Not really. This part is made of oak. If you know your timbers, you'll know that oak is a hardwood. Hardwood means that it's expensive. It has maans that it's hard - difficult - to work. This part here is angled. I don't have a power tool to do this - it had to be shaped by hand. And I can tell you it took ages. Finally, is is VIABLE It's not terrible. It's easy to "park" a cup. And it holds the cup securely. (Shame this is the only cup it works for.) There are a couple of things there are less than ideal: If I'm not careful and I jam my cup in too hard, when i pick it up the whole thing comes off. There's then a danger that I spill my tea, perish the thought! The second issue is to do with the environment. I work with wood. And power tools. That means sawdust. Lots of it. It goes everywhere, including into my tea. A holder with some sort of cover would have been a good idea. Here's the thing: I could have discovered these shortcomings without my not-so-minimal not-so-viable MVP. A quick and dirty PROTOTYPE would have done the trick. Thank you very much for watching If you enjoyed this episode please give it a thumbs up. if you hated it, give it a thumbs down - that's good too. If you'd like more videos like this, there's a new episode of Development That Pays each and every Wednesday. Click the big red button... and I'll see you on the other side. https://www.youtube.com/watch?v=VOjU3-veCVY https://www.youtube.com/watch?v=xxjbxk8dUqI
Views: 3269 Development That Pays
Daily Stand-up - 35 Rules For Stand-up Success - FREE DOWNLOAD
 
02:42
A curated collection of rules and inspiration for successful Daily Stand-up - from the viewers of Development That Pays. Grab your FREE copy of Daily Stand-up Words of Wisdom: http://www.developmentthatpays.com/cheatsheets/daily-standup-wisdom A couple of episodes ago, I laid out my rules for effective Daily Stand-up. And then I asked you for YOUR rules for daily standup. I was blown away by the quantity and the quality of your responses. They were too good to languish in the comments section: they needed to be elevated. they needed to be immortalised! I've collected then into a single document: Daily Stand-up Words of Wisdom. Download your copy using the link above. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 ------------------- 73. Daily Stand-up - 35 Rules For Stand-up Success - FREE DOWNLOAD Previously... I laid out my rules for effective daily stand-up And then I asked you for YOUR rules for daily stand-up. And boy did you deliver. Your rules were too good to languish in the comments section. They needed to be elevated. They needed to be... immortalised! Change of plan ---- This is NOT the episode I'd planned for today. I'd planned to go into detail on one aspect of daily stand up, based on your comments. And that was the problem: so many great comments. So many great ideas. After half-writing three scripts - Or should that be: writing three half-scripts - I realised I was missing the wood for the trees. The real value here is in the collection itself. So here's what I did: I grabbed your comments Pasted them into a document Grouped similar comments together And tidied it up into a rather nice PDF. I've called it Daily Stand-up Words of Wisdom. It's an absolute gold mine one of solid tips and inspiration. And it's yours to download today. You'll find notes on: The benefits of standing up The need to follow a system - whether your into "Yesterday Today Blockers" or "Walking the Board" The desire to keep it short - together with some very practical suggestions on how to "keep it short" There are notes on: respect and on the need to keep it varied and fun. All in all there are 35 comments in the document. Three items of housekeeping. Housekeeping item No. 1 ---- You're going to want to grab your copy of Stand-up Words of Wisdom. You'll find a link somewhere around this video. Housekeeping item No. 2 ---- In putting together Daily Stand-up Words of Wisdom, I tried to curate rather than edit. I can say that I agree with most of the comments - but certainly not all of them. And that's fine. Housekeeping item No. 3 ----- The document isn't finished. I plan to keep adding to it over time. So chime in. Leave me your top tips in the comments below. I'll add them to the document and send out updates from time to time. https://www.youtube.com/watch?v=_W-J6CMAVN0&list=PLngnoZX8cAn8NZIjKCfWOP3FaBTD6RcNN https://www.youtube.com/watch?v=q_R9wQY4G5I
Views: 2904 Development That Pays
Most Training FAILS. Here's Why.
 
03:43
11. Most Training FAILS. Here's Why. // When we provide or receive training, we expect performance to improve. But is that a reasonable expectation? (SPOILER: No. It isn't.) Unless the training is trivial, performance is GUARANTEED to go down in the short term. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe The problem, then, it not that the performance decreases in the short term: it's that we don't expect it to decrease. Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Have you ever had golf lessons Or tennis lessons If so, I have a question for you: Did your performance improve Or did it get worse Hi this is Gary, welcome to Development that Pays. Years ago, I read something about TRAINING, the truth of which hit me like a thunderbolt. I haven’t been able to find the original reference, but the gist of it was this: “Most training fails because… we expect an improvement in performance." Let me adjust this slightly: “Most training fails because… we expect an IMMEDIATE improvement in performance." Do you know this fellow I know nothing about sport, but I understand this guy is handy with a stick. What if you met him in a bar and he told you - in strictest confidence - that he was unhappy with his performance… and was going to be working with someone ”re-invent" his swing. Would you bet on him to win his next tournament I certainly wouldn’t. Rory’s swing is engrained. It’s a habit. It’s deep in his muscle memory. Shifting that habit to “install” a new swing is going to be hard work. It's not going to happen overnight. The thing is, Rory knows this. His manager knows this. His trainer knows this. They all know the swing is going to get worse before it gets better. So much for the world of sport. What about the world of work Dean is out of the office for two days on a course of some kind. Dean’s boss - let’s call him Mr Manager - is looking forward to Dean getting back. Wouldn’t you know it, it’s been a busy couple of days while he’s been away. Dean is back in on the Wednesday. Mr Manager is expecting great things from Dean Dean may also be expecting great things from himself. But things are about to unravel. Here’s a graph of Dean’s performance over time. The level of performance is more or less flat … up until the training course. His performance then DROPS as he attempts to break one habit and starts to install another. What we hope for for Dean is that he sticks with it long enough for his performance to “break through” his previous performance level. But it might be days or even weeks before he reaches this breakthrough point. Right now - at 11:30 on his first morning back: His expected performance is here His actual performance is way down here. He’s struggling under the weight of a huge a backlog of work. It’s not hard to predict what’s going to happen. The fastest way for Dean to close this gap is to go back to the way he did things before. The moment he decides to revert to the old way of doing things, that’s the moment when the training failed. Two things I think we can take from this: Number one: when you’re learning something new, be patient with yourself. Realise that your performance will get worse before it gets better. And number two: when you send someone else "to be trained”, realise that the you might be the one that makes the difference between training that succeeds and training that fails. As a minimum, give the person TIME to complete this journey. Ideally, provide support - dare I say it, COACHING - throughout the “danger zone”. Talk to you next time. https://www.youtube.com/watch?v=vD_mGFnpWZg https://www.youtube.com/watch?v=IgXte39G9_g
Views: 1986 Development That Pays
Is Agile More Profitable Than Waterfall?
 
07:32
32. Is Agile More Profitable Than Waterfall? // Follow the money and you'll see that Agile has a massive head-start over Waterfall when it comes to profitability. Don't worry! There are no complex equations or boring spreadsheets to wade through. I've gone out of my way to make it as interesting and exciting - yes, exciting! - as possible. → SUBSCRIBE for a NEW EPISODE every WEDNESDAY: http://www.DevelopmentThatPays.com/-/subscribe 0:26 - Present Value (PV) 2:13 - Net Present Value (NPV) 2:50 - Timing of Cash Flows 4:00 - How to maximise profit 4:12 - Waterfall 4:50 - Agile 5:23 - Waterfall vs. Agile RELATED VIDEOS - Present Value (PV) - https://www.youtube.com/watch?v=j0PeW1MsyEM - Net Present Value (NPV) - https://www.youtube.com/watch?v=ektsXQkc7Og - Discount Rate - https://www.youtube.com/watch?v=3iLenVuXAgM - Internal Rate of Return - IRR - https://www.youtube.com/watch?v=REexsZE4mJo Music: 260809 Funky Nurykabe: ccmixter.org/files/jlbrock44/29186 Warning. In the next few minutes you'll see graphic images of finance and accounting concepts. Please don't be alarmed. There will be no equations. And no spreadsheets. Some viewers may shocked to find that the concepts presented are... rather awesome. If that is the case for you, support resources will be presented at the end of this video. The Time Value of Money --------- Money now is worth more than money later. Everything we'll look at today stems from this single principle. If in was to give you £12,000... Would you rather have it now Or a year from now I'm sure you'd prefer to have it now. The "Money now is worth more than money later" thing is, for most people, intuitive. We even have a saying for it: "A bird in the hand is worth two in the bush." Apples and oranges ------ What if I offer you £10,000 now OR £12,000 later. Which would you prefer I'm sure you'd say that that depends on what I mean by "later". If "later" if tomorrow... You'd wait for the £12k If "later" is 50 years from now... You'd take the £10k now. But what if "later" is 6 months Or 18 months That's far from clear-cut. The difficulty is this: We need to be able to compare a present value - the £10,000. With a future value - the £12,000. These are two different things. And as any schoolboy will tell you, you can't compare apples and oranges. We need to be comparing apples and apples. A present value with a present value. Luckily, there's a way to do exactly this. Present Value --- Finance types talk about discounting future cash flows down to their present value. It's something that can be calculated. Here's how the value of the £12k payment various over time: The further we travel into the future, the less it's worth. Each of these bars moves us a year into the the future. By the time we get 20 years into the future, £12,000 is worth... hardly anything at all. If we do the same thing, but taking small steps... each of these bars represents a month - ... then at a certain point the the PRESENT value of £12k drops below £10k. Multiple Payments --- We can apply the same approach to multiple payments. Here we have four quarterly payments of £3k. We already know that adding up the £3k's would be a case of mixing... oranges, bananas, blueberries and plums What wee need to do is DISCOUNT each of the payments down to their PRESENT values. once that's done, we have values that can be compared - and totalled. This total is known as the Net Present Value. NVP for short. Hold on a second... ---- I know what you're thinking. These pretty graphs are all very well... But what about the whole Agile / Waterfall thing Let's see. Agile and Waterfall are projects... and projects involve expenses... and income*. Income and Expenses ----- Let's start with a super-contrived example of a project: It has expenses of: £10,000 a month for 6 months. At that point, the product is launched and the money starts pouring in: £10,000 a month for the following 6 months. £60k out. £60k in. Break even Not so fast: we need to do a spot of discounting. There's now more RED than green. This project has a negative Net Present Value. That's not a good thing. If we could magically switch this around... so that the income came before the expenses... This time, discounting works in our favour. There's more green than red. The net present value this time is positive. The Timing of Cash Flows ------- Interesting isn't it The only thing that changed was the TIMING of the cash flows. That - and that ALONE - made the difference between loss and profit. There's something else that I'd like you to take from this. To MAXIMISE profit: Get you income in as early as possible Delay your payments as lo https://www.youtube.com/watch?v=8i2YY4a_jPg https://www.youtube.com/watch?v=_U7Py7W-Qng
Views: 2367 Development That Pays

Legal investigator cover letter
Medical records clerk cover letter example
Civil service essay writing
24 hour fitness jobs application
I am writing to complain about the service you