Over the last few months I\u2019ve been investigating how our team can improve our understanding of our documentation process, and how we might be able to make improvements using principles from Theory of Constraints. I\u2019ve also been reading David Anderson\u2019s book, \u201cAgile Management for Software Engineering.\u201d His book has great diagrams that model a system for understanding its throughput. The diagrams are simple and show each activity in a system, its capacity, as well as loops where rework can occur.<\/P>\n
I decided to create a system model of our documentation process using the notation from David Anderson\u2019s book. My goal was for this model to show each activity in the process, its capacity level, and any loops. I also needed it to show where the bottleneck is located.<\/P>\n
Identify Activities<\/B><\/P>\n
I began by modeling the workflow of help topics. Our team is involved in other activities besides writing help topics. However, the process for creating help topics is the simplest and best understood part of our process, and it is also where we spend most of our time. This made a good starting point for constructing a system model.<\/P>\n
My first pass on the model looked like this:<\/P> \n
Each of these activities represents a distinct level of work by one or more people in which value is added to the help topic. When the help topic leaves the copy edit activity at the right, it has realized full value, and throughput is achieved for the system.<\/P>\n
Determine Capacity<\/B><\/P>\n
Next I added capacity data to each activity. I defined capacity as the maximum amount of throughput from an activity assuming no delays and 100% resource utilization. Therefore capacity is an ideal figure and useful for comparing each activity to see which one is a bottleneck. To get capacity data, I researched historical databases using previous cumulative flow diagrams and data we tracked in Visual Studio Team System. I looked for the maximum capacity numbers and also checked with team members to be sure the numbers were accurate. I came up with the following diagram:<\/P> \n
The capacity data in this model shows the maximum number of help topics that flow through any activity over one sprint (about 20 business days). It also reflects our team size of 6 writers and 1 editor. Therefore 6 writers are capable of writing 240 topics while 1 editor is capable of editing 500.<\/P>\n
From this new model we now see that writing is a bottleneck. But there is another factor that makes the bottleneck worse. The \u201cWrite\u201d activity requires a writer. So do the two \u201cRevise\u201d activities. These unadjusted numbers assume a writer is devoting 100% time to each activity simultaneously, which is obviously impossible.<\/P>\n
Adjust Capacity<\/B><\/P>\n
So I readjusted the numbers to reflect the more typical scenario of a writer spending 70% time writing, 15% time revising edits, and 15% time revising tech review comments. Also, editors spend 70% of their time editing, and 30% copy editing. Technical review is a special case because it involves stakeholders performing the review.<\/P> \n
The last adjustment to capacity is to introduce a buffer. Donald Reinertsen points out in his book, \u201cManaging the Design Factory,\u201d that reaching 100% capacity is very difficult and actually results in overloading the system. We\u2019ve found that aiming for 30% of capacity has historically worked to help prevent overloads. So my next step is to reduce the capacity numbers by 30%.<\/P> \n
Writing is still the bottleneck in the system. The maximum throughput of help topics over a sprint will only be as much as 117, unless steps are taken to address the bottleneck.<\/P>\n
Identify Loops<\/B><\/P>\n
Finally I looked for any loops in the system. There is only one in our system. After technical review, a topic can go back to the writing stage if it was severely off-track and needed considerable revisions.<\/P> \n
This loop is of great concern because it goes straight to the bottleneck. Any topics sent back for rework decrease the throughput of the system. Therefore great care should be taken to ensure topics are written right the first time with minimal changes after technical review.<\/P>\n
Summary<\/B><\/P>\n
Now that this model is created we have a starting point for understanding our process. We have identified the bottleneck in the system and can take steps to improve it. We also have a high degree of confidence in how much throughput can be achieved over a sprint. Finally I must stress that in any model, it\u2019s important to use as much historical data as possible to keep it accurate. I hope this model and the steps taken to create it are helpful if you are considering constructing a similar model for a system of your own. <\/P>\n
Thanks!
David Chesnut
Content Lead<\/P><\/p>\n","protected":false},"excerpt":{"rendered":"
Over the last few months I\u2019ve been investigating how our team can improve our understanding of our documentation process, and how we might be able to make improvements using principles from Theory of Constraints. I\u2019ve also been reading David Anderson\u2019s book, \u201cAgile Management for Software Engineering.\u201d His book has great diagrams that model a system […]<\/p>\n","protected":false},"author":125,"featured_media":45953,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-7373","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"acf":[],"blog_post_summary":"
Over the last few months I\u2019ve been investigating how our team can improve our understanding of our documentation process, and how we might be able to make improvements using principles from Theory of Constraints. I\u2019ve also been reading David Anderson\u2019s book, \u201cAgile Management for Software Engineering.\u201d His book has great diagrams that model a system […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/7373","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/users\/125"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/comments?post=7373"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/posts\/7373\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media\/45953"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/media?parent=7373"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/categories?post=7373"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/devops\/wp-json\/wp\/v2\/tags?post=7373"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}