photo credit: Anne
I was recently reminded of two things I already knew. I suspect you do too, but I'll share them anyway to help us remember.
Thing one: Getting back to basics is a good idea.
I spent the week after my Coast Guard retirement reviewing the basics of Agile software development to prepare for the Project Management Institute's "Agile Certified Practitioner" exam. Although I'd been in the trenches leading an Agile project every day for the past 18 months, I was surprised at how useful it was for me to take a step back and review the basics. Then I remembered that I had the exact same feeling as a pilot when I used to spend one week a year away from the day-to-day work to instead focus on the basics of being a professional aviator. This is something the Coast Guard did right: no matter how many flight hours or how many years of experience a pilot has in the cockpit, they still spend one week a year at Aviation Training Center (ATC) Mobile Alabama focused on being a professional aviator. We get back in the books and back into the simulator to hone our skills. We get back to basics.
That rhythm had always been part of my operational career: taking a periodic break from operating to get back to basics. But I hadn't done that in my final staff assignment. There was plenty of training required to become an acquisition professional. Then there were forty hours of professional development required each year to maintain currency. But in my final tour at headquarters, I never took an entire week away from producing to focus on reviewing the basics the way I did as an operational pilot. But once I retired, I spent the first week of my transition period immersing myself in the basics of Agile software development. I found myself wishing I'd done it earlier. The week re-energized me professionally, the same way I was energized at the annual pilgrimage to ATC Mobile. So what's the lesson for me? In the future, I need to consider setting aside a week a year to focus on the basics of my chosen profession. I know, sharpening the saw needs to be something that's down more than once I year. I get that, and I do that. But the experience reminded me of the value in engaging deeply over the course of a week to re-connect with the basics of my profession.
I was also reminded of something I would have put to use immediately if I hadn't just turned the reins of the project over to someone else. What was that thing?
Thing two: Don't start something unless you plan to finish.
This lesson is going to be a bit specific to folks in the Agile scrum world, but if you bear with me, I think there may be an underlying pattern with broader applicability as well. Agile scrum methodology divides work into releases that are completed in timeboxed iterations called "sprints." The amount of work planned is based on the expected velocity (capacity to do work) of the team. The sprint plan includes only user stories that can be finished during the sprint. That's basic agile stuff, and that's what my team did.
But while executing a sprint, even a a short, two-week sprint, sometimes things don't go as planned. External factors may keep planned work from getting done during a sprint. Some work might be completed earlier than expected and some things might take longer. Reality happens.
But here's the reminder that hit me like a two-by-four:
Team members do not start user stories they cannot finish in a sprint.
Yes, that sounds obvious. But I was surprised how easy it had been for my team to break this basic rule. If a team member completed everything they thought they could contribute toward finishing the stories planned for the sprint, they started work on stories they expected to be part of the next Sprint. We were working from a groomed product backlog, and there was little question that the story they were working on would be in the next sprint. They were starting important and valuable work that would eventually have to be done.
But I allowed them to start it knowing they were not going to finish it. Once not finishing user stories became acceptable, we started losing the satisfaction that comes from ruthless prioritization to define a sprint's worth of work, then working together as a team to get it done.
It's natural for a seasoned professional within a team to look for things where his or her specific expertise can be most efficiently put to use. If there are no more of those tasks left in the work of the current sprint, it's natural to want to get a jump on the work of the next sprint.
But after taking another look at the basics, I'll do things a bit different next time. Before starting stories that can't be finished in a given sprint, I'll encourage team members to use their capacity to help others finish planned stories. Or if we're going to bring additional stories into the sprint, we'll do so only if it can be finished. Perhaps an existing story can be divided into smaller chunks so that some part of it can be finished within the sprint.
By allowing the dev team to start work they knew they couldn't finish, we created some tracking and measuring challenges for ourselves. But much more importantly, we lost some of our discipline around finishing what we started. Rather than start another story that can't be finished in a sprint, an agile team should use any excess capacity to complete planned stories. If that work is outside the person's specialty, that's okay. The cross-pollination will yield long-term benefits by broadening the individuals skills and helping the team work more effectively.
This isn't meant to be an indictment of me or any of the members of the team. I was amazed at how we'd managed to be doing most of the basic things right. But in the future, I will have a much greater awareness of the need to make sure team members don't start something that can't be finished in a sprint.
Starting only what one can finish might be good for more than just agile software development.
Why start unless you plan to finish and deliver something awesome within the constraints you know exist?