Created with Sketch.
The Burn Up - Agile Software Delivery
34 minutes | 8 months ago
EP24: Learnings from the Space Industry – Part 2 of 2 – The Challenger Disaster and on
This episode is a follow-on from our previous episode about the Apollo space program. Marcel and Todd talk about the failures surrounding the Challenger Disaster as a cautionary tail for today’s leaders to consider to avoid the same pitfalls. Please listen to “The Challenger Disaster: You’re wrong about – The Challenger Disaster” – 3rd Jan 2019 by Sarah Marshall and Michael Hobbes for full context. Please also listen to part 1 of this series. The following topics are covered: The impact the challenger disaster had on NASA and our recollection of eventsThe findings of the rogers commissionImportance of listening to expertisePreventing a silo effect, where the procedures put in place box in taking logical actionDesigning for safety and understanding safe parameters, risk and probabilityThe importance of communication unfiltered by middle managersFindings of the house of representatives committee reportDian Vaughn’s (sociologist) 1996 analysis of the disasterGovernment contracting and its role in the disasterHigh turnover at NASA and its role in the disasterA discussion about SpaceX and how they are approaching spaceship development is a more Agile way We hope you enjoy this episode. As always please feel free to give us feedback and share. Background info you may find interesting The podcast we are referring to: You’re wrong about – The Challenger Disaster – 3rd Jan 2019 by Sarah Marshall and Michael Hobbes Challenger Disaster footage with radio loop: Challenger disaster radio communication transcript Rogers Commission report Richard Feynman at commission hearing demonstrates the o-ring issues: House of representatives report (PDF) Controversial Edward Tuft diagram analysis https://www.researchgate.net/publication/11520001_Representation_and_Misrepresentation_Tufte_and_the_Morton_Thiokol_Engineers_on_the_Challenger Dian Vaughn’s (sociologist) 1996 analysis of all 200k documents (by then the incident is a full fledged field of research, most based only on the exec summaries).
31 minutes | 8 months ago
EP23: Learnings from the Space Industry – Part 1/2 – Apollo 11
In this episode Marcel and Todd talk about management lessons learned during the Apollo era space program and how they can still apply in today’s management environment. The following topics are covered: The legacy of the Apollo era managementThe importance of a clear goal from the topHaving sufficient resources to achieve your goalsUsing a Systems thinking approachConfiguration managementEnsuring optimum solutions can winDesigning for simplicity and redundancyTesting under realistic conditionsThe importance of what-if thinking and mentalityTeam accountability and trustLuck For full context you may want to watch the “Management Lessons of the Moon” by Andrew Chaikin YouTube video before listening to the podcast. We hope you enjoyed this episode. As always please feel free to give us feedback and share. Background and other related interesting stuff Discussion on Apollo 11: Management Lessons of the Moon by Andrew Chaikin: https://www.youtube.com/watch?v=RaskWhy5pYE The Challenger Disaster: You’re wrong about – The Challenger Disaster – 3rd Jan 2019 by Sarah Marshall and Michael Hobbes: https://podcasts.apple.com/us/podcast/the-challenger-disaster/id1380008439?i=1000465289942 Other, material of interest Apollo 1 fire radio transmission (be warned, it’s not a comfortable file to listen to): https://www.youtube.com/watch?v=274lQSbpkRg Highly Recommended! Epic Apollo 11 documentary made solely of original material on Netflix: https://www.netflix.com/gb/title/81078076
28 minutes | 8 months ago
Ep22: Remote Interviewing
We strongly believe that organisations with a successful future are those that embrace remote working practices. Not only does this address some of the challenges posed by the current Covid-19 crisis, but overall, allows organisations tap into a wider talent pool, work with a wider client base and most importantly make for better work life balance. In this episode we discuss remote interviewing with 6 super interesting guests…. We have recently co-written a blog-post on remote interviewing and my business partners at Equal Experts have extensively discussed remote working practices in their free remote working playbook. But writing about it, is one thing, hearing it from the horse’s mouth is different altogether. In this Burn Up Episode, we chat with 5 guests, all with extensive experience in remote interviewing. We talk about whether remote interviewing works, whether it’s a stop-gap measure or there to stay, and how to be successful at it, as interviewer and candidate alike. Show Notes We’ve got an excellent cast of guests on this episode. Please feel free to get in touch with any of them if you are looking for an engagement, want to know more about remote working, work with an organisation that is interested in improving their remote working practices or simply want to say hello… In this episode you’ll meet; Becky Smith, recruiter and people manager, and Neha Datt who works as product consultant, has co-written the remote working playbook and runs a webinar on remote working best practices. She can best be reached via her company Mercurial Phoenix or via twitter @oliphantism. You will also hear from Nuno Silva Peirera who works as a Delivery Lead in Portugal and with whom we have remote interviewed many times. Nuno blogs, tweets @nunoaspereira, and has recently released a Metal Album which we highly recommend you check out. Nuno also has a most excellent youtube video on remote working. We also speak with Werner Smit who is a Delivery Lead in South Africa and has extensive experience working across country boundaries, Rajesh Kumar Thiagaran who is a Product Consultant in Pune, India, with experience in the recruitment industry and with whom we have recently run a major multi-day remote training session across London, Bangalore and Pune. And of course, there is also Dave Hewett whom you’ll have met in Episode 8. Dave has a keen interest in team working practices (remote or other) and hjas been instrumental in making the remote (and other) playbooks happen. If you want to work with Equal Experts you can get in touch with them via their website or any of us via linkedin or any other channel. https://www.equalexperts.com/blog/our-thinking/new-to-running-interviews-remotely-this-is-how-we-are-doing-it/ https://remote-working.playbook.ee/ CHECKLIST– Embedd added above– Embedd added to Excerpt– Delete this block
25 minutes | 8 months ago
EP21: How to do lightweight Inceptions
In this episode Swathi Poddar – who you’ll know from last season — and I catch up on Lean Inceptions. As you know we have written the Inception Playbook which is a quite chunky piece, providing in-depth guidance on how to kick off projects well and set initiatives up for success. While this is still very helpful, we found that the more experienced teams are looking for something a bit more light-weight, to incept not major initiatives, but smaller projects, feature delivery or additional workstreams. In fact, these days we are running more and more super short, highly focused Inceptions that may be as short as 2–3 days, or only 3–4 hours, even… In this episode we discuss when such Lean Inceptions are valuable and feasible and talk through the mechanics of running them. You may want to view the diagram below while listening to this podcast: Lean Inception flow More in-depth information about Lean Inceptions here: https://thedigitalbusinessanalyst.co.uk/lightweight-inceptions-82bb8bd8932b Download our free Core Tools Playbook and Inception Playbook here: Playbooks
15 minutes | 9 months ago
Ep20: Tools to make your live (and initiative delivery) easier
In this episode we introduce our new Core Tools Playbook and how these tools can help a team work more effectively and achieve better outcomes easier. Contrary to our Inception Playbook which suggest a process or approach to delivery over all, the Core Tools Playbook is a collection of the tools a team can use during kick-off of an initiative or at any point initiative delivery. In fact, some tools are so versatile they can be used outside of initiative or even IT context. Behold: The Core Tools Inception Playbook (free download). A compilation of plays (recipes) for 18 tools with templates and examples The Core Tools Playbook (available for free download) is a compilation of 18 tools to help teams work better, and achieve desirable outcomes in more effective, efficient and pleasant ways. This playbook introduces 18 tools, explains their benefit and when to use them, and provides step by step instructions on how to use them as well as supporting templates and examples. The Core Tools Playbook covers tools such as Affinity Mapping, Storymapping, Context Modelling, Wardley Maps, and many others… Who is the Core Tools Playbook for? The Playbook is for beginners, to get to know the tools and have guidance on how to use them, and for experienced practitioners to get inspiration and insight on what good looks like, what works and what doesn’t, to make you even more successful… Why 18 Tools? The tools described in the Core Tools Playbook are those that I, as a Business Analyst, Product Owner and — sometimes — Project Manager, use most frequently, and which I have seen to be most conducive to successful delivery. The playbook covers a sub-set of tools that were at the forefront of my mind in my day to day work. And as I am helping a lot of teams get well off the ground (Inceptions) these days, there is a clear bias to tools that help in that ‘space’. Of course to be successful overall, there are other tools we need to use, to get Discovery (identifying the right thing to do) and Delivery (implementing and operating it) right. I may write about those in the future… How does it fit in? This playbook is not about a big game plan, as is the Inception Playbook, but more about individual recipes to work better, than can be used in an orchestrated whole, but also in isolation. Where can I get it? Free download here.
3 minutes | 9 months ago
Ep19: Season 2
It’s been a while, mainly my fault. Been travelling a lot and just didn’t find the time. And Todd’s been busy as and doing new interesting things… So we have super exciting things to talk about in Season 2: We want to finish our discussion of roles We want to share thoughts on organisational dysfunction mainly based on both of us listening independently to podcasts about Apollo11 and the Challenger disaster We’ll finally do an entire series on discoveries and inceptions We’ll chat Infosec/Opsec with one of the EE practice leads and product with one of EE’s principles. And of course many many more things we’ve always wanted to talk about re all things lean, agile and software delivery As the first episode in this season we’ll introduce you to yet another playbook, this time about tools and techniques, which we’ve recently written. Yes, yes, we are also super excited… So tune in, and join the fun, because the future is agile…
14 minutes | a year ago
Ep18: TL;DR – Risk/Issue Management
In this episode Todd talks about the practicalities of Risk/Issue Management, including what risks and issues are, how to gather them, how to log them and how to review them. The following topics are covered: What’s a Risk/Issue? How are Assumptions and dependencies different?What’s different in Agile risk management vs. other methodologies?Risk data gather and S.W.O.T analysisRisk register breakdownALWAYS HAVE AN OWNER FOR EVERY RISK!!!Risk review sessionsAddING items into the development backlog to address risks and prioritise appropriatelyUSING metrics to understand when to act on risks, such as performance testing, etc. As always, please let us know if you have any questions. Show Notes An example risk register can be found here: https://docs.google.com/spreadsheets/d/1Nw3d7oa2O-xRUCOF3fzuzvH9lnk-h2kxgcFYrNr7iCs/edit?usp=sharing
9 minutes | a year ago
Ep17: TL;DR: Dependency Management
Dependency management, despite its importance, does not get the attention it deserves and is often a bit haphazard and less structured than it could be. In this playbook, we suggest a lightweight way to identify and manage dependencies. We explain why to do it, how to do it, what good looks like, and the most important dos and don’ts. Detailed discussion, example dependency map and template here. Example external dependency map Show Notes Detailed discussion, example dependency map and template here.
63 minutes | a year ago
Ep16: Team Roles – Delivery Manager / Scrum Master
In this Team Roles episode, Marcel and Todd talk about the role of the Delivery Manager and Scrum Master. We talk about the difference between delivery roles and give practical advice on how to help teams reduce risks, remove blockers and… Deliver! We touch on the importance of 1-on-1 relationships with team members, the importance of servant leadership, project awareness, project management tooling, risk management, good project hygiene and how to become a delivery manager. In this episode we talk in more detail about the following topics: What is a Delivery Manager anyway?The difference between Delivery Lead, Delivery Manager, Programme Manager and Scrum Master. Have we got you confused yet? Don’t worry, we’ll explain….Delivery mindset within the teamBalance between shielding the team and exposure to clientsThe importance of 1-on-1 relationships with team membersAvoiding being a ‘box ticker’ Delivery ManagerThe importance of servant leadershipBeing aware of what you DO know, not what you THINK you knowBeing organised and prioritising timeDocumenting everythingProject management toolsThe importance of building good teamsTodd’s number 1 tip: scheduling 1-on-1s and the importance of listeningRisk and blocker managementGood project hygiene and project ceremoniesHow to get into project managementProject management certifications and continuous learning Show Notes Getting Things Done® by David Allenhttps://gettingthingsdone.com/ Inbox Zerohttps://www.fastcompany.com/40507663/the-7-step-guide-to-achieving-inbox-zero-and-staying-there-in-2018
13 minutes | 2 years ago
Ep15: Should we allow FE and BE stories?
In this episode Swathi Poddar and I are talking about a thing we used to fight about: Should we or Shouldn’t we allow frontend (FE) and backend (BE) specific user stories? Surely, stories should describe features, something that delivers value? But what, if there was a public API? And if it turns out that API also fed a GUI frontend? And what if your team simply demanded it as it made their lives easier? Swathi Poddar is a Business Analyst, Product Owner and Software Consultant. She has worked and studied in the UK, US and currently works out of Pune and Bangalore, India. The illustration below is maybe helpful to illustrate what we are talking about: Good user stories Deliver value, so they need to cover some ‘end2end’ functionality. Something where an action leads to a measurable and valuable outcome.Can be deliveredStories must be sufficiently small so we can understand them, reason about them and deliver them within a practical timeframe (usually days more than weeks).Facilitate deliveryStories are a communication tool, so they need to make sense in the wider context of what we are expected to achieve. If they are too big we cannot deliver confidently, if they are badly ‘split’ or ‘sliced’ they make no sense and if they are too small we drown in noise. How to split / slice stories We can split a domain horizontally, vertically or in any other weird combination of both. But, we need to adhere to the above principles. For your team’s sanity it also makes sense to have some consistency and uniformity in how we slice stories. Backend vs. Frontend stories The default reaction should be: Don’t do it. It violates principles 1 and 3. Focus on end 2 end, and if there is a frontend, specifically a GUI frontend, then that must be included in the story. WrongStory1 – [BE] Derive price based on locationStory2 – [FE] Display price to user RightStory – Display location based price to user Consider this in the context of actually writing the BE and FE story: “As a [what?] I want to calculate the price?” Hard to justify value in that. But what, do you say, if the user is a system? Here is where we get to the exemptions. We believe it may be ok to write BE and FE specific stories in the following cases: Where the BE provides value in its own rightAn example would be a data purging related story. But remember, any valid story must and will provide value to some business user directly or indirectly (otherwise we must not play it).Where the BE exposes an (often public) API and the customers of that API are end users (your frontend alone doesn’t quality!).In this case the requirements of the consumer of this external interface need to be specifically recognised and more often than not require user experience or service design to be delivered well.Do not see a GUI frontend simply as something to be added on like a facade. It’s requirements towards supporting interfaces are highly specific and often very different from those of system to system interfaces. Be careful with the BackendForFrontend pattern (see Sam Newman’s book below). This may provide a solution to bridge the gap between FE and BE but this comes at a cost.Where a story would be too ‘big’ or complex. In this case we should make very clear that the split is solely to facilitate development, but BE and FE build happen in conjunction. It is important that in this case we maintain a clear relationship between all these stories required to ultimately realise value. Don’t Do not succumb to the temptation to first do all backend work, and then later, do the frontend on top. This is dangerous asa) you may not delivery real value unless the FE is completed, which goes against all lean valuesb) often a GUI frontend has very specific requirements that go beyond that of a system to system API, so you may have to massively add on or even restructure your backendDo not devolve frontend work to a ‘Frontend Team’.Because that would mean tightly coupling teams which is an antipattern (see Episode 14). Our guest in this episode is Swathi Poddar, Business Analyst, Product Owner and Software Consultant. She can be ‘found’ and contacted here. Stuff to read Books we touch on in this episode, and which are highly recommended to ready areSam Newman’s Building Microserviceshttps://www.goodreads.com/book/show/22512931-building-microservices
21 minutes | 2 years ago
Ep14: Assigning teams to features or services
In this episode Swathi Poddar and I are talking about a topic very close to our heart: how do we best assign work to our teams? Do we have clear ownership of features or services, and if so, what do we do with the ‘shared’ service we’ll invariably encounter? Are such services commonly owned, can anyone mess with them, or are we keeping them under tight guard, and we ask: ‘Who owns the frontend?’ Expect an interesting, possibly controversial discussion...
47 minutes | 2 years ago
Ep13: Team Roles – User Research
In our continued exploration into Team Roles, in this episode we talk to Erica Kucharczyk about the role of User Research. This is a role that is frequently overlooked, but can pay off huge dividends in the long run if quality research is incorporated into your development cycle. We discuss how research helps teams validate their value proposition, the value of user research, the process of designing, running and analyzing tests, Qualitative vs Quantitative, how to get into user research and what good looks like. So, get out there and do some research!
33 minutes | 2 years ago
Ep12: What if WE Were the Client – Selecting Software Suppliers as a Startup
In our “If WE were the Client” series we engage in some wishful thinking, turning the situation on its head and talk about all the things we would do and change if we were looking for or working with software suppliers. In this first episode we discuss what Startups should think about when selecting and working with software suppliers.
9 minutes | 2 years ago
Ep11: TL;DR: Status Reports
In this TL;DR episode Todd talks about Status Reporting. Status Reports don’t always have to be a chore, in fact it can be a great communication tool if you focus on your audience and quality, concise content.
6 minutes | 2 years ago
Ep10: TL;DR: Backlogs
Most software delivery use a story backlog to manage delivery: effectively a list of things to delivery. But often the backlog is at best a mess, at worst confusing and misleading. A good backlog provides structure and facilitates delivery, a bad one adds confusion and inefficiencies. Here is our 5 minute fix to help you optimise your backlog.
8 minutes | 2 years ago
Ep09: TL;DR: Story Mapping
Story mapping is maybe the easiest tool to quickly and reliably elicit requirements. It’s my default that always delivers reliable results, not matter the situation. Here is our 5 minute how-to.
28 minutes | 2 years ago
Ep08: Team Roles – Engagement Management
In this episode we will discuss engagement management and the vital importance - if done well - of this role for successful delivery. We will dispel the myth that account management and client servicing is just about ‘saying yes’ and ‘wine and dine’. We will explain why ‘thick skin’ and empathy helps with the role, and that the most important skills an engagement manager can have are to be relaxed in the face of pressure and the ability quickly switch context.
7 minutes | 2 years ago
Ep07: TL;DR: User Story Writing
Everyone has heard of User Stories, most delivery teams use them, most business analysts or product owners write them, but often we are not writing them well.
38 minutes | 2 years ago
Ep06: Team Roles – User Experience-, Visual- and Service-Design
In this episode we will touch on the importance of placing the user at the centre of things and in this context will explain the differences between service design (the overall end to end including the organisational view), user experience design (how user interact at the various touch points), user interface design (the design of an interface provided at a specific touchpoint).
28 minutes | 2 years ago
Ep05: Team Roles – Business Analyst / Product Owner
In this episode we are talking to our colleague Swathi Poddar about the role of the Business Analyst and Product Owner: what value these roles add, what excellence looks like, how one can get into these roles, what people in these roles 'do' and how they work with clients and the rest of the team. Expect exciting insights on how to resource your teams even better.
Terms of Service
© Stitcher 2020