Energy in Opensource

After a lot of hard work, I’m happy to say that the project my team has been working on has finally hit open source. A few days later, we were pleasantly surprised by a non-solicited article that drove a lot of traffic to our product repository.

One thing that really surprised (though maybe shouldn’t have) was how much the incoming feedback energized the team. Sure, a lot of it was asking for help to iron out the kinks in compiling and using the driver. But we also got a lot of questions of direction, detailed questions about optimization and feature requests!

This was the essence of the fourth principle of Agile and my first real contact in the software space. A real invigorating experience and noone minded the time we had to spend replying to questions, finalizing the FAQ, and getting other useful documentation done. It’s time well invested.


Guitar Hero

220px-Guitar_Hero_logo.svgCall it midlife crisis, if you want, but I recently purchased my first-ever gaming console. One of the games I picked up for it was Guitar Hero. I remembered enjoying the experience, when I got to play on other people’s machines and wanted to have it for my self.

Now that I have it, I found it a great way to blow off some steam after work and switch into “home mode”. I started thinking why and here’s what I came up with:

  • The game requires me to use skills I don’t exercise at work: manual dexterity, rhythm, music appreciation
  • It has a physical component – I find myself moving around the room while playing it
  • It requires quick response as the notes are coming down the screen
  • It gives instant feedback
  • It doesn’t allow you to dwell on mistakes – miss a note => try to get the next one

Overall, this is something I need to incorporate more into my life in a conscious way.

BTW Guitar Hero is an excellent name. It describes what the game is (playing a guitar) and it makes you feel good just for playing it (you’re a hero!).

Are you regressing to the mean?

As Reese’s Peanut Butter Cups teach us, some of the best ideas come from combining to possibly disparate things. Here’s on of mine.

I recently finished Geoff Engelstein’s “Gametek: The Math and Science of Gaming“. This book is a compilation of segments he recorded for the the Dice Tower podcast. These segments explore how math and psychology (among others) affect good game design.

At the same time, I’m struggling with my scrum teams, which recently had trouble completing there last few sprints. This is not only bad for morale, but also diminishes my ability to provide good timelines to our stakeholders.

One of the segments that resonated with me was the regression to the mean. In a nutshell, this states that performance clusters in a bell curve around the median performance. Which means that any incident of being above average is most likely to be followed by comparatively worse performance and vice versa. This also means that criticizing seemingly works (because the next performance after a bad one and criticism is usually better), while praise doesn’t.

I went back to look at the size of sprint backlogs over a period of time, I saw an increase in the number of stories selected by the teams (we don’t use story points #NoEstimates). To me this looks like a situation in which the teams saw they were able to deliver commitments, so they “challenged” themselves to do more. These challenges usually work for a time (reserve energy, sacrifice of slack), but as the sprint backlogs grew, so did technical debt, WIP items, items bouncing back to the backlog. Until it came crashing down in unsuccessful sprints.


What can we learn from the NY Giants?

I think there’s no doubt about it – the NY Giants suck this year. As I’m writing this, they are 1-7 with little hope of redemption. The one bright moment of the season came in week 6 against the Broncos. Let’s look at what they differently and what we can learn from this.*

* I’m far from a football expert, but I won’t let that stop me from writing a good narrative.

Head Coach

Ben McAdoo got promoted to Head Coach from the position of Offensive Coordinator and it seems he had a hard time letting go. During the games he would do offensive play calling. This probably meant that he focused too much on that part of the game and didn’t have focus for defense, special teams or general overview of the situation. This is a problem of localized optimization. (Also a common anti-pattern in organizations, where engineers advance up through the management chain).

Offensive Coordinator

What did Mike Sullivan, the offensive coordinator, think about being sidelined during each game? What did the team think about the guy in charge of offense, not being in charge when it mattered? What message does this send? This is a problem of building (breaking) trust. 


With Sullivan running the practices and training, but McAdoo calling the plays during the game, the team had an additional changing variable to cope with – a different voice, different mannerisms, etc. In a sport were patterns need to be executed flawlessly in a high pressure, real-time situation, you don’t need that. This is a problem of failure to create a stable environment. 

I think that handing the reins back to Sullivan (where they belonged) helped to make that game a success, after a string of failures.

So why have they lost the next two games? Well, you could blame the loss of their key players in the game against the Broncos, the fact that the next two games were against top contenders, or maybe I’m just spouting nonsense. Time may tell.

Trimming the Fat

During our last planning meeting, we were unpleasantly surprised that very few items were taken into the sprint backlogs (we have three teams in a LeSS model). Now there were good reasons for this (a lot of unfinished work that had to roll over, middle of vacation season) and no one blamed the teams, but it gave us pause.

The other “red flag” was the structure of the backlog. We bucket our backlog items into four tiers: next sprint, next+1 – next+2 sprint,  next+3 – next+5 sprint, no timeline. Combined with some statistical data about the number of items completed per sprint, gives us a measure of confidence about being on track. Well the tier 2 bucket had 3 sprints worth of work and since tier 1 did not empty out as expected, we knew that we had more work than we would be able to get through.

There and then we decided to do a quick scrub of the backlog. Very quickly we decided to classify work items into one of three categories: MVP, neutral, fat. The latter category was things that would help us or make the product a bit better, but were far removed from MVP and the product (and team) could live without it.

We were surprised (though probably shouldn’t have been) that a majority of tasks fell into the ‘fat’ category. Now we are faced with a hard discussion about priorities and verifying our opinion of what is “fat”, but it shows that we do have enough bandwidth to deliver what is important.

When is the last time you looked through the backlog for things that aren’t important?

(All references to we mean myself and my manager – we co-manage the engineers doing the work and act as PO).

Energy in planning

Last Monday we had our next sprint planning (#13 for those keeping count). It was a Monday, not the usual Friday to avoid missing half the team, who took a day off to celebrate the last day of school. But this strays from my topic…

I really enjoy what we call “turnaround day” – we do our Sprint Review and Sprint Planning on the same day (more on that another time). One of the reasons is that the team feels very energized during and right after the meeting.

So much that we moved up the Planning in the day, because the engineers actually want to start working on the stories that day. We’ve previously thought that planning on a Friday afternoon would allow people to calm down, have time to absorb the work over the weekend (subconsciously!) and start cracking on it on Monday. Well, surprise!

Why do I think they’re so energized:

  • new shiny things to do! – new stories, means new opportunities, challenges, valuable contributions
  • we meet as a team – working in a LeSS framework, this is one of the times members of all the teams come together to collaborate
  • egalitarian meets experts – on one hand, everyone has input into their team’s backlog sprint, including freshly hired interns; on the other – the technical leads and senior engineers get asked about their opinions on key items
  • playfulness – there is an amount of joking and ribbing that occurs at the meetings:
    • we have an informal (and unenforced) rule “you touch the story card last, your team has to take it” – ended with someone using tweezers during planning
    • last time I heard the phrase “I can take these for my team, since I’m going on vacation” (tongue firmly in cheek)
    • wayward story cards make it into initial backlog piles, before someone notices the sabotage

And in the end, we are surprised how much the team is able to pick up for the next sprint and they do deliver!

Well, two more weeks and we get to plan again.


Adopting Agile using Waterfall

Something that bothers me, is when organizations go out to adopt Agile, but try to do it using traditional program management or waterfall methods. “It’s the only thing they know” – you might say. But if it is, how are you doing the adoption? You have to have Agile coaches or Scrum Masters or Agile practitioners. Someone who knows how Agile works. And why wouldn’t you ask them to organize the adoption.

If you see value in adopting Agile, why not do it correctly? And if you don’t, and treat it as a fad – just don’t do it. Or better yet, let those that want to, do it and let it grow and spread organically. Otherwise, you’ll alienate both the practitioners as well as those that don’t want to change.

Is this just an anti-pattern of “those that can’t do, teach”?

(Note: I do say anti-pattern. I’ve had many amazing teachers throughout my life).