Home > Software Development > Two Week Tetris Applying Otazo’s Truths to Managing Development

Two Week Tetris Applying Otazo’s Truths to Managing Development

Two Week Tetris

March 25th | 2010

Two Week Tetris: Applying Otazo’s Truths to Managing Development

Managing a development team is a lot like maneuvering falling blocks in Tetris; the blocks of work never stop, they often need to be rotated mid-course, and as you go the shapes don’t always easily match up.

Applying the “truths” from Dr. Karen Otazo’s book, “The Truth About Being a Leader”, is effective for meeting the challenges of coordinating development; it offers key advice for maximizing your figurative score. As team lead for the product team, I manage a two-pair development team that tackles fixes and features for our company’s products. Being an Agile shop, we use Test-Driven Development with paired programming and a Scrum sprint structure. The main responsibility of a team lead is to produce high quality software at the fastest sustainable pace. Using a modified Scrum process, we employ a two-week sprint system where the development calculates points (block of work) for each story (requirement / feature) from the product owner and ultimately commits to getting a chunk of points/stories done for that dev cycle. It is these blocks of work that come off feeling like Tetris with the goal to clear the stories from the task board getting them all to “Done” (Code Complete, Reviewed, and QA’d). Otazo’s truths on the Player/Coach role—sharing forward thinking and managing the mental bandwidth—offer insight into winning in a leadership role.

Maintaining the Player / Coach Role

One of the challenges of a team lead is the constant straddle of the Player/ Coach role. Karen Otazo summaries this with Truth 8: “Player/Coach is a Tricky Role, So Make Sure That You Do Both Well” and questions when you should focus on being a player and when being a manager, to maximize the team’s output. Our team’s paired programming format helps me integrate with the team and gives each developer a voice for their own creativity and innovation. When pairing, the team lead is in the player role and has to defend his code choices and be open to alternative approaches. Pairing provides the benefits of learning from the lead’s experience while fostering the best collective approach. In the management role, the focus is on tracking the stories that are being completed, keeping the queue full, and occasionally stepping in on a pair disagreement.

Shared Vision

One way I keep a successful flow of the task board is by sharing my vision of the events coming up next. Otazo makes the case for this with Truth 19: “Playing Out the Tape Helps Others Prepare for the Future.” Truth 19 argues effective leaders learn to fast-forward by establishing a vision of what they see the future being. During the development sprint this means steering in the right blocks of work and expressing what would fit best for the next block. The taskboard is also designed with this in mind. By having, in addition to the In Process portion, the On Deck stories for the next chunk of work and the backlog visible, developers can get a quick sense of what’s in the pipeline. Telling the team how I see the board playing out helps the team get more lines cleared and avoid the gaps that form as developers remain focused on a single work stream.

Fill Your Mental Bandwidth

I have found Otazo’s first truth to be both necessary and demanding ; “More-Responsible Roles Require More Mental Bandwidth.” Most of my responsibility comes down to keeping track of everything for the development space while mentally organizing the requirements to stand in for the product owner and the customer. Going from developer to team lead, I have a new appreciation for the coordination that is required in all the stuff outside of getting the development done, and the significance of brainstorming / prep for the next sprint. Being able to maintain a handle on all the moving features and issues keeps the team on the right path and allows the product owner to trust the production process.

My Truth: Avoid Too Much To Clear

My advice is: put thorough thought into each story to obtain an accurate estimate, and avoid the clog of “almost” finished stories. When we take on too many stories or fail to plan completely for difficult tasks, just like Tetris, the task board is full of tasks and stories in process, but too full to be able to clear them all out by the end of the cycle. The stories on the board take on an oblong, ill-fitting shape, as Developers would much rather start a new code task than pick up code review or QA. The tasks don’t get cleared to Done and this quickly sours the sprint as every story is code complete but QA has to be carried over.

As team lead, I help mitigate the choke points by providing direction for the constant goal of clearing a story before taking on another one. By limiting the items in process or number of items allowed in a column, such as in Kanban, I keep the team driving to pull a story all the way across the board. And by implementing a proper planning phase and continually striving to complete the row and clear that difficult line—I achieve a consistent flow.

Tucker Croft is a Team Lead at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product.

  1. No comments yet.
  1. March 26, 2010 at 7:17 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: