Personal Kanban to the rescue

For my everyday “productivity” tool, I use a custom mix of practices adopted from Covey’s 7 Habits of Highly Effective People, Allen’s Getting Things Done, and Agile. In the past week or so, I felt uncharacteristically overwhelmed with everything that needs to be done. As is typical in complex situations, the root causes were multiple (although easy to  identify): we’re buying a new apartment and moving soon, we have a big family event coming soon, and (because life is not fair) got hit with several family emergencies.

Fortuitously I was in the middle of Jim Benson’s Personal Kanban – a book that was on my reading list for far too long. I had the pleasure of listening to Mr. Benson’s keynote at Agile By Example a few years back and it opened my eyes to a lot of subtleties of tracking working via Kanban.  As I consider my self a proficient user of Kanban, the book did not hold revelations (although I still heartily recommend it), but it did knock me out of my funk.

I had to set up temporary Crisis Kanban to get the important stuff handled!

That evening we set down with my wife to set everything up. Lacking a good whiteboard and wanting portability, I settled on having each value stream be a separate piece of A4 paper labeled with the name and relative importance. Tasks went (obviously) on stickies. Columns were the most simple possible – Backlog / Doing / Done. This allowed us to inventory all we had to do.

We agreed to make sure to close at least one task per day each. In the evening, we review progress and list out the 2-3 tasks e want to tackle the next day. \

Suddenly I’m much calmer.


Why PMs Need (to Understand) Agile

This year I had the honor of providing some opening thoughts at the NTPM conference. As the conference is aimed at Program Managers, but has a lot of Agile content, I chose to give three reasons why PMs should understand Agile. I’m rehashing them here.

Common Language with Delivery Teams

At the end of the day, PMs and delivery teams* have the same goal – maximize the value delivered as part of the project. To be able to determine what maximizes the value and how to best deliver it requires a dialog between the PM (especially if playing a PO-type role) and the team. You can’t have a good dialog without a shared language.

* I use the term delivery teams as Agile has grown far beyond software development teams.

Personal Efficiency

Practitioners of Agile quickly realized that they see benefits not only to team efficiency, but also personal efficiency. Be it through following concepts like limiting WIP, maximizing work not done or reflecting on how we work or implementing specific techniques like Personal Kanban.

Agile Adoption

The least obvious (but most dangerous) reason is that PMs are often chosen to lead Agile adoptions. To management this seems like a no-brainer – Agile adoption is an internal project, so it should be managed by PMs. But we know that projects are more effective, when PMs have an understanding of the subject domain (even if cursory). And an Agile adoption is so invasive into culture and the way people work that it’s very easy to mess it up or bend it to optimize the PMs job, not maximize value delivery.

The Problems with Player-Coaches

I recently got to chat with a friend, who coaches an American football team and the discussion drifted towards player coaches and QBs calling the plays. One of the reasons I prefer football to other sports is the impact play calling makes on the game. Since each snap is prefaced with a pause and reset, it gives the coach (or assistant coach) the opportunity to decide on what type of play will be made. This needs to take into account field position, down, time on clock, score, as well as the strength and weaknesses of your team and the opponents.

When there is a strong sense of trust between the coach and the team quarterback, the coach may cede this duty to the QB – he’s on the field, he’s the one that needs to execute. In some teams, the coach will also be the player – this is not unlikely for a new formed amateur or semi-amateur team where on person organizes the team, coaches it, but still wants to get in on the action.

So, what are the problems with this approach? First is the ability to see the whole situation. When on the field, vision is limited (on the sidelines, you can move over – look at the offense, the defense, your charts) and time is scarce (focus on the play, no time to talk). The other – more subtle – is that you are inherently biased. Sacked in the QB role? Maybe you’ll want to run the ball, to avoid getting hit. This will affect your decisions and thus the plays – optimizing (locally) for yourself, not for the team (globally).

So how does this feed into Agile? For one, it shows why an external facilitator, coach or Scrum Master is useful to the Team – they’re not in the thick of things, they are more divorced from the emotions. It also shows why a good Product Owner – one that is aware of the greater product vision (time lines, business environment, but also team’s strength and weaknesses) plays a critical role.

Highlights from NTPM 2018

This year I had the pleasure to attend the New Trends in Program Management conference in Gdańsk and the honor to give a presentation. As I mentioned in my opening address, the conference provides an interesting blend of Program Management and Agile topics. I’d like to highlight three presentations that I found most interesting.

Frank Turley gave a very interactive talk on “Top 10 persuasion techniques for PM”. The title is actually a lie, because there were 12 techniques. While formally a talk, this was more a workshop that quite engaged the audience.

Thiago Ayres gave us a fascinating look into the future of the world: work, education, technology, projects. This was the most energetic presentation. Again, with very active audience engagement. This was worth attending even to to see an excellent speaker put on a show.

Henny Portman – rounded out the conference by giving a whirlwind tour of Agile practices and frameworks from the viewpoint of Program/Project Managers, giving hints on how they need to adapt to this new world.

Special mention goes to the speaker dinner on Sunday. The hotel restaurant (Magiel) served a delicious four course dinner and I will happily visit it again.

PS. For those interested, I posted my slides.

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.