176 items found for ""
- Schrodinger's Work Item and the Quest for Value
This article is a guest contribution from Julie Starling, ActionableAgile customer, and was originally posted on her blog. Jump down to read more about Julie. We're all familiar with Schrodinger's cat right? The cat in a box which has the state of both dead and alive whilst the box is closed … when the box is opened it is one or the other. I can't help but see the parallels to work items in our system. Schrodinger's Work Item An active item in our system represents both potential value and waste ...until we deliver it, we do not know which it is. Potentially Valuable – In most instances, we engage with our customers to understand what is valuable to them. Even in cases where direct customer communication is limited, we often hold a genuine belief in the value of what we're delivering. However, complete certainty about its value remains elusive until we actually deliver the item and receive feedback. Only when our work item is in the hands of our customers can we truly determine whether the time invested has indeed been valuable. Waste - Until we deliver the item, the time we are spending on it can also be considered waste, as until it's delivered there is always a risk it won't be delivered and the time spent up until now will have been for nothing… these situations happen all the time and can be for a number of reasons, be it a change in strategy due to a global pandemic or change of requirement from our customers and everything else in between. It can also have been waste if we deliver it an no one uses it, it doesn't deliver the expected outcome or if we don't get any valuable feedback. Let The Cat Out The Box Whilst we understand that work in our system is potentially not valuable, we shouldn't be using this as a reason to not be experimental with what we deliver! Instead, we should think about getting work items out of our system as efficiently as we can. This way we can find out if it was actually valuable as quickly as possible, learn from this answer and move on with this new knowledge. Compromising quality is also not the answer! Two ways to get the cat out of the box... 1. Don’t Start! If you haven’t started working on an item then you haven’t started potentially wasting time. You can then put your efforts on keeping work that has started active and flowing. 2. Finish It! If you’ve started...then finish! One way to get an item out of a system is to finish it. On their own they may seem like two obvious and probably unhelpful points. However if we look at the bigger picture, we shouldn’t start items until we know they have the best chance of flowing through our system. When we do start, we should be managing that work in progress always with a goal of finishing. We want to keep our work flowing and keep the work as busy and active as possible. If we start items before they can flow there can be a lot of sitting around in the system. The longer the item is in the system the possibility of the item being waste just increases as the world around us changes or items become stale. Don’t Put the Cat in The Box, But If You Do, Don’t Keep It In There Longer Than Necessary In essence we shouldn’t start work until it’s the right time for our system, and when we do start it, we should be managing the work in progress with the goal of finishing. There are a number of ways in which we can manage work in progress, including... 1. Limit the amount of Work In Progress By not having too much in our system we are able to focus on what is active, less context switching and spend our efforts on keeping our work busy (keep work busy before people). If you are in a situation where you have a team of busy people and a number of work items that aren’t actively being worked on, then you probably need to start controlling your WIP. 2. Make items small The smaller work items are the easier they are going to flow through your system. We need to make sure our items are right-sized and represent the smallest possible chunk of potential value. This will help flow but it will also help us get the necessary feedback we need to know if we need to pivot in the quest for value. With this approach if the world around us changes and what we were delivering is no longer relevant, we’ve also minimized the amount of waste. 3. Take action on items that are unnecessarily aging Any item that is staying in the system unnecessarily long needs action taken on it. This could range from splitting the work item down, resolving blockers or even kicking it out of the system! But how do we know if an item is unnecessarily aging? ...I’ll be covering that in my next post. Similar to the state of Schrodinger's Cat being unknown until perceived, our work items exist in a superposition of potential value and waste. That is, until they are delivered and observed by our customers. Actively managing the work in the system shortens the time to understand its fate! TLDR; We can’t assume all work will be as valuable as we expect when we decide to do it. Work not finished has a dual nature of both potentially valuable or waste until we deliver and get feedback. To get the answer to ‘was it valuable?’ as quickly as possible we should be focusing on flow. Keep items in our system for a short of a time as possible. Keep inactive time to a minimum. Whilst work is in our system, we should be actively managing it with a goal to getting it out (at a high quality) as soon as we can. Techniques such as managing WIP, right sizing items and taking action on aging items help us to do this. About Julie Starling, Guest Writer Julie is passionate about the efficient delivery of value to customers and avoiding the illusion of certainty. In recent years she has specialized in how data can be used to drive the right conversations to do this. She encourages teams to use data in actionable ways and adjust ways of working to maximize their potential. She has spent over 15 years working in and alongside software delivery teams. In her spare time, she loves to travel, snowboard, and is obsessed with houseplants!
- How do you use pace percentiles on ActionableAgile's aging chart?
It is inevitable that there are ways that the software creator intends a feature to be used and there are ways that it ends up being used. 🤓 Sometimes these unintended uses can be even better than the initial idea, but other times they can end up causing harm. In a recent chat with Daniel Vacanti, we discussed this very thing about ActionableAgile™️ Analytics. I can say I was more than mildly surprised when one of my favorite features came up: the pace percentile feature on ActionableAgile's Work Item Aging chart. I love this feature because it helps you get early signals of slow work. However, after talking to and training many people, Dan saw that people very often misinterpret what this particular signal really tells us. How did he come to that conclusion? He talked to them about the decisions they would make because of the signals and saw that they weren't necessarily picking up what was intended. Instead, the decisions people were likely to make could lead to even worse outcomes than currently presented on the chart. What do you think? Are you interpreting the signals correctly? Watch this short video from Dan to find out. As always, feel free to leave your (appropriate) comments and questions on our YouTube channel!
- Little's Law - Why You Should Care
This is post 9 of 9 in our Little's Law series. I personally can't fathom how someone could call themselves a flow practitioner without a concerted effort to study Little's Law. However, the truth is that some of the posts in this series have gone into way more detail about LL than most people would ever need to practically know. Having said that, without an understanding of what makes Little's Law work, teams are making decisions every day that are in direct contravention of established mathematical facts (and paying the consequences). To that end, for those who want to learn more, here is my suggested reading list for anyone interested in learning more about Little's Law (in this particular order): 1. http://web.eng.ucsd.edu/~massimo/ECE158A/Handouts_files/Little.pdf Frank Vega and I call this "Little's Law Chapter 5" as it is a chapter taken from a textbook that Little contributed to. For me, this is hands down the best introduction to the law in its various forms. I am not lying when I say that I've read this paper 50 times (and probably closer to 100 times) and get something new from it with each sitting. 2. https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/OS/Littles-Law-50-Years-Later.pdf This is a paper Little wrote on the 50th anniversary of the law. It builds on the concepts of Chapter 5 and goes into more detail about the history of L=λW since its first publication in 1961. This paper, along with Chapter 5, should tell you 95% of what you need to know about LL. 3. http://fisherp.scripts.mit.edu/wordpress/wp-content/uploads/2015/11/ContentServer.pdf Speaking of the first publication of the proof of L=λW, there's no better teacher than going right to the source. This article would be my 3rd recommendation as it is a bit mathy, but its publication is one of the seminal moments in the history of queuing theory and any buff should be familiar with this proof. For extra credit: 4. http://www.columbia.edu/~ww2040/ReviewLlamW91.pdf This article is not for the faint of heart. I recommend it not only for its comprehensive review of L=λW but also (and mostly) for its exhaustive reference list. Work your way through all of the articles listed at the end of this paper, and you can truly call yourself an expert on Little's Law. If you read all of these, then you can pretty much ignore any other blog or LinkedIn post (or Wikipedia article, for that matter) that references Little's Law. Regardless of the effort that you put in, however, expertise in LL is not the end goal. No, the end goal is altogether different. Why You Really Should Care If you are studying Little's Law, it is probably because you care about process improvement. Chances are the area of process improvement that you care most about is predictability. Remember that being predictable is not completely about making forecasts. The bigger part of predictability is operating a system that behaves in a way that we expect it to. By designing and operating a system that follows the assumptions set forth by Little's Law, we will get just that: a process that behaves the way we expect it to. That means we will have controlled the things that we can control and that the interventions that we take to make things better will result in outcomes more closely aligned with our expectations. That is to say, if you know how Little's Law works, then you know how flow works. And if you know how flow works, then you know how value delivery works. I hope you have enjoyed this series and would welcome any comments or feedback you may have. Thanks for going on this learning journey with me! Explore all entries in this series When an Equation Isn't Equal A (Very) Brief History of Little's Law The Two Faces of Little's Law One Law. Two Equations It's Always the Assumptions The Most Important Metric of Little's Law Isn't In the Equation How NOT to use Little's Law Other Myths About Little's Law Little's Law - Why You Should Care (this article) About Daniel Vacanti, Guest Writer Daniel Vacanti is the author of the highly-praised books "When will it be done?" and "Actionable Agile Metrics for Predictability" and the original mind behind the ActionableAgile™️ Analytics Tool. Recently, he co-founded ProKanban.org, an inclusive community where everyone can learn about Professional Kanban, and he co-authored their Kanban Guide. When he is not playing tennis in the Florida sunshine or whisky tasting in Scotland, Daniel can be found speaking on the international conference circuit, teaching classes, and creating amazing content for people like us.
- October 18, 2023 | 5:00 PMTredje Långgatan 9, 413 03 Göteborg, Sweden
- November 8, 2023 | 6:40 AMMässgatan 6, 215 32 Malmö, Sweden
- Applying Metrics for Predictability (APM)Tickets: SEK 12,500.00January 26, 2022 | 12:00 PM
- 55 Degrees | Products - Portfolio Forecaster
Automated forecasts Always up-to-date Quickly generate up-to-date, automated forecasts on the epics or versions in your Jira projects with Monte Carlo simulations that use your historical data and your tolerance for risk. Minimize the time and effort you spend forecasting! Answer key questions with Portfolio Forecaster How likely is it that it will be finished by the due date? Our Monte Carlo simulations use your historical data to forecast how likely it is that you'll meet your desired due date for each epic or version. How certain are we about this forecast? In Portfolio Forecaster you can control the level of confidence in your forecast. That sets the probability of finishing by the shown forecasted dates. How will our choices impact the forecast? What would happen if we started more epics? Fewer? What if we changed their priority? You can use Portfolio Forecaster for what-if scenarios and have collaborative conversations early and often! Purchasing Options Start your free trial Portfolio Forecaster is exclusively available as an app that embeds directly in your Jira Cloud, Server, or Data Center instance. Every Jira user is automatically licensed! Try Portfolio Forecaster for free for at least 30 days! 55 Degrees is a Platinum Atlassian Marketplace Partner. Portfolio Forecaster for Jira participates in Atlassian's security programs and is Cloud Fortified
- 55 Degrees | DPA for our On-Premise Perpetual License Products