Search Results
55 items found for ""
- Moving cards backwards on your Kanban board
Almost all teams occasionally move a card backwards on their Kanban boards for one reason or another. Moving cards backwards isn’t always a bad thing but, backwards movement can have unintended consequences when you’re calculating flow metrics. What happens to the data when cards move backwards? Many people assume that all tools measure the Cycle Time for a workflow stage by adding up all the cumulative time an item spent there. Tools like ActionableAgile that focus on metrics for flow optimization do not! How work moves through the process impacts how we capture Cycle Time for the process and any state within. So, what do we do? Well, the answer is best seen in the Source Data chart. It is the place where you can find all of the dates we’ve captured for an item’s travels through the workflow. ActionableAgile always starts by capturing the date when a work item first moves into a column (or a workflow status mapped to a workflow stage if you’re in Jira and not using a board.) In the image above, we can see that a work item with the ID of FLOW-10 began in To Do in November of 2018, was moved to In Progress in January of 2019, and moved through Release Ready into Deployed on the same day in July 2021. But, those captured dates can get removed when cards move backwards in that process. If FLOW-10 were to move backwards from Deployed into Release Ready for whatever reason, we remove the date stamp for Deployed. If the item were to move from Deployed through Release Ready all the way back to In Progress, we would remove the date stamp for both Deployed and Release Ready. Essentially, when you move a work item backwards, all of the time that it accumulated in the stage you’re moving it out of (and any stages that you’re moving it through) gets added to the time already spent in the destination workflow stage. So, in the image above, the data now shows that it has continuously been in In Progress since January 30, 2019. When it finally moves through those stages again, the date they revisit the stages will be captured in the Source Data chart. What does this mean for me and how I work? First, know that it is always ok to move a card backwards when it was a mistake to move it forward in the first place. Accidentally dragged the wrong work item to done? Just move it back to where it was accidentally moved from. Just make sure that you don’t move it back any farther or you’ll lose valuable data. For example, if you have a card that accidentally moved from In Progress to Deployed, move it back to In Progress. If you move that card all the way back to To Do then dates for all subsequent columns will be removed and it will look like it never left To Do. Once you understand how backwards movement affects your data, the inevitable question then becomes “Well, if I shouldn’t move cards backwards, what should I do instead?” The answer can be contextual but almost always lies in how you design and use your board. How you anticipate and plan for these activities as expected things rather than unexpected things can make a huge difference. We have a few key tips in a companion blog post on designing boards for flow. Take a look then contact us for any questions you might have!
- What is Work Item Age?
Work Item Age is the elapsed time since the work item started. Work Item Age is one of four key flow metrics along with Cycle Time, Throughput, and WIP (aka work in progress). You can group these metrics into two pairs. Every completed item counts towards Throughput and has a Cycle Time where as every item still in progress counts towards WIP and has a Work Item Age. Work Item Age is, arguably, the most important flow metric because controlling age can result in significantly higher levels of predictability. In short, if you can only measure and manage one thing, make it Work Item Age. How do you calculate Work Item Age? To begin calculating Work Item Age, you need to have a defined process with two specific points identified: Your Start Line – or the point in your process in which items are considered started Your Finish Line – or the point in your process in which items are considered complete When you have those points defined, you can identify your WIP as they will be the work items between those two points. When you have those points defined, you can identify your WIP. They are the work items between those two points. You measure the age of each work item using the following calculation: (Now – Start TU) + 1 TU stands for Time Unit. You can use any granularity you'd like: seconds, minutes, hours, days or more. Why do we add 1? By adding one, this allows us to include both the start and the finish time unit in the Work Item's age so no time is left out. Work Item Age is the total elapsed time from start to today. This means it includes active working time as well any time that a work item is sitting there idle no matter the cause. So, whether work is waiting on someone, you’re blocked by a technical issue, or being interrupted by evenings and weekends, the time is included in an item’s Age. Getting Started Work Item Age is important to track for any team who wants to become more predictable. At its core, Work Item Age is a process improvement metric. When you see items aging more than expected, you can experiment with tactics to see if they help. There is no single fix but common tactics include limiting WIP, controlling work item size, reducing dependencies, and more. Once you manage Work Item Age, your Cycle Time data should stabilize and make forecasting easier! If you’re looking for a tool to help you track your flow metrics and improve your process, try out ActionableAgile for free. Don’t forget to reach out if you’re interested in joining our customer success program!
- How many completed sprints are needed for forecasting?
Probabilistic forecasting via Monte Carlo Simulations are a key feature of two of our products, ActionableAgile Analytics and Portfolio Forecaster. These simulations can provide amazingly accurate forecasts with a couple of clicks of a button, but there are lots of considerations when it comes to the data you use to generate the forecasts. A customer recently asked us about one of these considerations and we thought it was worth sharing. How many sprints are required to get decent data for a Monte Carlo sim? Our tool warns you that your forecasts might be iffy if you have less than 10 data points (finished work items), regardless of the number of sprints you have. Daniel Vacanti, creator of ActionableAgile and well-known trainer and speaker on metrics, goes into a little more detail. He says “you can forecast once you have approximately 10 data points regardless of the number of sprints. However, the quality of the forecast you will get is rather dependent on how good of flow you have during the sprint. If all items finish on the last day, then you may need several sprints before you can make a good forecast. However, in that case your biggest problem isn’t the data, it is how you are running your process.” The underlying consideration The rule of thumb with Monte Carlo simulations is that the conditions that were present when you generated your past data are roughly similar to the conditions that will exist during the period you are attempting to forecast. The word “conditions” here can refer to many different factors: team capacity, the mix of work, amount of work-in-progress, etc. These will all impact your throughput and throughput is the data used to forecast via our Monte Carlo simulations. So, if you have 10 items and that 10 items roughly represents the mix of work you’ll be doing in the future, those 10 items may be sufficient. However, if you have more cyclical work items or other considerations, you might need a bigger data set that accounts for that variety. Improve forecasts by improving predictability The less predictable you are — meaning the bigger the variation in how long it takes you to deliver work and how many work items you deliver over time — the more data you might need to get a better forecast. If you aren’t happy with your forecasts, usually the answer lies in improving predictability by controlling the age of in progress items. The more you prevent unnecessary ageing, the better your predictability. Want to try out probabilistic forecasting? Try ActionableAgile Analytics for free whenever you’re ready.
- What to do when forecasts and estimates conflict
At 55 Degrees, we think probabilistic forecasting is great. Heck, it is a key feature in our products ActionableAgile Analytics and Portfolio Forecaster. By basing your future outcomes on past outcomes, you can provide high accuracy with minimal effort. Assuming, of course, that current conditions are similar to your past conditions. Recently a customer had a great question stemming from his difficulties getting buy-in for using Monte Carlo simulations at his workplace. What happens if the forecasted likely outcomes from a Monte Carlo simulation fly in the face of the teams experience? How do you prove the model and get buy-in? Here’s our answer… One approach you might try is to talk up the pros of using a tool such as a Monte Carlo Simulation: Uses actual data from what you’ve accomplished before Can quickly run thousands of simulations to see how wide the range of possible outcomes really is Can give you a better understanding of which of those outcomes is really most likely Turns the focus away from whether or not a single outcome is right or wrong to determining how confident you need to be in any given forecast. That may make some headway. But, many hard-core proponents of effort estimates may need a bit more to decide that some simulation could be better at determining possible delivery dates than the experts themselves. What I try to remember is that what we’re really trying to achieve are better outcomes. Our success doesn’t (usually) live or die on which path people take to get the better outcomes. Add a pinch of science So, in this situation, why not let them take a more empirical approach and, potentially, prove it to themselves? Have people make a hypothesis of which they think will be better and why. Capture assumptions. Then, execute the experiment by utilizing both effort estimates and probabilistic forecasts. Finally, reflect and draw conclusions about which approach was better What do I mean by better? That’s a good question you should ask yourself when comparing a new option to your previous way of doing something. If either of the following conditions apply, I consider the new option to be “better:” More accurate (especially when no additional difficulty is added) Same accuracy but easier and/or less time-consuming A true scientist would tell you to repeat the experiment and see if the outcomes continually prove that conclusion. The worst case scenario is that a hypothesis proves to be wrong — yours or theirs. Either way, your forecasts win the contest because you’ve proven what is more accurate. Have you done this experiment? Share your outcomes in the comments below! Want to try out probabilistic forecasting? Try ActionableAgile Analytics for free whenever you’re ready.
- Is it time to get rid of all the managers?
A presentation at the Øredev developer conference in Malmö When I was a manager, I wanted to make a difference. A positive one. As a consultant, I work with managers who have the same goals. I’ve not yet come across anyone who wants to ruin everything (fortunately). When I started hearing the rhetoric about getting rid of the managers years ago, I was startled. Was I part of a huge problem that I didn’t even know existed? This question led me on a journey that had me studying the history of management and what people really thought of my past performance. I shared part of that learning in a talk at Øredev in Malmö, Sweden a couple of weeks ago. There is so much more to talk about on this subject that couldn’t fit in the talk. Please watch and let’s chat about your thoughts and experiences!
- What if there is no right or wrong?
Sometimes you need to change your approach When I watch the news, read social media, or listen to arguments about how to do something, I am struck by how far we’ve gone into the land of right vs. wrong. Unfortunately, it doesn’t feel like we’re just passing through. Instead, it seems we’ve built permanent structures and are settling in for the long haul. An example: U.S. Politics To understand what I mean, you need to look no farther than the US political scene. In a two-party system, there is meant to be a constructive conflict between adversaries that results in largely beneficial outcomes for the citizens the two parties serve. Working through the merits of different viewpoints allows people to come to better solutions for tricky questions like “How much should the government spend on social services?” or “When should the federal government make laws vs deferring to state government?” Unfortunately for U.S. citizens, the adversaries have transformed into enemies. Instead of constructive conflict with productive results, we now have regular battles to see which party can come out on top. The topic seems to matter less and less as time goes on… the language is usually about winning instead of serving the citizens. Policy making in America is approaching all-out war, where victory is paramount, “compromise” is a dirty word, and virtually any issue or development can become a weapon for bludgeoning the other side. David A. Moss, Harvard business review, march 2012 issue Ironically, when you lose sight of the goal you are trying to achieve and focus on the act of winning at all costs, everyone ends up losing in the long run. The citizens lose first, then the politicians lose when the citizens are tired of losing. Battlefields exist at work too Unfortunately, this problem isn’t limited to politics. We see this behavior in organizations as well. It is common to see departments focus on their needs and desires at the cost of overall business outcomes. Consider the time you’ve spent in discussions about prioritization at work. When is the last time you came out feeling as if everyone could accurately and selflessly compare their request amongst all the rest? I am guessing the answer is “Not often” or “Never.” We see methodological ideologists bash ideas without any recognition of the struggle that led to its creation, what it might be trying to achieve. If you have no idea what I’m talking about, just search for posts about SAFe on any social media outlet. Most of the detractors have valid points at the core of their arguments, but I’d wager a bet there is a correlation between the level of vehemence in their arguments and their blindness to anything that might be good in SAFe. Methods aren’t alone in being a target. We do this with tools as well. Everyone has tools they love to hate so much that they can no longer recognize any value that it might actually provide. Jira seems to be the most popular target these days. Let’s face it, we do need to know the downsides of the things we love. Knowing the limitations of a thing helps us use that thing properly. But the inverse is true also. If you are going to be a detractor of something, understanding the value it might bring to specific contexts is important to recognize. If you are going to be a detractor, its best to be specific about the context you are speaking from. Is it just one specific context you have a problem with or are you convinced that this thing is bad in all contexts? In the long run, we don’t serve the public with tweetable, snarky quips. We serve them with a reasoned, minimally-biased look at whatever we are commenting on. What we need is a balance We can’t wait for someone else to act to begin to restore sanity. We all have a part to play. It starts with realizing that “not everything is a problem to be solved, some things are situations to be managed,” as Barry Johnson says in his book Polarity Management: Identifying and Managing Unsolvable Problems. This means that there is not always a right or wrong. Sometimes there is only a balance to be found between two opposing, yet valuable, forces. In Sweden, we call this balance Lagom and it is something that we have to discover in each specific context. When I first started thinking about this I began creating a Spectrum Thinking Worksheet to help people identify what balance looks like. It includes writing down the following info: The opposing forces (extremes) at play Why it is important to balance them The value that each brings The negative consequences of over-focusing on one extreme What it looks like when you get it just right One of the things I want to help people realize is that balance doesn’t mean settling for average, or splitting the difference. Finding lagom means finding the place of contentment or equilibrium. This balance should be sustainable. And, like with a fulcrum, where you find this balance is highly dependent on the makeup of the forces at the poles. It may be heavily weighted towards one side or another, depending on your context. If you explore the same spectrum in two different contexts you will likely find that lagom looks different in each. Keeping your balance Once you have explored the spectrum between, and including, two extremes, a Polarity Map helps us visualize how these forces are really interdependent pairs. How, if you over-focus on one area, hoping to achieve the positive effects, you can tumble out of balance into the negative consequences you were working really hard to avoid. I was really excited to find this concept of polarity mapping as it overlaps quite a lot with my work on finding Lagom. Like with our Spectrum Thinking Worksheet, polarity mapping asks you to identify: early warning signs that you are getting out of balance. action items that you can and will take if the early warning signs you anticipated start to appear. But, thinking through where Lagom is on a spectrum gives you some particular insights about balance that you might not get using polarity maps alone. Using one or both of these tools will help you switch your default from binary thinking to spectrum thinking and understand how to find a balance between two valid, yet opposing viewpoints. Getting Started Don’t wait for someone to make the first move. It is up to us to bring sanity back to our lives. Perhaps your move will inspire others or show them how to make a difference. Identify a situation in which you’re being too dogmatic or ideological, to the detriment of your well-being or that of those around you. Then, use the Spectrum Thinking Worksheet alongside a Polarity Map to a) articulate the value of the opposing perspective, b) explore the spectrum between and determine what balance looks like, and c) anticipate early warning signals of falling out of balance and action items you’d take to get back to lagom. I would love to hear from you if you are using the Spectrum Thinking Worksheet and/or Polarity Maps. How have you struggled? How have you benefitted? Please share with us via our contact form.
- What is WIP?
WIP is an acronym for work in progress. So, the WIP flow metric measures the total number of work items that have been started – but not yet finished – at any given point in time. WIP is one of four key flow metrics along with Cycle Time, Throughput, and Work Item Age. These flow metrics are interconnected – meaning, when one of these flow metrics changes significantly, you’ll see an impact on one or more of the others. Most of us have experienced this reality: the more you have in progress, the longer it takes to get each thing done. It makes sense. If we put all of our effort in to one thing, that one thing will be finished faster than it would if we spread our time across multiple items. For more on this relationship, read about Little’s Law. The amazing news is that this makes WIP a leading indicator of future Cycle Time and it means that controlling your WIP can be a tool in your journey to help you deliver quickly and predictably. How do you calculate WIP? To begin calculating WIP, you need to have a defined process with two specific points identified: Your Start Line – or the point in your process in which items are considered started Your Finish Line – or the point in your process in which items are considered complete In the image below, work is considered started when it enters the In Progress column on the board. It is considered finished when it enters the Done column on the board. When you have those points defined, WIP is calculated as a simple count of work items between those two points. In the example above, we show a current WIP level of five (5). Why should I care about WIP? People can only do one ACTIVE thing at a time. You might be able to listen to music while working or something like that but you can't actually type or say two different things at one time. We are like single processors that way. So, when we have more things "in progress" at one time, we are switching back and forth between them. This makes each one take a bit longer to do than if you focused on just one thing at a time, not starting another until the first is finished. While you may not be able to have only one thing in progress, you should understand the impact of higher WIP - in other words more task switching. Take a look at one of my past blog posts to see about a study I did with my team at the time regarding the unspoken cost of high WIP levels: Can you afford not to limit work in progress? Getting started Teams often start looking at WIP around the same time they begin looking at Cycle Time, Throughput, and WIP Age. Looking at the impact of your WIP on the other key flow metrics will provide insight into the WIP limits you might want to experiment with for your process. As your experiment goes on, see what impact the WIP limit change had on your Cycle Time and Throughput. Repeat this process until you get a result that you’re pleased with! Interested in tracking flow metrics like this one? Try out ActionableAgile for free and reach out if you’re interested in joining our customer success program!