mattgrommes's blog
Welcome to the newest installment of My Agile Team, my team's ongoing series of misadventures in trying to get better at Agile development. This time around, we're still playing Whack-A-Mole on the list of bugs we've encountered since Go Live. We stomp one out, another pops up.
What I'm going to discuss this time is our approach to trying to fix these critical bugs while maintaining at least a semblance of our Agile nature. It's hard to do a planning meeting and decide on what to work on when you've got new things popping up and old things dragging on. Read on for more on how we're planning in the midst of firefighting production bugs.
Bookmark/Search this post with:
Welcome to the second installment of my new series, My Agile Team, where we're following my team's progress in getting more Agile and in moving from one project to multiple projects. Right now, we're still trying to put out fires and finish up the big project. We hope to start adding in things from our other projects in a couple more sprints.
The fires I mentioned are our term for the emergency stuff that pops up and has to be taken care of Now. This is usually things that customers will see; their bill being the most important. These seem to still pop up every couple of days so we have to drop our Sprint tasks and take care of them quick, fast, and in a hurry as my Dad says. It looks like we've probably stomped out the bulk of the underlying problems causing the most important fires so this coming week I'm hoping will be a little less crazy (of course now that I've said that, we're in trouble). Once we all have some distance on these issues my goal is to do a deep retrospective just on these issues that have come up since Go Live and see if we can root out anything we should have differently for next time.
One thing I'm struggling with right now is trying to get the Higher Ups to understand why we shouldn't use real time estimates on the stuff left on the big project. Read on for my thinking on this and how I'm trying to influence things.
Bookmark/Search this post with:
Hello and welcome to the start of my new series called My Agile Team here on AgileSoftwareDevelopment.com. This series is a sequel of sorts to the My First Agile Project series. From here on out, the plan for this bunch of articles is to follow my team as we move from being on one big project where we (mostly) used Scrum to being on multiple projects where we will (hopefully) really use Scrum. We all intend to learn from our mistakes the first time around and to adhere more closely to the recommendations that make Scrum work so well. But, as everyone knows, when the rubber hits the road even the best of intentions can go by the wayside, accidentally or intentionally.
In this first post in My Agile Team, I'll talk a little bit about the team's plans and what happened during the first 2 weeks of our transition. In our last project, Scrum was brought to us by the vendor and our management signed on fairly enthusiastically. This time though, we're on our own to implement and stick to the plan, at the same time moving from a big project we all worked on to multiple maintenance projects. We know what we want to do, but will that turn out to be what management wants to do? Will we even be able to make the transition successfully? Keep reading to find out!
Bookmark/Search this post with:
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.
Bookmark/Search this post with:
Welcome back to My First Agile Project. I spent a few weeks doing as little as possible for the holidays but now that I'm back at work we're starting to head toward the actual end of this project. For real this time; barring any natural disasters, stress-induced insanity, or alien invasions we should be live by the end of the month. So the next couple of posts in this series are going to be about the end of My First Agile Project as we complete this and transition to whatever comes next.
As I've discussed before, we've missed a couple of other deadlines in the past but this one just feels different. On past deadlines, when we thought we were close enough to done we'd find a 3-day weekend and try to decide if we could finish everything by then (converting all of our old data takes a long time so we have to basically shut the company down while we do it). Of course, things come up and we're too optimistic so when it comes down to it we've had to abandon the previous dates. We thought we were going to be able to do it at the end of November but again we missed it due to changes being made at the last minute and unforeseen problems. This time though, our list of remaining issues is small enough that when we decided on this new date we were all a lot more comfortable with it than in the past. This feels like an actual date of completion for everything, not a deadline we're rushing to meet.
Bookmark/Search this post with:
In the spirit of the season (Year-End Recap and Top 10 List season I mean), in this episode of My First Agile Project I'll be going over the previous posts in the series and giving some behind-the-scenes comments. If you've read some of the series, keep reading for more you might like. And if you haven't read any of my posts before, I've read some very kind things about the series on readers' blogs so you don't have to take my word for it when I say you will like it. If you don't like it, I'll give you your money back guaranteed.
Bookmark/Search this post with:
In the previous part of My First Agile Project I talked about the recent tempest in a teacup regarding the failure and fall of Agile. A commenter on that post ended up crystalizing something I thought during the reading of various posts on the subject; should we have hired an Agile Coach to help us start going on Agile? This is an important question for me in trying to figure out what we could have done better as well as for other teams starting out on Agile as well. This is an issue for Agile itself as well, whether a coach is needed for teams to succeed or not. Read on for more on this question and whether I think all new Agile teams need a coach.
When we started this project, our vendor brought Scrum to us. They recommended we buy Ken Schwaber's Agile Software Development with Scrum and had one of their people give a presentation about Scrum. After that, we were on our own. Most of us read the book, me included, but none of us apparently internalized all the important parts of Scrum. As I've mentioned before, we didn't do a good job of keeping track of our backlog or estimating things to know how much work we were adding to the project. These two omissions were the main reasons we got offtrack so badly without knowing it.
Would a coach have helped us with this?
Bookmark/Search this post with:
Recently James Shore wrote an article called The Decline and Fall of Agile where he talked about how Agile, and Scrum in particular, is failing many companies. The main reason I started writing this series of articles on our team's experiences was to help myself examine why we'd had such a hard time with Scrum in various ways. In this part of My First Agile Project I'm going to go through Mr. Shore's article and compare it to our experiences.
In the article, Mr. Shore focuses mostly on the engineering aspects of Scrum, or lack thereof. In our experience, Scrum's lack of proscriptive engineering processes is hardly the biggest problem. It could be that we haven't had enough time to run into the walls of difficult-to-manage code that he's seen but thanks to some of the other problems we've had with shifting requirements and the like, we've all revisited chunks of our code during the project and we aren't slowing down because of it. Read on for more on Mr. Shore's essay and how I see it through the lens of our project. It may be that Agile is declining, but if so it isn't for the reasons he's seen.
Bookmark/Search this post with:
Welcome to Part 12 of My First Agile Project. Inspired by Peter's recent 5 minute retrospective article, this time I'll be talking about our retrospectives, which we termed our GBU or Good, Bad, and Ugly meetings. Our vendor brought these GBU meetings to us, along with the Scrum methodology, and while we weren't doing everything by the book (not a surprise if you've read any of the other parts of this series) I think they were very valuable and still light-weight and easy enough to be adapted for other teams looking for retrospectives.
Read on for more on how we ran these meetings, what we got out of them, and what we'll be doing differently in our next meetings.
Bookmark/Search this post with:
And now, a story about physics. I'll get to programming in a second though, I promise. In 1900 Lord Kelvin (of the Kelvin temperature scale among many other things) spoke at the meeting of Royal Institute in London. There was a consensus at the time that physicists had succeeded in discovering almost everything knowable about the universe. Kelvin was one of the believers in this idea and also one of the most powerful and influential men in science. His speech at the Institute was on 2 'dark clouds' he saw on the horizon, 2 experimental results that didn't fit in with what they knew at the time. Since they thought they knew almost everything, Kelvin was confident that these clouds would be found out and moved past sooner rather than later. What he couldn't have known was that within the next decade, those 2 dark clouds would revolutionize not only physics but would literally lead to the invention of our modern world, including the computer you're reading this article on.
Read on for how this story relates to Agile projects. Although if you've been on a sufficiently large project, you can probably see the connection between things on the horizon that seem small and end up having a huge influence on your project. In this part of My First Agile Project I'll talk about a part of our project that seemed like a 'dark cloud' and ended up being a tornado tearing through our town.
Bookmark/Search this post with:
RSS feed
Subscribe on Kindle