tag:blogger.com,1999:blog-356516183452551110.post8685792424754226462..comments2024-03-14T22:05:51.185-07:00Comments on Software Engineering: Readiness at the Starting Point Matters!Raja Bavanihttp://www.blogger.com/profile/03107697584076683320noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-356516183452551110.post-79793923124774799022013-10-30T02:31:19.646-07:002013-10-30T02:31:19.646-07:00Thanks David! Great insights! I agree - ensuring ...Thanks David! Great insights! I agree - ensuring that we have a 'learning organization' and adhereing to DoR are necessary. Else, POs may stay in their comfort zone of providing one liners (user stories) for Sprint Planning and rely on project teams to groom user stories when Sprint execution is in progress. That hurts! When this happens, the team goes through 'a frog in warming water' syndrome and burns out when the water boils!Raja Bavanihttps://www.blogger.com/profile/03107697584076683320noreply@blogger.comtag:blogger.com,1999:blog-356516183452551110.post-7300918570626602952013-10-29T07:23:28.825-07:002013-10-29T07:23:28.825-07:00A DoR normally refers to the state of a User Story...A DoR normally refers to the state of a User Story to either 1) enter Sprint Planning in the case of Scrum or 2) active development in the case of a Kanban-hybrid. However, your point is well taken. In the past we have developed a "Release Planning Exit Checklist" but we were careful to ensure that it was flexible because every project cannot be treated exactly the same. <br /><br />The scenario you present is not uncommon and is highly dependent on the maturity of the organization involved. A project that has been appropriately considered and thought about with a DoR to start Iteration 1 is great if you can get there. <br /><br />However, the second scenario you present could be fraught with risks for the team. Basically when a company says "I don't know what I want but I know I want it by X date" be VERY careful. There are 2 ways to approach this 1) have a Release DoR (to begin Iteration <br />1) and stick to it. I believe this is the point of your last paragraph. Not a problem here as long as the organization is on board understanding that the number of Iterations will be continue to shrink while you wait to gather the information and people needed to meet the Release DoR. <br />or <br />2) Begin without having all the answers to a Release DoR. Plenty of Agile projects begin this way and a large segment of the Agile Community prefer this method. Will there be more re-work than Method 1 above, yep. But this method has it's advantages as well. <br /><br />The key here is to A) ensure you have a "learning organization" and B) come up with an optional Minimum Release DoR that ensure just enough has been thought about to guide the first Iterations and allow product to evolve. This will come with some growing pains but this also allows your team to begin writing actual code and learn from the growing software versus waiting for the product to be "defined" without any working software. It's a line all Agile Organization have to learn to navigate.Dave Updikehttp://agileleankanban.comnoreply@blogger.com