The last two weeks at work have been some of the most fun in the past few years. A few months ago I moved from management back to my first love: deep technical work. In my new position I’m responsible (with a co-worker) for technical strategy, creating our Enterprise Architecture, and forward-looking technical projects. We’re also tasked with finding new ways to collaborate and take on projects as well as take a hard look to ensure that IT is supporting the rest of the business.
For some of these, we act as facilitators for IT projects, even though we aren’t in the management chain.
IPv6 has been one of my “back burner” projects for almost a year. There is a business mandate that we must have IPv6 connectivity to one of the inter-corporate networks by 1 April. A select set of our internal users need to have IPv6 connectivity to business applications that will only be available over IPv6 via this network.
To prepare for this, we had a need to ramp up IPv6 knowledge from almost nothing, to ready to plan a limited IPv6 deployment next month.
We decided to try a new project methodology (loosely) based on agile concepts: we performed IPv6 testing and deployment preparation as a “sprint”. We got 12 of our most senior system and network admins together in a large conference room with a pile of hardware, a stack of OS install disks, a new IPv6 transit connection and said, “Go!”.
No distractions, no email, no phone calls. Just 12 people off in a completely different building, in a big room with a pile of gear and the mandate to “explore IPv6” and learn enough to be comfortable planning a limited IPv6 deployment at the end.
It was great seeing people from different IT departments who usually specialize in Linux, MS Windows, VMWare, networking, security, etc. all come together to explore IPv6 on all these platforms, bring up services, test, find vendor bugs 🙂 and in general build a standalone IPv6 lab from scratch.
We truly did start from scratch; we started with an empty room, a bunch of tables and chairs, two pallets of PCs, assorted network kit, three boxes of ethernet cables and installation media.
Along the way, all of these people stepped out of their comfort zones, learned about each others’ specializations, and worked together for a common goal that we all created together.
At the end of the 2 weeks, we had a fully functioning dual-stack IPv4/IPv6 network:
- Routers and switches, firewall and IPv4/6 transit from a new provider
- Fully functioning Windows infrastructure: AD, DNS, DHCP, IIS, Exchange, etc.
- Linux infrastructure: DNS, DHCP, syslog, apache, Splunk, Puppet (mostly)
- Windows Server 2008 and 2008 R2, Windows 7 clients
- Linux Centos 5 and 6 servers and desktop
- MacOS Snow Leopard and Lion clients
All the results and everything we learned is documented in a wiki full of IPv6 configurations, hints and tips, debugging info, links to IPv6 info, lessons learned and plans for IPv6 next steps to production. I think we generated about 50-60 pages of new documentation along the way on IPv6, and about 6 pages of notes on the sprint experience itself.
The sprint wasn’t perfect, and we had a few stumbles along the way. But we learned a lot about how to run these kinds of sprints, and we’re pretty sure that we’ll have more of them in the future.
We also had two full weeks of face time with our colleagues from four sites in two states. In some cases we had never met each other in person, but had been exchanging email and tickets for years.
It was incredibly productive two weeks. We learned a lot about IPv6, each other and found new ways to work together.
Thuktun (Message) 
#1 by donna on January 25, 2012 - 9:21 pm
I thought I was your first love… sulk.
#2 by tomperrine on January 25, 2012 - 9:41 pm
You are! I was misquoted!