![]() Another reason for which one wants to ensure a lot of ongoing work is to achieve high resources utilization.Whatever the reason, assuming that the Throughput does not change, the increase of work in process also increases the time required for its completion (the Lead time).Īlthough it may seem counterintuitive, remember that reducing WIP helps meet SLA and reduce development Lead time. However, in lots of cases exactly the opposite happens: the teams start working on lots of tasks so that the whole project “goes” faster. In other words, to meet development or service deadline, we must reduce the work in process, or finish it before starting a new jobs. The larger the WIP, the longer the lead time, i.e.the more it takes to finish the job started.The conclusions of this law are equally interesting and important: Throughput: the number of work units leaving the system at a given time, e.g.they have entered the system, but have not got out yet Work in process ( WIP): the number of requests (work units) that are being processed, i.e.The request may be a requirement, a user story, an incidence, material, a request from a user, etc. It is measured by the elapsed time (minutes, hours, etc). Lead time: The period between the entry of a request in the system and the receipt of the request.The law shows the relationship between Lead Time, Work in progress ( WIP) and Throughput. Look at your context (people + project) and use whatever delivers a better outcome.The origin of Little’s Lawis the Queuing Theory and it is perhaps best known law in the IT systems performance modeling. But it is not a silver-bullet (I feel like a parrot repeating this). It will not give you the optimal outcome, but it will unquestionably give you a better result. In this case, limiting the WIP with numbers and trying to tune it with time will give you a better process. This means that the person looking at the process would be actually temporary. I’d only use WIP Limits here to give process ownership to the rest of the team. This person can better understand how each person works and alert people to the amount of WIP according to each individual necessity as well as the type of project. If you have a Project Manager, an Agile Coach, a Scrum Master or other person that takes care of your process, you don’t need WIP limits. You have someone looking at your process.I see, until the time of this post, two options for two different contexts: But that doesn’t mean you shouldn’t use one. So what? Should I just go crazy and forget limits?Īs I said, it is just impossible to get a number that limits the work of everyone in an optimal manner. So, how can we come up with a single number that will magically fit all those curves under the same process? You can’t. Other than depending on the person, it also depends on the project: it might involve third-parties that regularly block their work, it might have a testing process that takes weeks or months to finish, etc. On the other hand, other people have a really difficult time changing focus and handling many tasks at once. They might get unmotivated with few responsibilities, or it might be easy for them to rapidly change focus between tasks, for example. Some people work best with more than one task at a time. I believe that a chart of WIP by the throughput of a person follow something like this: ![]() In another week, it will, unpredictably, take 3 hours to produce the same result.įrom my experience, some readings and even the way I work, I saw that different people work best with different workloads. ![]() One week, it may receive an input of size x and generate its outcome in 1 hour. Each machine can, unpredictably, change its behavior. ![]() And the machines don’t follow a linear relationship between size and time to complete a task.
0 Comments
Leave a Reply. |