{"id":686,"date":"2012-02-23T10:01:29","date_gmt":"2012-02-23T09:01:29","guid":{"rendered":"http:\/\/leanmagazine.net\/?p=686"},"modified":"2024-03-15T15:18:50","modified_gmt":"2024-03-15T14:18:50","slug":"make-ready-agile-projects","status":"publish","type":"post","link":"https:\/\/leanmagazine.net\/lean\/make-ready-agile-projects\/","title":{"rendered":"Make Ready \u2013 the missing link in Agile projects"},"content":{"rendered":"

The Make Ready Process can be of great use to Agile software teams. Here Bent Jensen and Sven Bertelsen give an introduction, based on their experience of Lean Construction. <\/em><\/h4>\n

\"\"<\/a>
\n<\/em><\/p>\n

An every day situation<\/strong><\/p>\n

\u201cWhere the heck are those test data for this module?\u201d Sam asked.
\nSilence in the whole office, nobody seemed to have them.
\n<\/span>\u201cDid we request them from the client?\u201d he asked this time.
\nMore silence.
\n<\/span>\u201cAnd by the way, did we order SubSoft to assist us this week? I haven\u2019t seen them this morning. And where is the test version from HardCore on their damned new gadget?\u201d
\nA sigh from the corner \u2013 but no answer.
\n<\/span>All of a sudden question upon question comes up, and the whole developing process comes to a grinding halt. Waste of time all over the place.<\/div>\n

This is an every day situation which we can all relate to \u2013 nothing out of the ordinary. Sometimes you may also hear conversations like this one:<\/p>\n

\u201cI think we should take into account that two sprints from now we are going to add x functionality. Let\u2019s already now make sure we can easily integrate it into the architecture.\u201d<\/p>\n

\u201cNo \u2013 you should not think of that now. We are not supposed to do that in Agile development. Let us cross that bridge when we get there.\u201d<\/p>\n

Planning Ahead<\/h2>\n

It is definitely true that software can be over-engineered and be configurable to handle all kinds of more or less probable enhancements in a distant future. But it is equally certain that it has never been the aim of Agile development to make teams behave more stupidly than they actually are by deliberately ignoring knowledge that is available to them and to make precautions in due time. Teams with this approach are faithful to the letter of Agile methods but not to their intent. They can be compared to a group of scouts going on a hike who, when they start, know they will have to cross a river some time later on the trip. However, when one guy wants to bring some rope the others tell him to leave it at home, because \u201cwhen we get there, we will find a way to cross the river\u201d.<\/p>\n

\"\"<\/a><\/p>\n

Anti-planning Syndrome<\/h2>\n

More of something good is not always better. That holds true for most principles in software engineering. \u201cThe simplest thing that can possibly work\u201d does not mean \u201cIgnore everything you know\u201d but rather \u201cDo the simplest thing that may possibly work\u201d (in the context of your current knowledge).<\/p>\n

Overdoing this principle can lead to the \u201cAnti-planning Syndrome\u201d which can sometimes be seen in Agile development. We have recognized that Big DETAILED design upfront BDDUF is not good, because we can\u2019t oversee the complex nature of the problem anyway. But that does not mean we should not spend enough time to understand the core of the problem and design at least the outline of a solution we are going to apply, before diving in and starting to write code.<\/p>\n

Doing it Right<\/h2>\n

\"\"<\/a>So how much planning is optimal? One way to look at it is this: if your team are routinely modifying what has been planned in detail, then you are planning too much, too early. If, on the other hand, they routinely have to redo work or get stuck halfway through a task because they miss information, decisions or deliveries from others, you are planning \u2013 or rather preparing \u2013 too little.<\/p>\n

There has been a lot of emphasis on \u201cDone\u201d-criteria and making work really \u201cdone-done\u201d in the Agile team process. The other side of the process, \u201cOnly working on stuff that is really ready\u201d, has not gained the same attention, even though the consequences of starting work which is not ready is at least as costly as not delivering work which is not really done.<\/p>\n

Putting backlog grooming to work<\/h2>\n

To avoid the waste of starting work that cannot be completed, you may have to implement a process that will ensure that only ready work is undertaken by the development team. On a number of occasions we have implemented the Make Ready Process in Agile teams, to help them bring the stuff they need to cross the river.<\/p>\n

The Make Ready Process consists of a process similar to the development process in Scrum and other Agile processes. Make Ready starts with loosely defined user stories or other forms of functional requirements and ends with user stories ready to work on. The process is aimed at giving maximum speed in development, so when a user story is actually ready to be started, it is most likely to be completed in the current sprint.<\/p>\n

Guidelines show the way<\/h2>\n
\"\"<\/a>
Bent Jensen is Director and Consultant at the Danish agile consulting firm BestBrains. BestBrains primarily helps software companies implement faster and more effective ways to create software with a Lean and Agile foundation.<\/figcaption><\/figure>\n

The criteria for when a user story or a task is ready to work on, will differ from project to project. However some guidelines can be found in looking along the streams which feed the flow of work and make the work packages \u201csound\u201d. By a sound work package we mean a task that is in good shape regarding:<\/p>\n

Dependencies<\/span>
\nIs there any development work that needs to be completed before this should be done? Do we need to coordinate with other teams?
\nSkills<\/span>
\nDo we have the skills on the team to complete the task?
\nSpace<\/span>
\nCan we actually get to make the change. What is the state of the code we are looking at?
\nU.X designs <\/span>
\nDoes the User Story have an associated U.I design and workflow?
\nStakeholders <\/span>
\nIs there anyone that needs to be informed and involved in this user story that maybe later can disapprove?
\nWork ahead <\/span>
\nIs there anything coming later that this development work needs to take into account?
\nFollowing work <\/span>
\nAre the receivers of this work in place and ready to receive it?<\/p>\n

Stuff ready to work on<\/h2>\n
\"\"<\/a>
Sven Bertelsen has worked for 40 years as consulting engineer and project manager and has been partner in NIRAS for 25 years. Today he is an external lecturer at the Danish Technical University as well as working as consultant.<\/figcaption><\/figure>\n

In practice this means there is a perspective on the projects that have a range of 4\u20138 weeks. It is not focussed on detailed planning, but on making sure there is stuff ready to work on when the time comes. And here we are not only looking at previous work but at all the prerequisites for the task \u2013 internal and external. By \u201cready\u201d we mean really ready with no exception or maybe. A smaller group will usually be responsible for the Make Ready process. Someone from the customer side will ensure the needs are well understood. A technical lead or architect will together with developers make sure we can actually do the work in the code. Developers may spend time making a spike to outline a solution. UX designers may work on high-level designs and people from other teams may participate to ensure that work between teams is coordinated.<\/p>\n

The Core of Coordination<\/h2>\n

The group should have joint responsibility and their performance should be monitored. A reliable flow of work is the key to higher productivity, shorter development time and lower costs. The process will usually we supported by a weekly meeting and progress will be tracked on a task board especially designed to visualize the make ready process. Often this process has its home in a development team, but on multiteam projects, the Make Ready Process and associated meetings belong to the overall project and are the core of coordinating several Agile development teams. A general question at all sprint and scrum sessions should be \u201cIs this task ready\u201d, and \u2013 if not \u2013 \u201cBy whom and when will it be so?\u201d More from this inspiring initiative will be coming up in our consultancies and in future editions of Lean Magazine.<\/p>\n

Download PDF-version of article: Make Ready PDF (2929)<\/a><\/strong><\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

The Make Ready Process can be of great use to Agile software teams. Here Bent Jensen and Sven Bertelsen give an introduction, based on
\ntheir experience of Lean Construction.<\/p>\n","protected":false},"author":21,"featured_media":690,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17,59,5,83],"tags":[36,6,29,30,28],"_links":{"self":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/686"}],"collection":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/users\/21"}],"replies":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/comments?post=686"}],"version-history":[{"count":35,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/686\/revisions"}],"predecessor-version":[{"id":1132,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/posts\/686\/revisions\/1132"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media\/690"}],"wp:attachment":[{"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/media?parent=686"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/categories?post=686"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/leanmagazine.net\/wp-json\/wp\/v2\/tags?post=686"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}