{"id":153,"date":"2014-02-24T13:44:04","date_gmt":"2014-02-24T18:44:04","guid":{"rendered":"http:\/\/sites.miamioh.edu\/itservices\/?p=153"},"modified":"2014-02-27T16:49:31","modified_gmt":"2014-02-27T21:49:31","slug":"agile-benefits-part-2-frequent-releases","status":"publish","type":"post","link":"https:\/\/sites.miamioh.edu\/itservices\/?p=153","title":{"rendered":"Agile benefits – Part 2 – Frequent releases"},"content":{"rendered":"

Another aspect promoted by Agile is the concept of frequent releases. \u00a0To demonstrate this, I’m going to draw on a real, current project that I’m involved in. \u00a0In this project, we’re developing a set of applications that contain approximately 15 major features between them. \u00a0While there is a basic framework that ties them together, most components are relatively independent.<\/p>\n

Waterfall Approach<\/h3>\n

With the project example above, we took a relatively normal waterfall approach. \u00a0We started with gathering requirements, then created a design, did a lot of development and are now testing. \u00a0The project timeline looks something like the following:<\/p>\n

\"Traditional<\/p>\n

As is typical with long waterfall projects, several pieces work as expected but a number of issues have been found in the testing phase that are requiring considerable rework. \u00a0Some of these issues are due to mistakes made back in the requirements gathering\/design phase of the project. \u00a0Since the project is being developed as a single, monolithic development, almost all aspects have to be delayed waiting on the rework of a few pieces that have problems.<\/p>\n

The first pieces of this project started to move into production in January – 16 months after the project began. \u00a0During that entire 16 months, the University gained no benefits from this project – no clients could use any of the work that had been worked on in the project.<\/p>\n

Agile Approach<\/h3>\n

Now, let’s look at the same project and same timeline but using an Agile approach. \u00a0With Agile, you organize the work into sprints (usually 2 weeks long) where you work on and complete<\/em> a certain number of pieces of the overall project. \u00a0At the end of each sprint, the work has been designed, developed, and tested and is ready for production. \u00a0This requires a number of cultural shifts in the way we do work at Miami including the involvement of clients throughout the project to gather requirements, perform testing, and sign-off on completed work.<\/p>\n

While work is completed every two weeks using Agile, it may not be in a form that’s ready for release to the general public. \u00a0Typically, applications are released after a set of sprints have produced a usable solution.<\/p>\n

Here’s a possible timeline for the same project with the same timeframe but using an Agile frequent release approach:<\/p>\n

\"Agile<\/p>\n

Note in this timeline that clients are able to use the first pieces of the project approximately 13 months before they could in the waterfall timeline. \u00a0Any problems that are found that require rework only delay the parts that come after what has already been released. \u00a0In addition, due to the increased client involvement and testing, rework issues should be caught earlier before they impact other aspects of the project.<\/p>\n

What if the project were cancelled?<\/h3>\n

One more benefit of frequent releases comes in the case where the project is cancelled or put on hold in the middle of the project timeline. \u00a0This could happen because of changes in business requirements, a realization that this project is requiring more resources than originally estimated, or a number of other reasons.<\/p>\n

Below is a view of our project using the waterfall method if the project were cancelled 12 months into the project.<\/p>\n

\"Waterfall<\/p>\n

Note in this case that the project was cancelled before any components were released. \u00a0Due to this, the work completed in the first 12 months of the project are completely wasted.<\/p>\n

Now, let’s look at the same scenario using an Agile frequent release strategy.<\/p>\n

\"Agile<\/p>\n

In this case, some work is still wasted, but only about 4 sprints worth (8 weeks) instead of 12 months. The University still gets benefit out of the 11 features that were released prior to the project cancellation.<\/p>\n

There are cases where projects are allowed to continue due to the work that has already been spent but which should probably be cancelled. \u00a0Agile gives the University more flexibility to cancel projects that may no longer be in the University’s best interest.<\/p>\n

Summary<\/h3>\n

Historically, IT shops have relied on large, monolithic releases at the end of a project to accomplish change. \u00a0Redesigning our project plans to allow for frequent releases (whether you’re using sprints or not) can have real, tangible benefits to the University community and can help projects be more successful. \u00a0When you undertake projects in the future, think about dividing up those projects into smaller chunks that can be released piecemeal and early on. \u00a0The benefits to your clients and the University community may be significant.<\/p>\n","protected":false},"excerpt":{"rendered":"

Another aspect promoted by Agile is the concept of frequent releases. \u00a0To demonstrate this, I’m going to draw on a real, current project that I’m […]<\/p>\n","protected":false},"author":699,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_total_topic_count_hidden":0,"_bbp_total_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"_s2mail":"yes","footnotes":""},"categories":[6,4],"tags":[],"class_list":["post-153","post","type-post","status-publish","format-standard","hentry","category-how-we-work","category-it-news"],"_links":{"self":[{"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/posts\/153","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/users\/699"}],"replies":[{"embeddable":true,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=153"}],"version-history":[{"count":0,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=\/wp\/v2\/posts\/153\/revisions"}],"wp:attachment":[{"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=153"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sites.miamioh.edu\/itservices\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}