By Alex Yakyma.
We know that WIP (Work In Progress) Limits are useful. They are useful at different levels of abstraction in the organization: portfolio, program or team (see posts by Dean Leffingwell, and Sean McHugh). Limiting WIP is one of the central themes in Lean Product Development as pointed out by Donald Reinertsen in his uber cool book "The Principles of Product Development Flow". We even know that WIP Limit makes a lot of sense at the individual level as there evolved an individual productivity tool called Personal Kanban, which looks quite simple and logical. However, WIP Limits in software development are not as simple as they may seem. Software engineering is a knowledge-intensive, creative, intellectual type of work and this implies a whole bunch of interesting nuances. We are going to explore some of them now at the team level.
So first of all, let's imagine a team consisting of one developer (and one tester, for instance). Assuming that he has a backlog of user stories, how many of them should he start working on at once? One, right? If it is just one, he won't be multitasking and thus will be totally focused on his current context of work. Well, not quite like that... In the time when I was a developer and then afterwards when working in other different capacities and observing the way other developers worked I was quite often seeing interesting pattern: a person takes a new story and starts slightly digging in that new direction while still working on the old one. And here's why it isn't always all that bad but often vice versa: we are not drilling holes in the wall or assembling chairs - we develop software and this is, as we said, uniquely intensive intellectual work. So let me give you an example: I work on the user story that would enable a search system user to not only see the links of the pages where the search phrase was found but also the short abstracts containing the phrase so I could at a glance see the context in which the phrase is used on the corresponding page. And then all of a sudden while still coding this story I take another one: "negative filtering by keywords" thus enabling the user to narrow down search results to those that do not contain the selected keyword. And it's not that I start coding it, no, I just read about it little bit, I talk to the people who dealt with something similar, I go home after work and when sitting in the bus, I give it some little thinking. Next day I seem to find an interesting idea (when brushing my teeth): in order to easily implement this one we need to start working with a binary vector on top of the array of all keywords in current filter criteria. Finally during the lunch same day with Andrew, the guy from another team, I just share my algorithmic problem that I anticipate in the context of this story and he simply gives me absolutely great idea of how to implement a lightweight comparison mechanism. Inspired by this direction of thinking I seem to know what to do with the rest of the open questions. That's all I did, I thought about it a little bit, talked to other people, slept on it... that's how it works - generating good ideas takes time and there has to be knowledge that eventually morphs into the idea in some miraculous way after some while.
So now I finished coding my first story, maybe a bit slowed down by the distraction that I myself introduced, but I already have a plan in my mind of how I will approach the second story and I can start coding. After a bit of coding, when I see some of my ideas working and some still needed modification, which it took a bit of time to do, I'm certainly gradually moving forward with story #2 and it's just about time to pick another one from the backlog and just see what's in it, speculate a bit, discuss it a bit with someone, sleep on it and maybe in a short while (while still working on story #2) my brain will generate some good ideas...
The takeaway is: one story per person at a time may not be optimal and while coding one story I can start thinking and reading and just doing some slight background work on the next one and it will be more efficient! So in cases when real creative work is required, the optimum WIP Limit per person could be 2, not 1. I know, I know, we have to avoid individual WIP Limits when talking about the team. But bare with me, this is just our thinking tool, we'll get there...
Next trick is even better. What if we now have two devs on the team? Should they follow the same pattern? In other words limiting each devs WIP to 2 instead of 1? Looks like "yes" but this already gives us few alternatives: the stories can be different or can be the same. In other words there can be as many as four stories in progress due to such logic or just two! And the latter is really good approach. So see, with individual WIP Limits = 2 we have three possibilities for the team WIP Limit: 2, 3 or 4, depending on the overlap, and as we know, collaboration is king and we would most likely prefer it equal to 2.Let's now play it backwards: what if we set WIP Limit of the team of two devs equal to 2? Again, we have different alternatives: it could mean that they work each on different story or they are actively coding one story and "previewing" the other. And again, the latter might be of our preference. Thus...
Same WIP Limit at the team level may lead to different outcomes depending on the collaboration pattern that the team chooses.
It is easy to see how to scale this logic further to a full-size agile team. When we talk about pairing we by the way do not necessarily assume pair programming. It can be just collaborative work (something we know by name of side-by-side programming, for instance). So the net result of such collaboration pattern is really interesting: much faster and higher quality results but with the same WIP Limit that equals to the number of developers on the team. This mix of pair work and previewing user stories becomes very useful for knowledge sharing and collective code ownership in the team. All that is needed is just to rotate the pairs over time. Because of the "previewing" the probability that someone (on the pair) will have something to learn from his team mate is now considerably higher.
All of the above is totally applicable to Scrum teams (and was written with those in mind). We know that once the Scrum team has planned and committed to the Sprint scope, there can be different strategies of how to succeed with the Sprint. Some of them are better than the others. Today we covered one aspect related to collaboration and WIP Limits and I hope it was helpful.
We know that WIP (Work In Progress) Limits are useful. They are useful at different levels of abstraction in the organization: portfolio, program or team (see posts by Dean Leffingwell, and Sean McHugh). Limiting WIP is one of the central themes in Lean Product Development as pointed out by Donald Reinertsen in his uber cool book "The Principles of Product Development Flow". We even know that WIP Limit makes a lot of sense at the individual level as there evolved an individual productivity tool called Personal Kanban, which looks quite simple and logical. However, WIP Limits in software development are not as simple as they may seem. Software engineering is a knowledge-intensive, creative, intellectual type of work and this implies a whole bunch of interesting nuances. We are going to explore some of them now at the team level.
So first of all, let's imagine a team consisting of one developer (and one tester, for instance). Assuming that he has a backlog of user stories, how many of them should he start working on at once? One, right? If it is just one, he won't be multitasking and thus will be totally focused on his current context of work. Well, not quite like that... In the time when I was a developer and then afterwards when working in other different capacities and observing the way other developers worked I was quite often seeing interesting pattern: a person takes a new story and starts slightly digging in that new direction while still working on the old one. And here's why it isn't always all that bad but often vice versa: we are not drilling holes in the wall or assembling chairs - we develop software and this is, as we said, uniquely intensive intellectual work. So let me give you an example: I work on the user story that would enable a search system user to not only see the links of the pages where the search phrase was found but also the short abstracts containing the phrase so I could at a glance see the context in which the phrase is used on the corresponding page. And then all of a sudden while still coding this story I take another one: "negative filtering by keywords" thus enabling the user to narrow down search results to those that do not contain the selected keyword. And it's not that I start coding it, no, I just read about it little bit, I talk to the people who dealt with something similar, I go home after work and when sitting in the bus, I give it some little thinking. Next day I seem to find an interesting idea (when brushing my teeth): in order to easily implement this one we need to start working with a binary vector on top of the array of all keywords in current filter criteria. Finally during the lunch same day with Andrew, the guy from another team, I just share my algorithmic problem that I anticipate in the context of this story and he simply gives me absolutely great idea of how to implement a lightweight comparison mechanism. Inspired by this direction of thinking I seem to know what to do with the rest of the open questions. That's all I did, I thought about it a little bit, talked to other people, slept on it... that's how it works - generating good ideas takes time and there has to be knowledge that eventually morphs into the idea in some miraculous way after some while.
So now I finished coding my first story, maybe a bit slowed down by the distraction that I myself introduced, but I already have a plan in my mind of how I will approach the second story and I can start coding. After a bit of coding, when I see some of my ideas working and some still needed modification, which it took a bit of time to do, I'm certainly gradually moving forward with story #2 and it's just about time to pick another one from the backlog and just see what's in it, speculate a bit, discuss it a bit with someone, sleep on it and maybe in a short while (while still working on story #2) my brain will generate some good ideas...
The takeaway is: one story per person at a time may not be optimal and while coding one story I can start thinking and reading and just doing some slight background work on the next one and it will be more efficient! So in cases when real creative work is required, the optimum WIP Limit per person could be 2, not 1. I know, I know, we have to avoid individual WIP Limits when talking about the team. But bare with me, this is just our thinking tool, we'll get there...
Next trick is even better. What if we now have two devs on the team? Should they follow the same pattern? In other words limiting each devs WIP to 2 instead of 1? Looks like "yes" but this already gives us few alternatives: the stories can be different or can be the same. In other words there can be as many as four stories in progress due to such logic or just two! And the latter is really good approach. So see, with individual WIP Limits = 2 we have three possibilities for the team WIP Limit: 2, 3 or 4, depending on the overlap, and as we know, collaboration is king and we would most likely prefer it equal to 2.Let's now play it backwards: what if we set WIP Limit of the team of two devs equal to 2? Again, we have different alternatives: it could mean that they work each on different story or they are actively coding one story and "previewing" the other. And again, the latter might be of our preference. Thus...
Same WIP Limit at the team level may lead to different outcomes depending on the collaboration pattern that the team chooses.
Figure 1. Efficient collaboration pattern: WIP Limit = 2 and story "previewing".
It is easy to see how to scale this logic further to a full-size agile team. When we talk about pairing we by the way do not necessarily assume pair programming. It can be just collaborative work (something we know by name of side-by-side programming, for instance). So the net result of such collaboration pattern is really interesting: much faster and higher quality results but with the same WIP Limit that equals to the number of developers on the team. This mix of pair work and previewing user stories becomes very useful for knowledge sharing and collective code ownership in the team. All that is needed is just to rotate the pairs over time. Because of the "previewing" the probability that someone (on the pair) will have something to learn from his team mate is now considerably higher.
All of the above is totally applicable to Scrum teams (and was written with those in mind). We know that once the Scrum team has planned and committed to the Sprint scope, there can be different strategies of how to succeed with the Sprint. Some of them are better than the others. Today we covered one aspect related to collaboration and WIP Limits and I hope it was helpful.
I'm not a developer but if you talk about numbers and development so i thought this should be really helpful for developers.
ReplyDeleteUK academic writers online
It is a very strange idea about this number that is the same but its results are different.
ReplyDeletebuy dissertation online
Pune Escorts Service | Escorts Agency in Pune | Escorts Pune | Pune Female Escorts | Pune Escorts Models
ReplyDeleteWatching a great movie is not the same as writing a film critique outline. In fact, it is better to get a critique paper from a respectable film critique writing service than try to produce a film critique on your own, particularly if you have never done that before.
ReplyDeletePackers and Movers in Aligarh
ReplyDeletePackers and Movers in Rohtak
Packers and Movers in Tiruchirappalli
Packers and Movers in Bhagalpur
Packers and Movers in Jodhpur
Packers and Movers in Bhuj
Packers and Movers in Mathura
Packers and Movers in Gaya
Good day everybody! I love my relatives and they said that my mom worked as a doctor and saves people's life. But if you need to write an essay and maybe you are a student of medical institute or other, or you need to write a dissertation, so just take a look at this writing company and contact pro typers (they always write my essay). Check their online page as they have many smart editors working there!!!
ReplyDeleteSitapur Independent Escorts | Sonbhadra Independent Escorts | Sultanpur Independent Escorts | Unnao Independent Escorts | Varansai Independent Escorts
ReplyDeleteAmritsar Female Escorts are highly trained according to their profession. Amritsar Escorts agency is one of the elite escorts service provider in the town. Call Alisha to book your favorite Amritsar Escorts at very affordable price. You can choose variety of call girls according to your desire. http://www.alisharoy.biz/Punjab/amritsar-escorts.html is the only trustable Escorts Service provider in the town. Our Female Escorts will satisfy all your dream fantasies.
ReplyDeleteAmritsar Escort | Varanasi Escort | Bikaner Escort | Vijayawada Escort | Visakhapatnam Escort
Being heavily overloaded with various assignments is a common thing for students across the globe regardless of their educational levels. Certainly, students may cope with all the assigned projects i.e. essays, research proposals, presentations, speeches, reports, dissertationsand look for essays writer
ReplyDeleteHey there! If you see that writing papers is a big problem or a complex task for you then it's better to apply to the essay writing service page and On its page people can find information how to get a professional writing help. write my discussion
ReplyDeleteThe outcome may be different and depends on the method you are applying while writing an assigtment. I you are not sure which techics of writing you should choose for your paper you can always find free essay samples on the web and use it as a template for your writing. It always worked for me.
ReplyDeleteThis comment has been removed by the author.
ReplyDeleteSi vous êtes confronté à des problèmes d'appareils électroménagers à Dorval, je vous recommande vivement d'essayer ServiceServotech. Ils m'ont définitivement rendu la vie plus facile et plus efficace. Les services professionnels de réparation électroménagers à Dorval peuvent sembler plus coûteux à première vue, mais à long terme, ils vous permettent d'économiser de l'argent en prolongeant la durée de vie de vos appareils. Plus besoin d'investir dans des remplacements coûteux ! Quelle est votre expérience en matière de réparation professionnelle d'appareils électroménagers ? Faites-nous part de vos commentaires !
ReplyDeleteIf you're struggling with weight management, I encourage you to look into the latest Retatrutide study outcomes and implications. It could be the solution you've been searching for. Don't forget to ask your healthcare provider for recommendation before starting any medication.
ReplyDelete