![\"Project](\"http:\/\/www.managerjs.com\/blog\/wp-content\/uploads\/2015\/04\/2015-04-10-golden-triangle.png\")
<\/a><\/p>\n(I made the triangle golden because it\u2019s THAT important.)<\/p>\n
That senior manager\u00a0taught me this:<\/p>\n
\u201cOn Time\u201d is as basic as following this rule: Always insist that the person requesting to change one aspect of the triangle also tell you how the other aspects of the triangle are to change in order to maintain plan integrity.<\/p><\/blockquote>\n
\u2026 wow, after reading that sentence it doesn\u2019t sound simple. Read it a couple of times if you have to. It really is simple.<\/p>\n
For example: You want more feature (more scope): what feature would you like to drop? or What money do I get to hire more people? or What other project is going to slow down as we borrow their developers and testers?<\/p>\n
Commitments that have hard deadlines prefer to NOT change the Schedule<\/h2>\n
The only thing remarkable about a hard deadline commitment is that you can assume the stakeholders are more willing to change scope and resources than they are to change schedule.<\/p>\n
For example, when a key feature was to be released it wasn\u2019t translated into all the languages we wanted. It didn\u2019t meet scope. The key stakeholder made a choice: ship it now and we\u2019ll catch up on those languages.<\/p>\n
Other than the preference to keep schedule constant, a hard deadline commitment should be no different than any other commitment. And even so, stakeholders may very well choose to sacrifice schedule anyway.<\/p>\n
Stakeholders want to choose<\/h2>\n
Even though it is uncomfortable to confront the fact that you can\u2019t have everything you want, when you want it, without spending any more \u2013 even though that\u2019s an obnoxious choice we all hate \u2013 there is something we hate even more: when someone else makes the choice for us.<\/em><\/p>\n
No matter how much you wish you could buy both cars, you would still prefer making the choice than having the dealer say, \u201cNo problem, we will deliver them both to your house next week.\u201d<\/p>\n
Only to have just one show up.<\/p>\n
A month late.<\/p>\n
Missed Deadlines? The Issue is Plan Integrity<\/h2>\n
When I heard the term “hard-deadline” it made me think of padding schedules and cutting out rounds of experimentation. Who knows, it might still involve some of that. But that\u2019s not the real story.<\/p>\n
It also made me think that on top of all the other inflexibility in the golden triangle now we can\u2019t change schedule either. Now I see that\u2019s not the case at all.<\/p>\n
The real problem is that we don\u2019t consistently maintain plan integrity. Things are added to the plan without forcing a decision about schedule and people. Some teams don\u2019t even have user stories sketched out for work less than a month away. How can you force a discussion about trade-offs when the plan doesn\u2019t exist? Or is so outdated that it can\u2019t make the trade-offs clear.<\/p>\n
Everyone needs an insertion ritual<\/h2>\n
Every person that makes commitments needs an insertion ritual. When someone asks you for another commitment then follow that ritual. It should force the new commitment to be viewed in context of existing commitments and forecasts.<\/p>\n
For example, a team mate had a simple board with sticky notes on it that looked liked this:<\/p>\n
\n\n
\n Developer<\/strong><\/td>\n Jan<\/strong><\/td>\n Feb<\/strong><\/td>\n Mar<\/strong><\/td>\n Apr<\/strong><\/td>\n May<\/strong><\/td>\n Jun<\/strong><\/td>\n<\/tr>\n \n Aaron<\/td>\n Proj1<\/td>\n Proj1<\/td>\n Proj4<\/td>\n Proj4<\/td>\n Proj4<\/td>\n Proj4<\/td>\n<\/tr>\n \n Jack<\/td>\n Proj1<\/td>\n Proj1<\/td>\n Proj5<\/td>\n Proj5<\/td>\n Proj5<\/td>\n Proj5<\/td>\n<\/tr>\n \n Brad<\/td>\n Proj2<\/td>\n Proj3<\/td>\n Proj6<\/td>\n Proj6<\/td>\n Proj6<\/td>\n Proj7<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n (See how all three aspects of the plan are represented and easy to reason about?)<\/p>\n
His insertion ritual was simple:<\/p>\n
President comes in with Project X and he\u2019s excited. Manager says, \u201cOK, that\u2019s two stickies. Here\u2019s the board. Where do you want them?\u201d The president doesn\u2019t want to give any of them up. Manager asks, \u201cWould you like me to add a couple of months to the board?\u201d No. \u201cWould you like me to add another row for a new developer?\u201d No. Finally the president nixes a project on the board and places his sticky notes. The trade-off is clear.<\/p>\n
A prioritized backlog of relatively sized work units facilitates the insertion ritual<\/h2>\n
Consider having an estimated backlog of work for at least the next 3 months. When someone asks to add something to the backlog make them pick its spot. Appraise them of the estimated completion date. For hard-deadline commitments I would also use a more conservative velocity estimate, perhaps one half normal velocity. \u2026 But I\u2019m jumping to solutions. I\u2019m a man AND a developer. Double Jeopardy.<\/p>\n
Who knows what other great ideas you will come up with. But I\u2019m pretty sure a backlog, priority, and estimates will be involved.<\/p>\n
Stay limber<\/h2>\n
If people need a hard deadline from you don\u2019t assume you have to ditch agile for something with more prominent planning artifacts. Hard deadlines are still very compatible with Agile development.<\/p>\n","protected":false},"excerpt":{"rendered":"
The length of a single task is notoriously difficult to estimate. But without an insertion ritual estimates don\u2019t even matter because no one consults them. It’s a free-for-all. Over a year ago I was part of a committee trying to improve our \u201con time performance.\u201d Our conversation took me back to the heady days of… Continue reading Your Plan Needs an Insertion Ritual<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":184,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[23,17],"class_list":["post-182","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-executive","tag-agile","tag-plans","wow fadeInUp","entry"],"_links":{"self":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts\/182","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/comments?post=182"}],"version-history":[{"count":4,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts\/182\/revisions"}],"predecessor-version":[{"id":188,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/posts\/182\/revisions\/188"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/media\/184"}],"wp:attachment":[{"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/media?parent=182"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/categories?post=182"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.managerjs.com\/blog\/wp-json\/wp\/v2\/tags?post=182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}