Search Results

At the heart of Malmö, Sweden, where innovation meets inspiration, 55 Degrees once again took center stage at the Øredev Developer Conference from November 8th to 10th, 2023. As a testament to our commitment to revolutionizing team workflows, our booth became a hub of meaningful conversations, exciting giveaways, and friendly competitions. Let’s take a journey through the highlights of this extraordinary event. Empowering Workflows Through Conversations Our booth became the focal point for participants seeking revolutionary solutions to elevate their organizational workflows. With passion, our team conveyed how our software products can boost collaboration and productivity for teams and organizations. The exchange of ideas and experiences ignited a shared enthusiasm for innovation. To inject some fun into our workflow discussions, we set up a fortune wheel at our booth. Attendees spun the wheel, and the excitement was contagious! Lucky participants won cool swag like beanies, baseball caps, backpacks, and exclusive tickets to our highly anticipated rock-paper-scissors competition the next day. Team Spirit in Stickers: Putting Faces to 55 Degrees To make personal connections at the conference, we shared stickers representing each member of the 55 Degrees team. It was heartwarming to see the joy on everyone’s faces as they collected these tokens of team spirit. Connecting faces to our brand resonated deeply with our commitment to building genuine customer relationships. Rock, Paper, Scissors: A Grand Finale to Remember The pinnacle of our participation unfolded the next day with the Rock, Paper, Scissors competition. The crowd gathered, anticipation filling the air, as attendees battled for the grand prize—an Airpods Pro. This spirited competition highlighted 55 Degrees’s dedication to building a lively community and served as a memorable and entertaining conclusion to the conference. This year marked our second appearance at the Øredev Developer Conference, and it was undeniably one of our favorite moments of the year. The connections forged, the excitement shared, and the lessons learned are invaluable to our ongoing journey. To everyone who stopped by our booth, engaged in conversations, spun the fortune wheel, collected stickers, and participated in the rock paper scissors showdown, thank you! Your enthusiasm and energy fueled the success of our journey at Øredev 2023. Until next year, thank you for the memories! Capturing the moments that sparked meaningful conversations, exciting giveaways, and friendly competitions.

What is SOC 2, and why is it important? SOC 2, or Service Organization Controls 2, is a framework governed by the American Institute of Certified Public Accountants (AICPA). With a SOC 2 audit, an independent service auditor will review an organization’s policies, procedures, and evidence to determine if their controls are designed and operating effectively. A SOC 2 report communicates a company’s commitment to data security and the protection of customer information. Improving your security posture SOC 2 compliance exemplifies an organization’s commitment to customer trust and is a major milestone toward improving their overall security posture. With increasing cybersecurity threats and data breaches, it is paramount that organizations prioritize information security and the protection of their systems and data. By undergoing a SOC 2 audit, our controls and processes were validated by a third party who attests to the functioning of the controls relevant to our application. Why we pursued SOC 2 now? At 55 Degrees, two of our company values are "Make things better" and "Put people first." An important part of living up to those values is our commitment to data privacy and security throughout all aspects of our organization. From recruiting and training to onboarding new tools to delivering new products and features, we don’t take a single step without ensuring we’ve taken all reasonable steps to protect your data and your privacy. SOC 2 compliance is integral in proving to customers, stakeholders, and interested parties that our organization lives up to those values and has effectively implemented security controls. At our company’s stage, we realized that it was an ideal time to pursue this as it is important to protect data and mitigate potential security risks early and on an ongoing basis. 55 Degrees’ journey to SOC 2 compliance Compliance Partners Without the right compliance partners to guide us on our journey, the task would have seemed insurmountable. There were some key partners involved in our SOC 2 compliance journey. We partnered with Vanta to help us automate the collection of our audit evidence and monitor our continued compliance. Vanta provides us with the strongest security foundation to protect our customer data. Our audit firm, Advantage Partners, was extremely helpful in creating a seamless audit experience. With their guidance and support, we were able to achieve SOC 2 compliance in a swift, efficient manner. Process While SOC 2 can be a big undertaking, our compliance partners streamlined the process. We leveraged Vanta to integrate our key systems and guide us in quickly implementing policies and procedures to become audit-ready. Vanta gave us the direction we needed to pursue our compliance journey in a much shorter timeline than we would have had without them. Advantage Partners then confirmed our audit readiness, and we kicked off our Type II audit. Advantage evaluated the controls we have in place for the audit and opined on their state. In a matter of weeks, after our audit window ended, Advantage Partners drafted and issued our report. Timeline One key takeaway is understanding that improving our security posture and achieving compliance is a monumental task. This can be made easier with the right compliance partners, but it will take dedicated focus and time from your organization. The readiness period can take the most time, but we were able to make compliance a priority to get audit-ready in just a couple of months. We also found it important to review the audit timeline with Advantage Partners, set an ideal audit date, and work backward to be ready in time. We started with the required 3-month audit window. However, now that controls are implemented, we plan to exhibit our focus and priority on security by maintaining audit readiness at all times so that subsequent SOC 2 audits will be even more seamless and cover longer audit periods. Lessons we learned Start the process early. It is easier to implement policies earlier rather than later, and doing so as early as possible helps you build a more secure organization from the start. Building secure procedures and infrastructure are key components of a successful security program. Focus on improving security posture, not checking boxes. Compliance is not one size fits all. Ensure you are spending time understanding the frameworks you’re working towards so you can know how to best comply for your organization. Your entire organization will be involved in improving security and adhering to procedures. Help them to understand how they impact your ability to stay compliant! Security is a continuous project that should be prioritized in an organization. Don’t snooze your alerts - aim to stay at 100% readiness in Vanta all the time! The right partners and tools are key. Finding a compliance management tool like Vanta to guide you through the process makes it so much easier to know what to do and to do it quickly. Not only does it make it easier to get started, but it makes it (nearly) painless to maintain your audit readiness! For us, leveling up our licenses in tools like Snyk Enterprise has really taken the pain out of managing certain aspects of our compliance and providing the necessary proof. Finally, partnering with an audit firm dedicated to your success makes the process much less scary! Make sure you find a firm that you feel comfortable with and that is comfortable in your compliance management system. You can read more about our trust stance at https://55degrees.se/trust. If you would like to request access to our SOC 2 report or see information about the controls currently in place and other publicly available documents, you can visit our Vanta Trust Center at https://trust.55degrees.se. If you have any other questions, please contact us!

In today’s rapidly evolving tech landscape, where Software as a Service (SaaS) companies continuously strive for innovation and excellence, it’s crucial to remain mindful of our responsibility to both our communities and the world at large. At 55 Degrees, we firmly believe that true success extends beyond profits and market share. We take pride in our enduring commitment to making a positive impact and giving back to society. Our dedication to putting people first has been one of our core values since the beginning, and we are constantly seeking ways to make a difference through initiatives such as the “1% Pledge”, where we donate 1% of team member time to charitable causes and 1% of our profit. Supporting the Barncancerfonden One cause that has been close to our hearts is the fight against childhood cancer. The words "Children" and "cancer" should never coexist. As an organization, we proudly support the Barncancerfonden in their fight to keep cancer away from children. The Children’s Cancer Foundation fights childhood cancer and ensures that affected children and their families receive the care and support they need. As Barnsupporter 2023, we are involved and contribute to this noble cause. Despite advancements in medical science, the fight against childhood cancer continues. By donating to organizations like the Barncancerfonden, we are helping individual families and the collective effort to find better treatments and, ultimately, a cure for childhood cancer. Every day, a child in Sweden faces the harsh reality of cancer. However, there is hope! Thanks to research and more effective treatment methods, we’ve made significant progress, with 85 percent survival rate today. However, the ultimate goal is to ensure that every child diagnosed with cancer not only survives but also leads a healthy and fulfilling life. To achieve this, we proudly support Barncancerfonden by being a Child Supporter 2023. We encourage others to join us in supporting this vital cause, and together, we can bring hope and healing to children battling cancer. Do as we do, support Barncancerfonden | Stöd barncancerforskning Together, we help keep cancer away from children!

This is post 3 of 9 in our Little's Law series. Having explained in an earlier post in the series that Little's Law (LL) comes in at least two flavors, it's time for another thought experiment. For this test, I'm going to ask you to fabricate some flow data over an arbitrarily long period of time. In order to keep the experiment as simple as possible, the requirements for our fabricated data are going to be quite specific, so please allow me to list them here: Your flow data must start with zero WIP. Trust me, the experiment works equally well if you start with non-zero WIP, but in order to eliminate the possibility of certain edge cases occurring, let's all start with zero WIP. For the whole period of time under consideration, the arrival rate of your data must be constant. For example, if the arrival rate for the first day is two items, then the arrival rate for the second day must be two items, as well as two items for the third day, etc., for the whole span of your dataset. Likewise, the departure rate (Throughput) for your data must be constant for the whole time period under consideration AND must be less than your arrival rate. This should make sense. If we start with zero WIP, it would be impossible to have a constant departure rate greater than your arrival rate--otherwise, your WIP would turn negative (which, of course, is impossible). So, for example, if the departure rate for the first day of your dataset is one item, then the departure rate for the second day must also be one item, as well as one item for the third day, and so on for the whole span of your dataset. Items must move through your process and complete in strict first-in-first-out (FIFO) order. Again, this need not be strictly necessary, but it makes conjuring your dataset easier. The length of time for your dataset is completely up to you, but make it realistic, say, the length of one or two Sprints, the length of one of your releases, or the like. Got it? (I'm hoping the reasons for the specificity of these requirements will become clear shortly.) You'll recall from this earlier post that to calculate flow metrics, all you need to have is the start date and end date of each item that moves through your system. Thus, the following (Figure 1) might be some example data that we might use for this experiment: Figure 1 - Sample data Please note (and please forgive) the use of American-style dates above. "3/1/2023" is 1 March 2023, not 3 January 2023. You'll further recall from that earlier post that it is rather straightforward to calculate flow metrics from our item date data: Figure 2 - Flow Metrics Calculated From Sample Data Figure 2 above shows the arrival rate, Throughput, Cycle Time, and WIP for every single day of the time period under consideration (again, using American-style dates). The astute reader will notice the mathematically correct nuance of how the averages were calculated, which I hope to address in a future post. Now that we have all of our flow metrics derived, we can do some LL calculations for comparisons. We left off last time by pointing out that we have two versions of LL to deal with. The first is L = λ * W Where L is the average queue length (WIP), λ is the average arrival rate, and W is the average wait time (Cycle Time). Plugging in numbers from Figure 2, we have L = 7, λ = 2, and W = 3.5, or 7 = 2 * 3.5 which, of course, is correct. However, in the case of the second form of LL: WIP = TH * CT where WIP is the average work in progress, TH is the average Throughput, and CT is the average Cycle Time; when we plug in numbers, we get WIP = 7, TH = 1, and CT = 3.5, or 7 = 1 * 3.5 which, of course, is NOT correct. So how is it that we can have two forms of a "law" where one is correct, and the other is incorrect? Any mathematical theorem you can think of comes with a set of assumptions that must be in place in order for the theorem to be valid. I can guarantee you that the problem isn't with LL. The problem is with us and our understanding of LL. Let me explain. Any mathematical theorem you can think of comes with a set of assumptions that must be in place in order for the theorem to be valid. Violate any one (or more) of the assumptions at any time (or times), and the results you get in practice will not match the theory. For example, the fundamental theorem of calculus requires that you are dealing with (amongst other things) real-valued, continuous functions. Unless you are a mathematics geek, you may not know what any of that means but violate any one of those assumptions, and most of what you learned in your Calc 101 class becomes meaningless. Because it is an equation, most people want to rush to plug numbers in [Little's Law] to see what comes out the other side--without really understanding what they are doing. Little's Law is no different. It's worse, even. Because it is an equation, most people want to rush to plug numbers in to see what comes out the other side--without really understanding what they are doing. The prevailing Lean-Agile literature perpetuates this myth by suggesting you can do just that. (I'm loathe to give any examples here lest I become part of the problem, but just search the interwebs on your own for Little's Law in Agile, and you will see what I mean). What's worse is that many of those "sources" will tell you that you can use Little's Law as a predictor for what will happen if you take specific action. In other words, Little's Law will tell you exactly what your Cycle Time will be if you cut your WIP in half (spoiler alert: it won't). Another way of saying the above is that most people see L = λW, and they want to treat it like E = mc^2^ or F = ma. That is to say, they want to plug two of the three parameters into the equations to see if they can predict what the third parameter will be in some future state of the system. So if our current WIP is 12 and our current Throughput is 2, then all we need to do to get our future Cycle Time down to 3 is to cut our WIP in half while keeping our Throughput at 2 at the same time. I'm sorry to say it doesn't work like that. At all. The work to dispel these myths will start with the next post in this series. It will be a bit of a slog, and the minutia might seem tedious, but my hope is that if you stick with it, you will gain a much deeper appreciation for the law. That detailed discussion of what assumptions need to be in place for LL to be valid and how those assumptions apply to your own process data begins next. 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 (this article) 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 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.

This post is part 2 in our Little's Law series. You might think that the history of the relationship L = λ * W (Eq. 1) would start with the publication of Dr. Little's seminal paper in 1961 [reference #1]. The reality is that we must begin by going back a bit further. What the symbols in the above figure (Eq. 1) mean will be discussed a little later. Evidence points to queuing theorists applying (Eq. 1) in their work well before 1961--seemingly without ever providing a rigorous mathematical proof as to its validity. The earliest pre-1961 example that I could find (in a semi-exhaustive search) was a paper written in 1953 called "Priority Assignment in Waiting Line Problems" by Alan Cobham [reference #2]. Somewhat coincidentally (for those who know me), this paper applies (Eq. 1) to prove the dangers of prioritization schemes to the overall predictability of queuing systems. (As an interesting aside, a quote from that paper is, "any increase in the relative frequency of priority 1 units increases not only the expected delay for units of that priority level but for units of all other levels as well."--in other words, we knew about the dangers of classes of service at least as early as the 1950s!) It would seem that (Eq. 1) was not only acknowledged well in advance of 1953, but it was also widely accepted as true even then. We knew about the dangers of classes of service as early as the 1950s! For the purposes of our story, however, the most important person before 1961 to recognize the need for a more rigorous proof of (Eq. 1) was Philip M. Morse. In 1958, Morse had published an Operations Research (OR) textbook called "Queues, Inventories, and Maintenance." [reference #3] In that book, Morse provided heuristic proofs that (Eq. 1) holds for very specific queuing models but commented that it would be useful to have the relationship proved for the general case (i.e., for all queues, not just for specific, individual models). In Morse's words, "we have now shown that...the relation between the mean number [L] and mean delay [W] is via the factor λ, the arrival rate: L = λW, and we will find, in all the examples encountered in this chapter and the next, for a wide variety of service and arrival distributions, for one or for several channels, that this same relationship holds. Those readers who would like to experience for themselves the slipperiness of fundamental concepts in this field and the intractability of really general theorems might try their hand at showing under what circumstances this simple relationship between L and W does not hold." Somewhat serendipitously, circa 1960, Dr. John Little was teaching an OR course at Case Institute of Technology in Cleveland (now Case Western Reserve University) and was using Morse's textbook as part of the curriculum. During one class, Little had introduced (Eq. 1) and commented (as Morse had) that it seemed to be a very general relationship. According to Little himself, "After class, I was talking to a number of students, and one of them (Sid Hess) asked, 'How hard would it be to prove it in general?' On the spur of the moment, I obligingly said, 'I guess it shouldn't be too hard.' Famous last words. Sid replied, 'Then you should do it!'" [reference #4] Little took up the challenge, went away for the summer in 1961 to come up with a general proof for (Eq. 1), wrote up his findings in a paper, submitted the proof to the periodical Operations Review, and had his submission accepted on the first round. His paper has since become one of the most frequently referenced articles in Operations Review's history. [reference #5] As such, the relationship L = λ * W quickly became more commonly known as Little's Law (LL). The real beauty of Little's general proof--apart from not relying on any specific queuing model--was all of the other things you didn't need to know in order to apply the law. For instance, you didn't need to have any detailed knowledge about inter-arrival times, service times, number of servers, order of service, etc., that you normally needed for queuing theory. [This point will become of monumental importance when we talk about applying LL to Agile.] In the years after its first publication, LL found applications far beyond OR. One such application was in the area of Operations Management (OM). OM is a bit different than OR because OM is generally more focused on output rather than input. Consider the perspective of an operations manager in a factory. A factory manager's primary focus is output because the whole reason a factory exists is to produce "things" (factories don't exist to take in "things"). Because of this potentially differing perspective, in the OM world, LL is usually stated in terms of throughput (TH or departures) rather than arrivals; work in progress (WIP) rather than queue length; and cycle time (CT) rather than wait time [reference #6]: WIP = TH * CT (Eq. 2) It's fairly easy to see that (Eq. 1) and (Eq. 2) are equivalent; however, the change in focus from arrivals to departures will require a nontrivial amount of care that we will get into in a later post. The reason I mention (Eq. 2) is because this is the form of LL that the Agile community seems to have preferred, and so it is here that our brief history ends and the real story begins. So why should you be concerned about any of this? There are a couple of reasons, really. First, practitioners should acknowledge that any doubts about the legitimacy of the theory have been settled for 70 years or more. There is simply no question about the validity of LL or its place in the management of flow. Second, because most agile practitioners have only seen LL in the form of (Eq. 2) and not (Eq. 1), it is important for them to understand where (Eq. 2) really comes from. It's not just a matter of simply substituting variable names, and Robert is your father's brother. There is simply no question about the validity of Little's Law or its place in the management of flow. This brings us to the fact that we actually have two forms of Little's Law to consider: L = λ * W and WIP = TH * CT But which one do we use and when? I'm glad you asked because that will be the topic of the next post in this series... Explore all entries in this series When an Equation Isn't Equal A (Very) Brief History of Little's Law (this article) 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 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. References Little, J. D. C. A proof for the queuing formula: L = λ W. Operations Research. 9(3) 383–387, 1961. Alan Cobham, Journal of the Operations Research Society of America, Vol. 2, No. 1 (Feb. 1954), pp. 70-76 Morse, P. M. (1958) Queues, Inventories and Maintenance, Publications in Operations Research, No.1, John Wiley, New York. Little, J. D. C., S. C. Graves. 2008. Little's Law. D. Chhajed, T. J. Lowe, eds. Building Intuition: Insights from Basic Operations Management Models and Principles. Springer Science + Business Media LLC, New York. Whitt, W. 1991. A review of L = λW and extensions. Queueing Systems 9(3) 235–268. Hopp, W. J., M. L. Spearman. 2000. Factory Physics: Foundations of Manufacturing Management, 2nd ed. Irwin/McGraw-Hill, New York.

This is post 4 of 9 in our Little's Law series. In the previous post, we demonstrated how the two different forms of Little's Law (LL) can lead to two very different answers even when using the same dataset. How can one law lead to two answers? As was suggested, the applicability of any theory depends completely on one's understanding of the assumptions that need to be in place in order for that given theory to be valid. However, in the case of LL, we have two different equations that purport to express one single theory. Does having two equations require having two sets of assumptions (and potentially two types of applicability)? In a word, yes. Recall that the L = λW (this is the version based on arrival rate) came first, and in his 1961 proof, Little stated his assumptions for the formula to be correct: "if the three means are finite and the corresponding stochastic process strictly stationary, and, if the arrival process is metrically transitive with nonzero mean, then L = λW." There's a lot of mathematical gibberish in there that you don't need to know anyway because it turns out Little's initial assumptions were overly restrictive, as was demonstrated by subsequent authors (reference #1). All you really need to know is that--very generally speaking--LL is applicable to any process that is relatively stable over time [see note below]. For our earlier thought experiment, I took this notion of stability to an extreme in order to (hopefully) prove a point. In the example data I provided, you'll see that arrivals are infinitely stable in that they never change. In this ultra-stable world, you'll note that the arrivals form of LL works--quite literally--exactly the way that it should. That is to say, when you plug two numbers into the equation, you get the exact answer for the third. Things change dramatically, however, when we start talking about the WIP = TH * CT version of the law. Most people assume--quite erroneously--that this latter form of LL only requires the same assumptions as the arrivals version. However, Dr. Little is very clear that changing the perspective of the equation from arrivals to departures has a very specific impact on the assumptions that are required for the law to be valid. Let's use Little's own words for this discussion: "At a minimum, we must have conservation of flow. Thus, the average output or departure rate (TH) equals the average input or arrival rate (λ). Furthermore, we need to assume that all jobs that enter the shop will eventually be completed and will exit the shop; there are no jobs that get lost or never depart from the shop...we need the size of the WIP to be roughly the same at the beginning and end of the time interval so that there is neither significant growth nor decline in the size of the WIP, [and] we need some assurance that the average age or latency of the WIP is neither growing nor declining." (reference #2) "At a minimum, we must have conservation of flow." Allow me to put these in a bulleted list that will be easier for your reference later. For a system being observed for an arbitrarily long amount of time: Average arrival rate equals average departure rate All items that enter a workflow must exit WIP should neither be increasing nor decreasing Average age of WIP is neither increasing nor decreasing Consistent units must be used for all measures I added that last bullet point for clarity. It should make sense that if Cycle Time is measured in days, then Throughput cannot be measured in weeks. And don't even talk to me about story points. If you have a system that obeys all of these assumptions, then you have a system in which the TH form of Little's Law will apply. If you have a system that obeys all of these assumptions, then you have a system in which the TH form of Little's Law will apply. Wait, what's that you say? Your system doesn't follow these assumptions? I'm glad you pointed that out because that will be the topic of our next post. A note on stability Most people have an incorrect notion of what stability means. "Stable" does not necessarily mean "not changing." For example, Little explicitly states aspects of a system that L = λW is NOT dependent on and, therefore, may reasonably change over time: size of items, order of items worked on, number of servers, etc. That means situations like adding or removing team members over time may not be enough to consider to a process "unstable." However, to take an extreme example, it would be easy to see that all of the restrictions/changes imposed during the 2020 COVID pandemic would cause a system to be unstable. From a LL perspective, only when all 5 assumptions are met can a system reasonably be considered stable (assuming we are talking about the TH form of LL). References Whitt, W. 1991. A review of L = λW and extensions. Queueing Systems 9(3) 235–268. Little, J. D. C., S. C. Graves. 2008. Little's Law. D. Chhajed, T. J. Lowe, eds. Building Intuition: Insights from Basic Operations Management Models and Principles. Springer Science + Business Media LLC, New York. 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 (this article) 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 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.

This is post 6 of 9 in our Little's Law series. As we discussed in the previous post, a thorough understanding of what it means to violate each of the assumptions of Little's Law (LL) is key to the optimization of your delivery process. So let's take a minute to walk through each of those in a bit more detail. The first thing to observe about the assumptions is that #1 and #3 are logically equivalent. I'm not sure why Dr. Little calls these out separately because I've never seen a case where one is fulfilled but the other is not. Therefore, I think we can safely treat those two as the same. But more importantly, you'll notice what Little is not saying here with either #1 or #3. He is making no judgment about the actual amount of WIP that is required to be in the system. He says nothing of less WIP being better or more WIP being worse. In fact, Little couldn't care less. All he cares about is that WIP is stable over time. So while having arrivals match departures (and thus unchanging WIP over time) is important, that tells us *nothing* about whether we have too much WIP, too little WIP, or just the right amount of WIP. Assumptions #1 and #3, therefore, while important, can be ruled out as *the* most important. Assumption #2 is one that is frequently ignored. In your work, how often do you start something but never complete it? My guess is the number of times that has happened to you over the past few months is something greater than zero. Even so, while this assumption is again of crucial importance, it is usually the exception rather than the rule. Unless you find yourself in a context where you are always abandoning more work than you complete (in which case you have much bigger problems than LL), this assumption will also not be the dominant reason why you have a suboptimal workflow. This leaves us with assumption #4. Allowing items to age arbitrarily is the single greatest factor as to why you are not efficient, effective, or predictable at delivering customer value. Stated a different way, if you plan to adopt the use of flow metrics, the single most important aspect that you should be paying attention to is not letting work items age unnecessarily! More than limiting WIP, more than visualizing work, more than finding bottlenecks (which is not necessarily a flow thing anyway), the only question to ask of your flow system is, "Are you letting items age needlessly?" Get aging right and most of the rest of predictability takes care of itself. As this is a blog series about Little's Law, getting into the specifics of how to manage item aging is a bit beyond our remit, but thankfully Julia Wester has done an excellent job of giving us an intro to how you might use ActionableAgile Analytics for this goal. To me, one of the strangest results in all of flow theory is that the most important metric to measure is not really stated in any equation (much less Little's Law). While I always had an intuition that aging was important, I never really understood its relevance. It wasn't until I went back and read the original proofs and subsequent articles by Little and others that I grasped its significance. You'll note that other than the Kanban Guide, all other flow-based frameworks do not even mention work item aging at all. Kinda makes you wonder, doesn't it? Having now explored the real reasons to understand Little's Law (e.g., pay attention to aging and understand all the assumptions), let's now turn our attention to some ways in which Little's Law should NOT be used. 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 (this article) How NOT to use Little's Law Other Myths About Little's Law Little's Law - Why You Should Care 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.

This is post 5 of 9 in our Little's Law series. Not to get too morbid, but in police detective work, when a married woman is murdered, there are only three rules to determine who the killer is: 1. It's always the husband 2. It's always the husband 3. It's always the husband The same thing is true when your flow metrics are murdered by your process: 1. It's always the assumptions 2. It's always the assumptions 3. It's always the assumptions Think back to the first experiment I had you run at the start of this blog series. I had you look at your data, do some calculations, and determine if you get the results that Little's Law predicts. I even showed you some example data of a real process where the calculated metrics did not yield a valid Little's Law result. I asked you at the time, "What's going on here?" If you've read my last post, then you now have the answer. The problem isn't Little's Law. The problem is your process. The Throughput form of Little's Law is based on five basic assumptions. Break any one or more of those assumptions at any one or more times, and the equation won't work. It's as simple as that. For convenience for the rest of this discussion, I'm going to re-list Little's assumptions for the Throughput form of his law. Also, for expediency, I am going to number them, though this numbering is arbitrary and is in no way meant to imply an order of importance (or anything else for that matter): 1. Average arrival rate equals average departure rate 2. All items that enter a workflow must exit 3. WIP should neither be increasing nor decreasing 4. Average age of WIP is neither increasing nor decreasing. 5. Consistent units must be used for all measures In that earlier post, I gave this example from a team that I had worked with (60 days of historical data): WIP: 19.54, TH: 1.15, CT: 10.3 For this data, WIP / TH is 16.99, not 10.3. What that tells us is that at one or more points during that 60-day time frame, this team violated one or more of Little's Law's assumptions at least one or more times. One of the first pieces of detective work is to determine which ones were violated and when. Almost always, a violation of Little's Law comes down to your process's policies (whether those policies are explicit or not). For example, does your process call for expedites that are allowed to violate WIP limits and that takes priority over other existing work? If so, for each expedited item you had during the 60 days, you violated at least assumptions #3 and #4. Did you have blockers that you ignored? If so, then you at least violated #4. Did you cancel work and just delete it off the board? If so, then you violated #2. And so on. This was quite possibly the easiest post to write in this series -- but probably the most important one. A very quick and easy health check is to compare your calculated flow metrics with those that are calculated by Little's Law. Are they different? If so, then somewhere, somehow, you have violated an assumption. Now your detective work begins. Do you have process policies that are in direct contradiction to Little's Law's assumptions? If so, what changes can you make to improve stability/predictability? Do you have more ad hoc policies that contradict Little? If so, how do you make them more explicit so the team knows how to respond in certain situations? The goal is not to get your process perfectly in line with Little. The goal is to have a framework for continual improvement. Little is an excellent jumping-off point for that. Speaking of continual improvement, when it comes to spotting improvement opportunities as soon as possible, there is one assumption above that is more important than all of the others. If you have followed my work up until now, then you know what that assumption is. If not, then read on to the next post... 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 (this article) 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 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.

This is post 7 of 9 in our Little's Law series. You may or may not be surprised to hear me say that the Little's Law equation is indeed deterministic. But, as I have mentioned several times in the past, it is not deterministic in the way that you think it is. That is, the law is concerned with looking backward over a time period that has already been completed. It is not about looking forward; that is, is not meant to be used to make deterministic predictions. As Dr. Little himself says about the law, "This is not all bad. It just says that we are in the measurement business, not the forecasting business". (1) In other words, the fundamental way to NOT use Little's Law is to use it to make a forecast. Let me explain, as this is a sticking point for many people (again, most interwebs blog posts get this wrong). The "law" part of Little's Law specifies an exact (deterministic) relationship between average WIP, average Cycle Time, and average Throughput, and this "law" part only applies only when you are looking back over historical data. The law is not about—and was never designed for—making deterministic forecasts about the future. Little's Law wasn't designed for making deterministic forecasts about the future. For example, let's assume a team that historically has had an average WIP of 20 work items, an average Cycle Time of 5 days, and an average Throughput of 4 items per day. You cannot say that you are going to increase average WIP to 40, keep average Cycle Time constant at 5 days, and magically, Throughput will increase to 8 items per day—even if you add staff to keep the WIP to staff ratio the same in the two instances. You cannot assume that Little's Law will make that prediction. It will not. All Little's Law will say is that an increase in average WIP will result in a change to one or both of average Cycle Time and average Throughput. It will further say that those changes will manifest themselves in ways such that the relationship among all three metrics will still obey that law. But what it does not say is that you can deterministically predict what those changes will be. You have to wait until the end of the time interval you are interested in and look back to apply the law. The reason for the above is because--as we saw in the last post--it is impossible to know which of Little's assumptions (or how many times) you will violate in the future. As a point of fact, any violation of the assumptions will invalidate the law (regardless of whether you are looking backward or forward). But that restriction is not fatal. The proper application of Little's Law in our world is to understand the assumptions of the law and to develop process policies that match those assumptions. If the process we operate conforms—or mostly conforms—to all of the assumptions of the law, then we get to a world where we can start to trust the data that we are collecting from our system. It is at this point that our process is probabilistically predictable. Once there, we can start to use something like Monte Carlo simulation on our historical data to make forecasts, and, more importantly, we can have some confidence in the results we get by using that method. There are other, more fundamental reasons why you do not want to use Little's Law to make forecasts. For one thing, I have hopefully by now beaten home the point that Little's Law is a relationship of averages. I mention this again because even if you could use Little's Law as a forecasting tool (which you cannot), you would not want to, as you would be producing a forecast based on averages. Anytime you hear the word "average," you must immediately think "Flaw of Averages" (2). As a quick reminder, the Flaw of Averages (crudely) states that "plans based on average assumptions will fail on average." So, if you were to forecast using LL, then you would only be right an average amount of the time (in other words, you would most likely be wrong just as often as you were right--that's not very predictable from a forecasting perspective). Plans based on average assumptions will fail on average Having said all that, though, there is no reason why you cannot use the law for quick, back-of-the-envelope type estimations about the future. Of course, you can do that. I would not, however, make any commitments, WIP control decisions, staff hiring or firing decisions, or project cost calculations based on this type of calculation alone. I would further say that it is negligent for someone even to suggest doing so. But this simple computation might be useful as a quick gut check to decide if something like a project is worth any further exploration. While using Little's Law to forecast is a big faux pas, there are other myths that surround it, which we will cover very quickly in the next post in the series. References Little, J. D. C. *Little's Law As Viewed on Its 50th Anniversary* https://people.cs.umass.edu/~emery/classes/cmpsci691st/readings/OS/Littles-Law-50-Years-Later.pdf Savage, Sam L. *The Flaw of Averages*. John Wiley & Sons, Inc., 2009. Vacanti, Daniel S. *Actionable Agile Metrics for Predictability* ActionableAgile Press, 2014. 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 (this article) Other Myths About Little's Law Little's Law - Why You Should Care 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.

This is post 8 of 9 in our Little's Law series. In the previous blog post, we talked about the single biggest error people make when applying Little's Law. That's not to say there aren't others out there. Thankfully, Prateek Singh and I recorded an episode of our Drunk Agile podcast to go over some of these other myths in more detail. While a large portion of what we talk about below is a rehash of the forecasting debacle, we also get into lesser-known problems like: 1. Using LL to set WIP Limits 2. "Proving" LL using Cumulative Flow Diagrams 3. All items need to be the same size 4. Cycle Times must be normally distributed 5. FIFO queuing is required BTW, you will recall from a previous post where I quoted Little as saying, "...but it is quite surprising what we do not require. We have not mentioned how many servers there are, whether each server has its own queue or a single queue feeds all servers, what the service time distributions are, what the distribution of inter-arrival times is, or what is the order of service of items, etc." (1). If Little himself says that these are myths, who are we to disagree? So grab your favourite whisky and enjoy! References Little, J. D. C., S. C. Graves. 2008. Little's Law. D. Chhajed, T. J. Lowe, eds. Building Intuition: Insights from Basic Operations Management Models and Principles. Springer Science + Business Media LLC, New York. Drunk Agile YouTube channel https://www.youtube.com/@drunkagile4780 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 (this article) Little's Law - Why You Should Care 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.

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.

If, like most everyone else, you answered, "Mount Everest," then you are not quite right. But you are not quite wrong, either. The real answer has to do with a concept I wrote about in an earlier blog post. Scientists can all objectively agree where mountains "finish". That is, it's extremely hard to argue about where a mountain "peaks". But when measuring, we know that "finished" is only half the battle. Agreeing where a mountain "starts" is a whole other conversation altogether -- and not nearly as straightforward as it may sound. For example, more than half of the Mauna Kea volcano in Hawaii is underwater. Only 4,205 meters of the whole mountain is above sea level. But if we measure from the base to the summit of Mauna Kea, it is 10,211 meters -- that's about 20% taller than Everest's 8,848 meters. If you only want to talk about mountains on land, then, base-to-summit, Denali in Alaska is actually taller (5,900m) than Everest base-to-summit (4,650m). So why does Everest get the crown? The reason is that most scientists choose to start their measurements of mountain heights from a concept known as sea level. But the problem with sea level is that anyone who has studied geography knows that the sea ain't so level. The physics of the earth are such that different densities of the earth's makeup at different locations cause different gravitational pulls resulting in "hills and valleys" of sea level across the planet (the European Space Agency has an outstanding visualization of this) Add to that things like tides, storms, wind, and a bulge around the equator due to the earth's rotation means there is no one true level for the sea. Scientists cheat to solve this problem by calculating a "mean" (arithmetic mean or average) sea level. This "average" sea level represents the zero starting point at which all land mountains are measured (cue the "Flaw of Averages"). You might ask, why don't we choose a more rigorous starting point like the center of the earth? The reason for that is... remember that bulge around the equator that I just alluded to? The earth itself is not quite spherical, and the distance from its center at the equator is longer than the distance from the center to either the north or south pole. In case you were wondering, if we were to measure from the center of the earth, then Mount Chimborazo in Ecuador would win. It seems that geologists fall prey to the same syndrome that afflicts most Agile methodologies. A bias toward defining only when something is "done" ignores half of the equation -- and the crucial half at that. What's more, you have Agilists out there who actively rant against any notion of a defined "start" or "ready". What I hope to have proven here is that, in many instances, deciding where to start can be a much more difficult (and usually much more important) problem to solve, depending on what question you are trying to solve. At the risk of repeating myself, a metric is a measurement, and any measurement contains BOTH a start point AND a finish point. Therefore, begin your flow data journey by defining the start and end points in your process. Then consider updating those definitions as you collect data and as your understanding of your context evolves. Anything else is just theatre. References PBS.org, "Be Smart", Season 10, Episode 9, 08/10/2022 The European Space Agency, https://www.esa.int/ 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.