As a methodology, Lean is pragmatic, flexible, and time-tested. So why hasn’t it swept software engineering the way Agile has? Part of it may be a not-invented-here bias. Lean originated with automotive manufacturing, long before software teams were a thing. Could something born from the challenges of building things out of atoms really work for a discipline concerned with building things out of bits?

Another reason could be the terms that buzz around Lean—”kanban”, “value streams”, “WIP”, “flow efficiency”… it all sounds a little jargon-heavy and probably complicated.

My personal vote for why Lean has lived in Agile’s shadow is its prescription for continuous improvement. Not the principle itself, of course—who says no to improvement? Rather, the measures that Lean prescribes have been, at least historically, much easier to surface from instrumented machinery on a factory floor than they are from the “invisible” work of software development. (Again: atoms versus bits.)

Whatever the reason, Lean has plenty to recommend it. Let’s examine the case.

Lean principles—and what they mean for software dev

 are as nicely summarized as anything in the Agile Manifesto. There are five:

Identify the value stream for each thing the customer wants, and eliminate the wasted steps in providing it.

Make the product flow continuously through the remaining value-added steps.

Introduce “pull” between all steps where continuous flow is impossible.

Measure & improve so that the number of steps and the amount of time needed to deliver value to the customer continuously falls.

Granted, we’ve got some robotic sounding jargon-speak in there. (Value stream? What the hell does it mean to “introduce pull”?) But that’s why we’re here. To translate the principles into language that makes sense for software teams. 

The phrasing is a tad awkward (”Specify the value”), but Lean is all about moving value into customer hands as quickly and efficiently as possible. “Value” is just that—anything that your customer wants. The emphasis is on prioritizing things that 

To make this a little more concrete: in the software world, “the value” is commonly a feature. The work for that feature is usually made explicit, specified, in the form of an objective or epic. (Because “epic” carries certain tool/methodology associations, I’ll stick with the more neutral “objective”.)

“Build what your customers want” may sound too obvious to bear stating. But poking around in most backlogs, you’re bound to find lots and lots things that someone somewhere just thought sounded cool. The relation of these cool-sounding things to actual customer value is hopeful at best.

. We’re not interested in a bottomless backlog packed with every theoretically bright idea we’ve ever had. Backlogs aren’t parking lots. We want to be a value-delivery machine, not an idea-generation machine.

Identify the value stream for each thing the customer wants, and eliminate the wasted steps in providing it. 

As a term, “value stream” has a vague, big-vendor, enterprise-y sound. It’s enough to make anyone sleepy. But the idea and purpose of a value stream is simple:

Identify all the steps involved in moving a product feature from request to customer hands.

Get rid of the wasted steps. (There are probably more than you think.)

If you do the above, you are in fact “managing your value stream.” That is, you’re continually working to improve your end-to-end delivery process—your ”request-to-delivery,” or “order-to-cash,” or any other name it may go by.

How many organizations actually take the time to a) make explicit every step in bringing a feature to market and b) eliminate the wasteful steps? In my own experience, not many. When we join a company, we often just sort of inherit its structure, its departments, its macro processes. Do we really need a formal product requirement doc to justify every engineering investment? Who knows— that’s just how it’s done, and we’ve already built the team and formalized the processes to do it.

More commonly, a company’s value stream—the steps for bringing value to customers—simply accumulate steps over time. It’s like technical debt on the process side: steps and teams and inputs and gates that just build up and build up. After enough time, the whole edifice begins to feel untouchable. 

he said he makes it a point in any new company to “start slow, and ask lots of questions. Why do we work the way we work? Why these specific processes? What’s the history behind them?” That’s the kind of ongoing scrutiny and rigor that “value stream management” requires. It’s a habit of keeping your processes, well… lean.

For software engineers, this one’s natural. It’s easier for us to automate the flow of features between our value steps than it is for builders of physical products. In fact, this is what things like  

Introduce “pull” between all steps where continuous flow is impossible

There’s that mysterious phrase again— “Introduce pull”. 

What’s the essential difference between a “push” and “pull” model of work? 

One prioritizes starting work; the other, finishing it.

Ideas are created in response to actual customer demand, stack ranked in priority;

 by engineering teams into the development cycle as they have capacity to work them.

A bunch of work is planned, based largely on assumptions that customers will want it. (Think of all those endless backlogs…)

) to development team members, after negotiations with those teams over how quickly the work can start.

In the pull model, what you really want to know is: How well do ideas move from start to finish? How long (i.e., cycle time) does it take on average to get these ideas prioritized and built? Where are the bottlenecks in our workflow, and how do we eliminate them?

how do we move value into customer hands, from request to delivery, as quickly and efficiently as possible?

If this sounds obvious, good. Although there are plenty of product and engineering organizations who nod at the above, but actually use the push model. Why? Likely because that approach gives the illusion of progress. The emphasis falls on 

 work. All negotiations revolve around how quickly work can begin.

We all know the comfort of being able to confidently report, “Work has started on [X].” But it can be a false comfort, and set up false expectations. Just because work has started doesn’t mean it’s going to be finished any time soon. Still, in the moment, it 

 better than saying, “We haven’t started that yet.”

 work. In the pull model, new work doesn’t begin until sufficient work has been finished and the team has capacity.

It emphasizes throughput—actual work finished—instead of starting lots of stuff and declaring progress.

It empowers people (and their teams) to keep work moving. This is because the decision to begin new work rests with them, based on their capacity as measured by 

. Everyone becomes an owner of good flow.

There’s less management overhead. A manager’s job is concentrated on helping to relieve bottlenecks in flow and grooming the To Do queue, not on evaluating capacity or deciding who should take on what work. The team members take care of that themselves.

Lean really shines in the pragmatism of its metrics. They’re right there in the principle: you want to continually reduce “the number of steps” and “the amount of time” needed to deliver value. Simple, straightforward, without any confusion over what matters and why. 

The harder part is what I mentioned at the beginning: how do we bring these metrics to life for software teams? Handily, this is a big part of what Socratic does. So let’s break down what it looks like.

By continually evaluating and reducing “the number of steps” we’re trying to optimize 

—how well work moves from start to finish. An efficient engineering team is one whose work moves through the minimum number of steps, with a minimum of interruptions. Naturally, some interruption in flow is inevitable. You’re simply trying to keep time spent in any exception (i.e., non-flowing) states to a minimum.

automatically derives exceptions to flow efficiency

 based on the way work moves (or fails to move):

 is the backward movement of work, e.g. from a test phase back into a development phase;

represents work that was started, but then returned to a backlog phase, likely in favor of new, higher priority work;

 is any work that goes more than seven days with no movement or code activity;

For efficiency, we want to know how much of our total active work time is spent productively—that is, in a normal flowing state—versus time spent in any of the above exception states.

Assume an objective has absorbed a 100 total work days so far. If the time spent in nonproductive states is only 20 days, we probably feel pretty good—our efficiency, by this measure, is 80 percent. But if that number were 50 days, it would mean that half our total time so far has been eaten up by blocked or idled tasks, reworking tasks, or burning time on things that fell out of priority. Something is off.

The “amount of time needed to deliver value” is measured by 

. Put even more plainly, our speed: how long does it take us to deliver work, from start to finish?

Socratic determines the actual average time, measured in days elapsed, required to complete tasks and objectives. With our 

, we can see how our cycle time is changing period over period. If we notice a significant upward change, our eyes go immediately to the diagnostic metrics included as a part of cycle time: notably merge time (derived automatically from git), efficiency (explained above), and phase time. 

Phase time reflects how much time work spends in a given work phase (e.g. “To Do” “Doing” etc.)—the steps in your value stream. Below is a real example from our team. This shows the average time tasks spent in each engineering work phase in August, relative to the average time by phase over the last six months. 

The bottleneck leaps off the screen: tasks spent an average of 16 days in our “Ready for test” work phase—double the monthly average for time in that phase!

“Ready for test” is a waiting phase. Meaning, engineering has completed its work and the tasks are waiting to be pulled into the test phase. By making these ‘wait’ phases explicit, we can use our data to better surface bottlenecks like this one. The solution? We need more QA capacity…

Throughput goes back to Lean’s emphasis on finishing work, not starting it. Obviously, the starting variable for throughput is knowing how many objectives and tasks we completed in a given period. But that variable, by itself, is fairly meaningless. Is ten good? A hundred? A thousand?

What we're really interested in is the number of tasks we completed, 

relative to the number of new tasks raised. 

Ten tasks completed is actually a good number, if the number of new tasks raised over the same period was, say, seven. This tells us that delivery is outpacing demand. 

But—can we really use tasks as the unit to measure throughput? These aren’t manufactured widgets, where each one is the same. Aren't there so many variations in task size and complexity, that you're essentially mixing apples and oranges and bicycles?

Paradoxically, the answer to both questions is Yes.

 (LLN). Over the course of enough tasks, the inevitable differences in complexity among them basically come out in the wash.

With flow efficiency, cycle time, and throughput, we have a neat encapsulation of what product and engineering teams should aim for: 

deliver a lot of customer value, well and at good speed

.  By these measures we can know—and show—that we’re doing our job.

Big picture, there are a number of things we like about Lean:

—actual work finished—instead of starting lots of stuff and declaring progress.

 (and their teams) to keep work flowing. This is because the decision to begin new work rests with them, based on their 

 by allowing them to focus on completing what’s on their plates before picking up more work.

favors a pragmatic way of understanding—and showing—work health

, using actionable measures that anyone can understand: cycle time, throughput, and flow efficiency.

. A manager’s job is concentrated on helping to relieve bottlenecks in flow and grooming & prioritizing the backlog; team members are empowered to decide when to take on new work.

Never mind how long ago Lean principles were invented. They remain a timeless way for engineering teams to work.

Strange but true: a methodology born from the automative industry is perfect for software engineering teams

The authoritative guide to Lean software development

Already, AI is the most transformative technology since the iPhone. And that statement may soon be a wild 

statement, given where we seem to be headed. The 

forthcoming possibility (threat?) of general intelligence

 and the wizardly powers of ChatGPT, DALL-E and the like, have reinvigorated all the old hopes and fears about sentient machines.

While many fields have already seen disruption from AI (see 

), the AI dice aren’t yet settled in the field of project management. However, industry watchers predict that AI will transform it soon. Gartner thinks that 

80 percent of project management tasks will be automated with AI by 2030

The good news? Where project management is concerned, AI forecasts as an enabling technology, not a replacing technology. What it will do—and is doing already—is allow project managers and their teams to make better, faster decisions, with far less legwork and guesswork. 

Buzzword killer: what kind of “artificial intelligence” do we mean?

“AI”, like “cloud” before it, has fast become one of those tech buzzwords that everyone uses to cover over a host of different capabilities and meanings. At a kind of wiki-level summary, we can say AI is the simulation of human intelligence with machines via computer software and algorithms. This includes things like pattern recognition, deductive reasoning and the perception of sense data. 

The other relevant term here is machine learning, technically considered a subcategory of AI, which describes algorithms trained on data to build smart models that can do all kinds of cool, complex stuff. In an attempt to minimize clumsy writing and irritating pedantry, I’m going to use “AI” and “machine learning” interchangeably.

AI has most charismatically been deployed in the form of Large Language Models (LLMs) like ChatGPT. Trained on terabytes of text data, ChatGPT has learned to understand both the meaning of textual inputs provided by humans, as well as to assign probabilistic values to the text responses it gives back.

This process of understanding patterns from vast datasets is characteristic of AI. Among other things, this enables (to borrow 

) the “fracking of information” from huge bodies of text. An LLM can summarize thousand-page documents in a matter of minutes, complete with citations.

Of course textual communication and summary matters to project management. But the core questions project managers seek to own and answer—When will this project finish? Do we have enough people? How much will it cost? etc.—aren’t answerable by combing textual data sets. This is why, though the LLM flavor of AI is useful to project management, it hasn’t (yet) risen to the level of “transformative.”

There is another significant body of data, however, that’s highly relevant to project management. That dataset is the work activity of the organization, as captured in tools like Jira and GitHub. This “work activity” includes things like how work is moving (or failing to move), where workloads are growing or shrinking, how long work takes to finish, and how all of this compares to the historical activity of past projects.

This idea of applying machine intelligence to an organization’s work activity isn’t all that different from the way professional sporting leagues have used advanced analytics to unlock team performance. The “activity” in the sporting case includes things like how successful batters are based on type pitch, or the scoring efficiency of the team when facing different defensive sets.

The opportunity for AI in the realm of project management, then, is to see what patterns can be observed, what predictions made, based on the way teams work, and what drives improvement over time.

Let’s first consider the kinds of questions project managers are expected to answer:

How long will this project take to finish? 

To answer these questions, the project manager traditionally relies on sentiment: their own, and that of their teams. The job, by and large, is to aggregate and analyze this sentiment data—via meetings, reports, chat threads, etc.—and present a unified whole of project state. 

In plainer terms, project managers wrangle informed opinions to answer the questions above. Historically, there’s been no real alternative. Given this reliance on manually collected opinion, it’s small wonder that the statistics around project failure rates are high. (Sixty-six percent, according to the 

Fortunately, this bucket-brigading of opinions and educated guesswork is already being upended by machine intelligence. The move is toward hard data, instead of sentiment and opinion alone. 

This change is better understood by some examples. Let's take a look at how a few of the primary functions of project management are (or soon will be) transformed by AI.

When project managers and other leaders decide what's involved in a project, we’re making judgements on what is achievable within the constraints of time and money.

This is a matter of educated guesses. Often we have one or two known variables: the number of people available to do the work, and/or when the work is due. The rest relies on the judgment of experienced people to decide how much work is involved, how to break it down into its logical parts, and to guess how long the parts are likely to take to finish.

From there, things get murkier still. If our collective best guesses tell us that we’re likely to break the bounds of what our time/people/money can achieve, what should we change? Add more people? Reduce scope? Both? How much, and where?

But this kind of prediction and what-if analyses are where machines excel. 

How do you throw machine learning at this particular use case? Via 

. Monte Carlo is a statistical technique used to model complex systems across a wide range of fields—traffic control, stock predictions, and nuclear reactors, to name a few. The idea is to use the law of large numbers to predict how a complex system might behave.

Monte Carlo runs scenarios using our best empirical data and knowledge of the "rules of physics" for the system at hand. By collecting results from enough randomized scenarios, we can get an idea not only of what is most likely to occur, but also visualize the range of possible outcomes.

This makes Monte Carlo tailor-made for experimenting with the size of scope, and/or the number of people available, to see how these inputs change forecast time to complete. In this case, the “empirical data” fed into the model includes the historical actual time-to-complete previous work, as automatically derived from the system where work is managed (e.g. Jira, Socratic, etc.). It’s the kind of capability that’s best understood by way of example, 

A big part of project management is understanding how many people—and who—may be available to take on new work, or to help with existing projects needing more firepower.

In a small organization, this is a relatively trivial job. You know, or can quickly assess, whether anyone has spare cycles. As organizations grow and/or become geographically spread out, however, the picture gets muddy fast.

It’s simple enough with existing, non-AI project management systems to see who has what work on their plates. The hard part is figuring out how long will that work take to finish, and when a person might start to have free cycles.

But newer, AI-driven solutions like Socratic can derive these answers automatically. This is because the systems observes, by person and project, 

the actual historical average time-to-complete work

Going forward, these kind of data further enrich scenario planning, especially as conducted via Monte Carlo simulation as described above. Now, for instance, the “empirical data” used in the simulation can incorporate how many people are due to become available, who, and when. And because the data is personalized, the model will also account for variables like new hires, whose ramp times may naturally be longer than more experienced team members.

Once projects become active, there are really only two questions stakeholders care about: “How are we progressing, and when will it be done?”

Progress alone is reasonably straightforward to show, a matter of looking at completed work (usually captured as tickets in a work system) against open work for the project in question. But this simple math of X% complete, while useful, is missing some important context.

Is our progress speeding up, or slowing down? By how much?

In other words, what we want to understand in addition to progress is our 

. If a long-running project shows as 90% complete, we can start to feel good. But if we see that our momentum—essentially, the change in work delivered versus open work—is slowing by a significant amount, we feel… less good. At that late stage of a project, we should be completing more work than we’re adding. Something is off.

What does this mean for our ideal smart work system? It would know, with every change in work state (tickets completed, new tickets added, tickets reopened, etc.) 

how the new state compares to the prior state, and what this means for our rate of work delivered

. Granted, the calculation involved here hardly requires AI. But it’s in keeping with the thematic spirit—how the right, smart data lets project managers jump from opinion gathering to problem solving.

Very much needing the power of AI is the forecasting of end dates. Where earlier we looked at how Monte Carlo simulation changes the game for planning new work, here we’re concerned with predicting when active work will finish. 

For active work, we have richer, more fine-grained effects to feed into the model. A short list of those effects might include:

The rate at which work tickets falls idle;

The number and relationship of blocked tickets;

The amount of rework involved before a ticket is completed;

The application of people with specialized skills.

These are examples of the kinds of granular or unforeseen changes that impact project finish dates. Where a human couldn’t hope to know or account for them all, a machine can easily observe and absorb them into its models. Accurate project forecasts, long the Holy Grail of project managers and business stakeholders everywhere, are an imminent reality.

In a low-data, high-sentiment world, both project managers and  stakeholders rely on a manual collection of opinions to gauge the likely outcomes of the project. Commonly, the feelings of the team are aggregated into a kind of sentiment summary: maybe color-coded along the lines of “green”, “yellow”, “red”.

Now, AI doesn’t and shouldn’t replace the perspective of managers or team members. Sentiment—informed, experienced opinion—matters. But if all a stakeholder has to go on is a color marker on a slide, the project manager should expect some… questions. Some scrutiny. What’s wanted are the hard data to answer the questions explored here. With data comes transparency, authority, and trust.

What AI “will do” to project management and planning is already happening…

, the leading investment research platform, which streamlines the information investors need to move quickly, build conviction and make better decisions to outperform the market. Ram's Data Integrity team is responsible for three key areas of Tegus solution offering including BamSEC.com, Tegus' modeling product, and Tegus' data acquisition product.

I was curious to learn how Ram approaches software engineering generally, and specifically where/how this thinking has informed his team’s work at Tegus. What stood out:

Eyeing the number of handoffs in an organization as a predictor of bottlenecks

Giving teams the autonomy to own the full delivery of their work to customers

Piggybacking on John Kotter’s concept of Big Opportunity to let people work on what naturally drives them

Orienting around good flow, and making every team member an owner of it

Thanks again to Ram for taking the time to talk!

Let’s start generally. Pretend you’ve joined a new team. What does Day 1 look like?

My motto is always: start slow, and ask lots of questions. Why do we work the way we work? Why these specific processes? What’s the history behind them? It’s really just trying to get to the deeper Why behind things. Sometimes you’ll find people may not even know why things are done the way they’re done: it’s just always been that way! 

A specific example I’ve seen of this is the build process. It’s not uncommon to find that everyone complains about the build taking 30 minutes, an hour, two hours, but nothing gets done about it, right? There’s a fear factor. The build process has become this mysterious, brittle thing that no one wants to crack open. Everyone's petrified to touch it.

And I always ask, Why? Why can't we get training on it? Why can't we expense a few days to understand our build process and to modify it to actually make it work?

You have that relatively short period to come in and be the person who knows nothing, which allows you to look more holistically at what’s going on. Before you’re consumed by whatever the legacy processes, and they just become mechanical for you.

Are there other things that draw your eye?

One is handoffs. Handoffs, to me, are like “smells.” If you have a software development team, and a DevOps team, and a test team, and a release management team… that smells a little bit to me because it signals an organization with lots of siloes and limited autonomy for each of the participating teams.

Another thing that I often look for is turnover, and how we onboard people. Do we have good onboarding processes, and do we ever exercise that muscle? I've seen teams that become stale with people who are tenured five, ten years. It sounds great, but when it’s time to bring someone new on, there’s just no feel for how to do it. The current team is so steeped in the code base and its history, they can’t even imagine what it means to get a new person up to speed.

Looking at handoffs is interesting. It’s like a risk indicator for bottlenecking, I suppose…

That’s exactly it. Handoffs are a preventer of flow. It’s just an opportunity for things to stall out, or get missed. 

It also tends to undermine autonomy. If a piece of work has to pass through five different teams’ hands on its way out the door, who really is responsible? No one team is accountable for getting it into customer hands. Each team could do their part perfectly, but maybe it still takes months to get things delivered. That also means months before you’re getting feedback from customers. It’s like each team is winning their battle, but collectively we’re losing the war.

How does this inform planning and building at Tegus?

I lead the Data Integrity team. For roadmap planning, we have what we call “DI Day.” The whole team comes into the office, and everyone pitches ideas of things they want. They make these pitches to the product manager. All these ideas end up written on a board. 

Once we’ve had a chance to get our ideas out, we then talk about the needs of the business. The product manager will give us the context for things like sales, business targets, go-to-market strategy, and so forth. And then we work to align our ideas with the go-to-market strategy. 

From there, we come up with a list of the things we want to tackle. A list of objectives, with some initial, coarse-grain sizing: small, medium, large. In our world, small is roughly two to three weeks, medium is three to six weeks, and large is six to eight weeks. 

On a quarterly basis, we also set aside what we call “engineering time.” This is time for all the work that doesn’t tie neatly to one of our quarterly objectives—tech debt, defects, etc. Some quarters we budget a fair amount of time for it; other quarters might have little or none. It just makes for a less stressful, more impactful quarter when we’ve got agreement with our product manager on how much time can go towards it.

So you have your prioritized set of quarterly objectives. What happens from there?

We follow the pull model—meaning, people are selecting objectives from the prioritized list. 

, which is something that gives a person a real sense of urgency, because you’re passionate about what this thing you’re working on will make possible. That really spoke to me, because I remember my days as an individual contributor where, if I got a chance to learn something new or to work on something I chose, my intensity and energy showed in my work.

So we want people to claim objectives based on their interests. When somebody raises a hand and says, ‘Hey, I really would like to learn more about this,’ or ‘I feel super passionate about this,’ they get to lead that objective. And while I have team leads, while I have seniors, there is no rule that says an objective has to be led by a senior. An objective has to be led by a person. And it doesn't matter your tenure. What matters is your passion for the subject.

Size-wise, we like our objectives to be no more than four weeks in duration. Because you want, again, that principle of flow. That principle of incremental. It just creates the conditions where the product manager gets to see something pretty fast. Three to four weeks is always the timeframe where she can see something real, get something tangible in her hands and say, ‘Yes’ or ‘Not there yet.’ 

What sort of data are you using to understand how work is going?

 is one of the things I look at in Socratic on a daily and weekly basis. And yes, as we start populating our objectives with tasks, I don't know how you do it, but that forecast feature is pretty accurate! Socratic has learned pretty well how the team works. 

We recently had some unplanned work crop up, so we had to go through an exercise of rebalancing some objectives from Q2 to Q3—what could we realistically get done, what would we need to push? I did that exercise in less than a minute on a live call, using Socratic’s forecast data to tell me what was possible, and how to get back on track. And then we moved on from that subject. We didn't have to go into a heavy planning session. We didn't have to have some long discussion. 

 is the other thing I look at on a weekly basis. 

Merge request (MR) time is obviously a key component of cycle time.* It can become a big interruptor of flow. If you think about an MR taking three days, for example, what's the developer going to do during those three days? The natural thing is to pick up another task. And if your average is three days, that means that maybe they're done with the second task before that MR is complete. Well now their work-in-progress (

) is two. Well, if they're still waiting, their work-in-progress is going to three. All right, where does this end? 

When we talk about how long should it take a developer to review code, we like to see something around 15 to 20 minutes. So ideally, your MRs are of a size that they can be reviewed in less than 30 minutes. Again, working incrementally as much as possible, keeping that flow going.

I like empowering development teams to be accountable for taking value to the market. I want my teams to feel accountable to good flow, and that starts with having enough autonomy over the end-to-end process. In my team we’ve created a few norms around how long it should take to ship a small feature, a small bug, and how we create flow and a continuous release cadence. We’ve found success in shipping bug fixes within a day or less, small features within a week, and projects within 3 to 6 weeks.

I want to work with product owners who have identified value for customers, and then have a group of teammates who are responsible for turning that into software. They should have the freedom and the responsibility to work with the product owner to define the idea, build it, and ship it!

 show merge time is indeed the largest chunk for teams, accounting for nearly a third of total cycle time, on average.

A conversation with Ram Bolaños, engineering manager at Tegus, on what he looks for Day 1 with any new software team, and the data that helps keep work flowing.

At the moment, you can’t swing a Schrödinger's cat without hitting some reference to AI. Such is the spooky action of ChatGPT and other LLMs. 

, we’re actually employing a different breed of AI: Monte Carlo simulation. Monte Carlo is a statistical technique used to model complex systems across a wide range of fields—traffic control, stock predictions, and nuclear reactors, to name a few. The idea is to use the 

 to predict how a complex system might behave. 

Monte Carlo runs scenarios using our best empirical data and knowledge of the "rules of physics" for the system at hand. By collecting results from enough randomized scenarios, we can get an idea not only of what is most likely to occur, but also visualize the range of 

tl;dr: Monte Carlo is tailor-made for forecasting how long software projects will take to finish. 

The basic steps and inputs of our Monte Carlo model are as follows:

 tasks with random (but representative) durations.

 (identically-skilled) people to complete the tasks.

(4) Determine the completion dates for each task.

(5) Construct a burndown chart from these dates.

; Socratic provides the rest. This includes randomly-sampled task durations based on our anonymized body of historical actuals, which is needed for step 1. 

For our public forecaster, we’ve set the number of model runs (

) to 100. The more you do, the more statistical significance you gain, but it also starts to absorb some serious compute cycles. In our own analysis, 100 runs is enough to get a reliable forecast.

A Monte Carlo model can be improved by expanding the list of effects that impact the system in question. You might start with a basic model, but iterate with finer and finer effects until you reach an arbitrary degree of accuracy. In the realm of project work and software engineering, these finer effects would be things like:

The number and relationship of blocked tasks;

The amount of rework involved before a task is completed;

Our public forecaster gives 'first order' approximations, a bit like ignoring air resistance in a physics problem. (Suffice to say, it’s wildly more advanced than any spreadsheet!) The scenario planner and advanced forecaster being built for the Socratic app will incorporate effects like those above to yield even more accurate forecasts.

So there it is. The next time someone asks how long some project might take to tackle, you can chuck the guesstimates and spreadsheets. With just a couple of simple inputs and a click, you get 

the power of Monte Carlo, backed by real-world data

Make project estimating the machine’s problem.

Who needs story points when you have Monte Carlo simulation?

What are the traits of fast, productive software engineering teams? We used data to establish some preliminary baselines and findings.

The data that follow are derived from anonymized work activity of hundreds of Socratic beta users across more than 10,000 tasks. This represents almost two full years of data, from January 2021 through September 2022.

What’s our average speed to release work? Are we getting faster or slower? Where are the bottlenecks? All of these are first questions for many software teams. Here’s what we found…

A quick word on how we determine cycle time (speed). Socratic automatically measures the elapsed calendar days from the time work starts on a task, to the time it’s completed. So, if work begins on a Monday and finishes the following Monday, the total elapsed time for that task is 7 days.

A new kind of
task management
work intelligence

Task management meets artificial intelligence. A simple, powerful way to work better, easier, faster—from idea to working software.

Instant answers for the whole team

Answer the questions that matter.

Are our priorities on track?

Where do we spend our time?

How are we improving?

Methods

A new kind oftask managementwork intelligence