Effective Programming

where agility meets computer science

May 13, 2020 - LB

Teamshare

Mindshare, but for teams

Somewhat related to my Team First post, heres an idea for an experiment aroiund time management that considers the team, development, and individuals by explicitly disignating time for meetings, pairing, and work - largely in the name of shared understanding and maximizing team effectiveness given asynchronous, remote work. I’ve alluded to it but to be clear, my thoughts are specific to software developers but if that doesn’t apply in your case, feel free to extend this idea to include other types of work as well and let me know how you did it!

  • 0-1h daily team meetings
  • 2-3h daily mob or pairing
  • 4-6h daily problem solving

Team Meetings

I think team meetings are important - especially when you throw remote into the mix. I would go out of my way to levelset that developers should plan to spend spend some nominal amount of time, everyday, meeting with the team as a whole. I know time spent in meetings can be a hot topic and I wholeheartedly agree it needs to be managed but I don’t find it helpful to simply go into dark, async mode when meeting time gets abused. Admittedly, I won’t dig into what these meetings should focus on as part of this post but if it isn’t obvious, I may reconsider in the future.

Mobbing / Pairing

The 2nd practice I’d heavily advocate is for some sort of team dependent time set aside everyday for pairing or mobbing on work together. I don’t personally like broad stroke agreements that require pairing on every story but again, I don’t think the opposite end of the spectrum is any better. I like pairing. Some of my best learning came while I was pairing. Pairing is important. It need not make up 100% of your day but I’d advocate that it should be a serious consideration in every developer’s day.

For instance, after standup, I’d advocate that the developers take 2 hours to pair off and present the work they are doing to each other. Don’t have to show everyone, everything, everday but you do need to work side-by-side regularly. Consider this a sharing opportunity. Wouldn’t be a code review as much as a walkthrough of problems and considerations. Would be an excellent time to showcase novel techniques, ask questions or even write some code together via test driven development. I wouldn’t mandate what happens as part of those sessions unless folks were just lost but I would ask the group to retrospect the idea behind this allocated time regularly so as to help each other maximize the value they are getting from this time together.

Getting Things Done

Finally, I’d try, on average, to help make sure the developers are able to spend, on average, at least 60-70ish% of their total time actually purusing stories and building solutions. I don’t really care whether this is done individually or together but for sake of this post, we can assume indivually as I think that may be more tenable for most organizations. Again, not digging into this phase here as much as just advocating to consider the proposed rule of thumb first. Will have to followup with tips on how to be most effective in this model.

Wrap Up

At the end of the day, developers spend some amount of time getting on the same page with the team. Spend some amount of time sharing and clarifying practices with each other and spend some amount of time (the bulk of their time?) applying what they’ve learned to the problems they’ve picked up off the board.

Admittedly, this post leaves many questions unanswered and that is, in part, on purpose. Consider, just for a moment, that all I’m really advocating is to levelset that some amount of time ought to be spent on these activities … and without further information, letting the individuals on the team find a way to maximize their effectiveness under said guise. This is not always how I approach things - I tend to consider outcomes and then finally land on practices but in this case, I think it might be OK to consider an experiment such as this for a month or so to see what comes out of it. Good luck if you choose to try it, and please, do let me know what you learn!

What do you think? Give me some feedback if you have a chance!