Communication, communication, communication
Over my many years as a software developer, leader, coach, and manager, the most important job function I stress is communication. I cannot think of a position where it is not vital to communicate, well and often, to some other individual or group. Your boss, your boss’s boss, and your customers want to know what you are doing and what to expect. And on a good team your peers want to know too.
Lucky for me, some of this comes naturally. Way back on the Jack Nicklaus 5 team at Eclipse Entertainment, we each had private offices not even next to one another. The team was comprised of a bunch of guys that had never worked with one another before. After all, we were the first employees of a brand new company. But to a man, none of us had any inhibition toward getting up and asking a question, soliciting feedback, etc. Meeting our contractual milestones meant meeting payroll for this young company.
Good Scrum Good
I learned of Scrum in the mid-2000s and quickly decided to take the certification course. What became obvious to me was not that Scrum was some panacea of process perfection. Rather, it was a tool to assist with the biggest challenge that faces every team, communication. Software teams in particular have to deal with the fact that they speak a different language and often work on [architectural/framework/plumbing] tasks that are not visible to anyone. The ideas in Scrum help to deal with the unknown factors of software development and make them a bit more tangible for everyone else.
So, I’m not going to get into any details of Scrum here, but I will say that not every aspect of Scrum works for every team. For example, I currently work on an eCommerce team. We have no software “product” that starts from nothing and ships at some point in time. There just isn’t some overarching release cycle. We do have a framework that is continuously refined, enhanced, expanded, sliced up, and launched again. We get requests from multiple sources across the company who compete for development resources. The iterative nature of Scrum has encouraged (successfully, I might add) the different areas of the company to coordinate and prioritize the requests as a collective and to have a level of expectation for when they will be delivered.
Bad Scrum Bad
There has been a growing discussion against Scrum in favor of continuous processes like Lean. One specific event within Scrum getting a lot of attention is the regular review meeting. Often, this meeting is lengthy and most attendees harbor frustration of “not getting anything done.” While I agree with eliminating waste, I will also point out that development teams are comprised of humans not doing repetitive tasks. This is not a factory.
It is a Utopian belief that the backlog will be properly filled with appropriately described and sized tasks always sorted according to the company’s priorities. That developers will take those tasks in order, execute according to the prescribed plan and move the tasks down the board. However, the more likely scenario is that this will work well for a few weeks and then OK for a few weeks and then really begin to breakdown. Humans just have a tendency to find “shortcuts” to a process and get lazy.
One of the primary purposes of the review meeting is to serve as a checkpoint for the process, to circle the wagons and make sure everyone is operating on the same page. This meeting does not need to take a long time. Every two weeks, we conduct a retrospective of the past sprint and review the tasks for the next sprint. We discuss tasks that did not go according to plan. We highlight what worked well and what didn’t. We discuss desired tweaks and act on them. We scan the upcoming tasks in case some re-estimation is needed. We do all of this in an hour and a half or less. That is a pretty efficient communication for a room of 10-12 people.
High five
Knowing that this team is built of people, the review meeting is also an ideal moment to just say, “Good job, everyone.” People need that. They need to know their work is appreciated and the team is succeeding.
Back at Eclipse, the owner David Stafford had a tradition when shipping a product. Each developer got a “ship.” Technically, it was a wooden knick-knack with sails mounted on a base, but it came with a trophy plate celebrating the product. I still have all of mine from 15 years ago. They represent a lot of hard work by a great team and great friends.
With today’s continuous release cycles, we have a little fun as a team. To celebrate the end of a cycle we pass around a bucket of Lego Minifigures. Everyone pulls out a random pouch to build and add to their collection. The figures decorate each member’s desk. Some stand on monitors; others pose in elaborate scenes.
In the end it all centers around the communication. Communication within the team and outside the team. If you dread the sprint review meeting, you might want to talk about it.