![\"\"](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/agile-methodology.jpg\")
<\/p>\n<\/p>\n
As I was reading\u00a0Ed Horley\u2019s<\/a>\u00a0fifth blog post in his series on IPv6 planning and deployment best practices<\/a>, it made me think about how organizations shouldn’t wait to get started.\u00a0 Organizations should not delay their IPv6 deployment by trying to attempt to design it perfectly from the start.\u00a0 Large and small organizations tend to fall into the traditional linear \u201cwaterfall\u201d thinking when it comes to deploying information technology.\u00a0 Their desire to get things right the first time and anticipate all future problems halts their forward progress.\u00a0 This got me thinking about how a more “agile” approach could be used to speed up IPv6 deployments.<\/p>\n The\u00a0Agile Methodology<\/a>\u00a0is an approach to project management that is typically used in software development.\u00a0 It uses an iterative approach of smaller work amounts called \u201csprints.\u201d\u00a0 This methodology originated from a paper written in 2001 titled \u201cManifesto for Agile Software Development<\/a>\u201d that documents,\u00a0according to the authors,\u00a0how software should be created.\u00a0 This manifesto is also complimented by a list of guiding principles titled \u201cPrinciples behind the Agile Manifesto<\/a>\u201d.\u00a0 This agile methodology helps to rapidly create early versions of software that deliver the essentially features and then over time improve the software with user feedback.\u00a0 The goal is to ship minimum viable working software early and not wait for a fully functional product with all the features before you start to hear from customers.\u00a0 If you try to anticipate all the features a user may want, you could waste valuable time writing software that isn\u2019t as valuable to customers as you thought.\u00a0 You want customer input sooner (and throughout the process) to speed up creation of the product and adapt\u00a0to changes.\u00a0 This will help you go to market quicker and deliver more user-desirable features earlier in the product lifecycle.<\/p>\n The mantra of many Silicon Valley startups \u201cfail fast, fail often<\/a>,\u00a0fail forward<\/a>\u201d further illustrates the concepts of this new methodology. \u00a0It seems to say: “We want to have adaptive planning with quick feedback cycles because we do not know what the future holds.” \u00a0Humans have shown that we are bad at predicting the future and at anticipating market demand.\u00a0 For example, just ask an IPv6 expert what year they expect IPv6 to become mainstream.<\/p>\n Many times people start implementing IPv6 without\u00a0fully\u00a0knowing\u00a0the intricacies of the protocol.\u00a0 This may be an acceptable approach and may be substantially better than waiting to deploy IPv6 until it is \u201cfinished.\u201d\u00a0 Consider that, even today, the IPv4 protocol is not finished evolving.\u00a0 Therefore, you cannot afford to wait until IPv6 is finished evolving before you start to move forward with deployment.\u00a0 Get started and adapt as your needs evolve and as the protocol becomes fully integrated into all network-connected devices.\u00a0 With IPv6, you want to have early delivery, flexibility to change rapidly, continuous improvement, and evolutionary development.<\/p>\n Agile methodology shares some philosophies with the\u00a0Scrum methodology<\/a>\u00a0for software development.\u00a0 Both are iterative and incremental approaches and they both extol the virtues of flexibility and agility and speeding up the development lifecycle.\u00a0 Scrum challenges the traditional linear and stepwise methods for managing projects.\u00a0 The traditional waterfall approaches lead to cost overruns, missed schedules, and products that were not fit for task or purpose.\u00a0 The product could take years to develop before it is first seen by the customers and well after it was too late to change.<\/p>\n One of the key principles in scrum is the concept of getting customer and user input early in the process and getting continuous feedback as part of feature testing.\u00a0 These \u201cUser Stories<\/a>\u201d drive the functionality and goals of the project and will then be broken up into much smaller tasks and assigned to the various team members (e.g.,\u00a0IPv6 transition\u00a0team members).\u00a0 Scrum methodology prescribes trying to achieve each of these within one sprint cycle.\u00a0 A sprint cycle can be anywhere from a few weeks to a month or more.\u00a0 The goal should be to try to keep the sprint cycles to a uniform duration that are not too lengthy.<\/p>\n When it comes to IPv6, there are many \u201cuser stories\u201d that would drive planning and deployment.\u00a0 Examples of IPv6-related user stories are:<\/p>\n Smaller, measureable goals is another agile method.\u00a0 You do not want to take on a large goal and then not measure success until completion.\u00a0 It is better to have smaller goals that lead toward the ultimate direction, but allow for measurement of success sooner in the process.\u00a0 An example of this is for organizations to start their IPv6 deployment by focusing on achieving a few simple tasks.\u00a0 Deploying IPv6 Internet connectivity to your DNS server, your web server, and your e-mail server are three short-term goals that are easy to evaluate success. \u00a0As we saw from the above list of user stories, a common agile approach to IPv6 might be to\u00a0start at the Internet edge<\/a>.\u00a0 Once you have had success on that initial goal, then you can move forward with deploying IPv6 internally within the enterprise.<\/p>\n The same agile methodology holds true for\u00a0IPv6 address planning<\/a>.\u00a0 You would not want to spend years working on the ultimate IPv6 addressing design that takes everything into consideration.\u00a0 By trying to make it \u201cperfect\u201d you will be delaying your start and delaying the time when you start to gain experience with IPv6.\u00a0 By creating an IPv6 addressing plan that focusses initially on the Internet perimeter, you are starting small.\u00a0 If you fail, you can easily re-address that smaller portion of your environment.\u00a0 Then you can apply these lessons learned toward your IPv6 addressing plan as you start to bring IPv6 into your core and internal WAN.\u00a0 By the time you are ready to start assigning IPv6 addresses to access networks and ultimately to end-user devices, you will possess deployment and testing experience.\u00a0\u00a0Ron Broersma<\/a>\u00a0(U.S. Navy\/SPAWAR) predicts that most organization will go through multiple iterations of their IPv6 addressing plan before they settle on their final design.<\/p>\n Another aspect of agile methodology is to facilitate collaboration between smaller self-organizing cross-functional teams.\u00a0 This is applicable to IPv6 because you do not want to solely create a team of network engineers to lead your IPv6 deployment.\u00a0 Deployment of IPv6 is not just a \u201cnetwork problem.\u201d\u00a0 Today, the Internet Protocol touches every facet of your enterprise.\u00a0 Servers, storage, facilities systems, mobile devices, wired and wireless networks, and embedded smart objects all rely on IP connectivity.\u00a0 Therefore, IPv6 will eventually touch every one of these areas.<\/p>\n The most successful IPv6 deployments will be performed by interdisciplinary teams that have\u00a0management support<\/a>\u00a0and representation from all business units.\u00a0 Organizations should take a page from how the U.S. government has structured their IPv6 initiatives. \u00a0For example, enterprises should create\u00a0IPv6 task force<\/a>\u00a0teams that have people from systems, software, network, and helpdesk departments.\u00a0 Having these different perspectives and specialties be part of the small and focused agile team will increase the likelihood of success.<\/p>\n Another aspect of agile and scrum methodologies is to avoid complexity and try to keep\u00a0Occam\u2019s Razor<\/a>\u00a0in mind.\u00a0 When it comes to IPv6, you will want to keep it simple,\u00a0dual-stack where you can, tunnel where you must<\/a>.\u00a0 You will prefer using\u00a0native IPv6 connectivity<\/a>\u00a0to the Internet and proceeding in a \u201csmall strokes fell great oaks\u201d approach to getting the job done.\u00a0 Your IPv6 deployment will likely be treated like an organization-wide program (i.e., a collection of many smaller projects) and will transpire over many years.\u00a0 Don\u2019t force complexity; IT systems are already complex enough.<\/p>\n Another area of avoiding complexity in IPv6 is to stick to several standard prefix lengths.\u00a0 The \/64 is the common prefix length that you will use virtually everywhere for interfaces (see\u00a0RFC 4291<\/a>\u00a0and\u00a0RFC 7421<\/a>).\u00a0 There may be a few other prefix lengths that you may use sparingly but \/64 should be the default prefix length.\u00a0 You might use a \/128 for loopback interfaces and you might entertain the use of \/127s.\u00a0 However, I would argue that you have plenty of \/64s and there is benefit of simplicity and commonality in keeping all prefix lengths the same across your entire networked environment.<\/p>\n From all of this, we can take away the idea that we should start sooner, rather than later, on our IPv6 deployment.\u00a0 Our planning and deployment strategies will likely change over time as our requirements and user stories change. \u00a0We should create small interdisciplinary teams that can accelerate the business impact of IPv6 sooner than with traditional linear approaches.\u00a0 We shouldn\u2019t be afraid to fail with IPv6 as it offers plentiful amounts of IPv6 addresses to adjust as needed.\u00a0 In today\u2019s busy IT world \u201ctime is of the essence.\u201d\u00a0 There is no time like the present to start using agile and scrum methodologies to accelerate your IPv6 deployment.<\/p>\n","protected":false},"excerpt":{"rendered":" As I was reading\u00a0Ed Horley\u2019s\u00a0fifth blog post in his series on IPv6 planning and deployment best practices, it made me think about how organizations shouldn’t wait to get started.\u00a0 Organizations should not delay their IPv6 deployment by trying to attempt to design it perfectly from the start.\u00a0 Large and small organizations tend to fall into […]<\/p>\n","protected":false},"author":321,"featured_media":3139,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[30,51,38],"class_list":{"0":"post-3135","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-dns","9":"tag-ipam","10":"tag-ipv6","11":"entry"},"acf":[],"yoast_head":"\n\n