My First Agile Project: Go-Live – The Final Frontier
Originally published on AgileSoftwareDevelopment.com
We did it! The project I’ve been talking about all this time has finally gone live and is now being used in production. Pretty much everything worked fine on launch day as well, which was nice. :) In this installment of My First Agile Project, I’ll talk about the last week of the project and where we go from here.
The last weeks of any project are pretty hectic and this was no exception. Our last week was a weird one though as we were theoretically in a code freeze (more on that below), and we still had to finish final testing, and we had to be done by Thursday so our database admins could start the data conversion first thing Friday morning. We all pretty much ran around like chickens with our heads cut off all week but once Friday came a weird sense of calm had settled over most of us (it might have been a fog of fatigue or brain tiredness, it was hard to tell). The DBAs had run through the conversion process 29 previous times so while they were working, it wasn’t some new process. The conversion process ran like clockwork, even finishing a few hours earlier than projected, and on Sunday we began the final Go-Live steps.
Sunday morning when I got to work, there were still some final conversion processes going on so a couple of us got to the important work of setting up a big screen TV and some seating to watch the NFL playoff games that were going on later. Most of us didn’t end up watching much of the games but the Go-Live Lounge, as we called it, was a fun place to have a break. Also, Go Cardinals!
Semi-Frozen Code
During the final week, we had determined that there were a couple of smallish fixes that we would need to put in before doing any real work on the system. Of course we all wish these things would have been found earlier but these things happen. Because we were so paranoid about the data conversion process, we had done a code freeze and decided that we would do the conversion using the same code that had been used the week before. This meant that we would do the conversion on the same code, then update the code to include the fixes, then bring the system online. The fixes were important enough and small enough that we all decided it was okay. If something broke, we had backups anyway and could roll-back. We finished the conversion process early on Sunday, did the update, and brought the system online in the afternoon for “sanity testing”, just to make sure everything was working.
Sunday
Once the first testing was done, the team started putting real work into the system from the past days where everything had been down. This part took a lot of coordination. Since this is a billing system, we need to make sure people’s payments went in and nobody got into any trouble with money not being in their account because we had been down. We need to post payments, make sure all the money was distributed and invoices were generated so it would all look seamless. It’s a credit to everybody involved that I don’t think anything noticeably wrong went out to customers.
I ended up being at work 11 hours on Sunday and others were there longer than that. I shudder to think how little sleep our DBAs were running on. Luckily our management had made a big trip to a nearby warehouse grocery store to stock up on a table full of bad-for-our-health but delicious goodies to help keep our batteries charged.
Monday
We were all back at work Monday morning as well, to make sure everything looked okay and to start our list of things to fix. We put a couple of minor fixes in Monday afternoon but nothing too ugly. I think the worst thing we forgot was that I left the wrong starting check number hardcoded into my code so the first batch of checks were numbered incorrectly. Luckily, the fix for that ended up being a better solution than we had originally written so it worked out alright. Monday evening our Product Owner made the final decision to go ahead with the new system and not roll back to legacy. In celebration a coworker played the Peanut Butter Jelly Time song over our building PA system (an inside joke on the team), without knowing that our CEO and Senior VP were still in the building. They know us though so I don’t think it phased them.
Tuesday
Tuesday was perhaps the most nerve-wracking day of all, being the first day people would be back at work and using the system for real. It doesn’t matter how much you test or how comfortable you are with a system, the day people start really banging on it and seeing your stuff in action is fairly frightening. I found an issue or two with some of my stuff that hadn’t been exercised enough but overall nobody found anything especially ugly.
Thursday
Thursday was the first day where we went back to Scrum for real. We did a 15 minute stand-up meeting in the morning and had our first Sprint Planning meeting that afternoon. Boy, it felt good to be back to planning and sprinting for sure. We’re going to do 1 week sprints for the next couple of weeks to take of some things we pushed back to after Go-Live. We had a fixed deployment night of Wednesday so anything we want to get in has to be done and tested by then. Because of this I don’t think 1 week sprints will work for us long-term. By the time we do a planning meeting, work, and test our changes we won’t be able to get a lot done in a week. Our plan is to move to 2 week sprints in a few weeks so we’ll be able to compare the two approaches.
The Future
Our plans from here on out are far from decided. The team knows what we would like to do but we’ll have to see how much influence we have over things in the coming weeks. What we hope to do is do our 1 week sprints on this project only for a few weeks. Then we’ll move to 2 week sprints and start moving in tasks from our other long-neglected projects into the plan. The big benefit of this plan that I’ve tried to explain to management is that we can work on multiple things at once, or put all of our effort toward one thing. We’ve got maintenance tasks to do, new stuff to build, and a big upgrade coming before too long. A multi-project Scrum plan seems like it’ll work very well. But we have to deal with the fact that we may very well have lost enough credibility with the exploded timeline of this project that our options are limited. I hope not though and the team and I will sure fight for our vision.
Now that this project is over, I’m going to change the focus of this column as of this installment. I think this is going to be the last My First Agile Project. Next week I’ll return with a new name (suggestions welcome) and the column will be following my team as we navigate the changes to our status quo from the past year and a half. I hope to document the plan as I described above, as we move to multiple projects, but whatever happens you’ll hear about it if you stay with me.
Thanks for reading My First Agile Project. If you missed any of the past posts, there’s a handy table of contents to the whole series below. I’d love to hear what you think in the comments below. One of the best things about writing this series is the great comments people have made. Thanks again and Stay Tuned next week. Same Agile Time, Same Agile Channel!
My First Agile Project Series
Part 1: Doing 80%
Part 2: Inception & Planning
Part 3: Viral Videos and Bad Jokes in Scrum Demos
Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Part 5: Our Top 5 Agile Mistakes
Part 6: The First End of Our Project
Part 7: Adventures in Agile Testing
Part 8: 9 Things We Disliked (and Liked) about ScrumWorks
Part 9: Choosing A New Tool – VersionOne
Part 10: 5 Important Issues For Teams
Part 11: A Tale of Two Dark Clouds
Part 12: The Good, The Bad, and The Ugly – Our Retrospectives
Part 13: Reflecting on The Decline of Agile
Part 14: Did We Need A Coach? Does Anyone?
Series Review: So It’s Come To This – The Year In Review
Part 15: The Last Mile
Part 16: Go-Live – The Final Frontier
You should follow me on Twitter here!
|
|
