One of the staple technical practices of agile software development is Continuous Integration (CI). A continuous integration environment provides fast feedback on the state of your code. In a typical configuration, the CI tool is configured with a "job" that monitors the source code repository for commits. When a commit is made, the job:
What we have to say, what you want us to hear.
That’s how our blog works. It’s interactive. Let’s learn together.
Recently, a friend and I were sharing our love for the movie Groundhog Day. In this movie Phil, a disgruntled, cynical weather reporter (played by Bill Murray) visits a town to report on the emergence of the groundhog and whether this indicated 6 more weeks of winter. Of course, Phil has a terrible day and everything lives up to his cynicism. When he awakens the next morning… it is Groundhog Day all over again. Phil gets to live the same day over and over again… until the experience forces him to grow into a better version of himself.
This reminiscing got me to thinking… what lessons are suggested by Groundhog Day that help us in our roles on software development teams…?
Does your software team feel like it is on a hamster wheel? Maybe delivery pressure has been high for a long while, or there is a constant stream of support work to be done… so it's just "heads down and keep going". This way of working can be seductive… after all, we are getting things done and responding to "what's wanted from us". After a while, it becomes habit, our familiar way of working. Is there a better way? And if so, how do we get there?
When I first learned* about Scrum, the trainer provided us with some "rules of thumb" for planning our time during a sprint. As we started putting Scrum into practice, we applied these rules of thumb… but also encountered shock and horror from outside the team about how much "overhead" was involved. The arrival of Ken Rubin's recent blog post, How Much Time Should Each Scrum Practice Take? reminded me of these early experiences. In this blog post, I reflect on the perception vs. reality of this "overhead".