Spring Cleaning

Aware of how a backlog can get crud in it, we had planned to do a major cleanup over the New Year. However, tight project deadlines motivated us to push out the effort. By March I was fed up and decided to finally get it done, even if it cost us some time.

For this cleanup, we wanted to achieve two things:

• leave only work that we reasonably could get done this calendar year
• prioritize the work by value

Leave only work that we reasonably could get done this calendar year

I try to collect data, when is is possible to do it inexpensively. I had a good cumulative flow chart encompassing about 30 weeks of work. This gave us a good idea of the amount of work we could get through in the three quarters of 2019. Accounting for work that was not in the backlog at “day zero” (bugs, feature requests, infrastructure improvements) was less of a science.

We assumed that up front we knew about 50% of the work. If the number ended up lower, than we would find something to keep us busy. If it was much higher, any plans would be discarded anyways.

Prioritize the work by value

Here I have to admit to letting the tool put some restrictions on us. The tool we use to manage our backlog has four priorities, so we sorted the work items into five buckets:

• Work that we must do (40%) – failing to do this work would be catastrophic to the project. As we work very close to the hardware, we have a lot of requirements and restrictions that basically stem from physics
• Work that we should do (20%) – failing these would have serious negative consequences, but we could mitigate or live with them
• Work the we would like to do (35%) – the polish that we want to put on the product or internal infrastructure; here more than earlier the effort would determine, if we wanted to do the task
• Work that we shouldn’t do (5%) – this is work that in the opinion of the (majority) of the team shouldn’t be done, but we haven’t gotten full stakeholder (including the team in some cases) buy-in
• Items to remove from the backlog

The percentages indicated the backlog composition after the scrub. After we were done less than half of the backlog remained and remaining items could fit into this year’s bandwidth. Note that the category we chose was based on the our understanding of the value the day we did the review and may change.

The actual prioritization involved a long table with the five buckets marked with tape, a whole bunch of pizza (bribe), and a deck of story cards. I’d read out the title and the team would point were an story would land. Maybe 10% required discussion and it was usually to chose between two neighboring priorities. Though in a few cases we actually had a technical discussion. So I think it was a good exercise, even if I almost lost my voice at the end.

What got discarded

It was interesting to view, what we actually pruned from the backlog:

• Items that were already done – a detriment of a large backlog is that people will create a new work item for what they’re doing instead of using the one in the backlog (that they can’t find); it may also mean that the granularity of stories is off
• Items that no longer make sense I – this is items that were once valuable / strategic, but the environment has changed or the ROI is no longer there
• Items that no longer make sense II – bugs that got resolved through other fixes; features no one is asking for anymore etc.
• Good ideas that won’t see the light of day – there’s only so much time in the day and some good ideas (especially around internal tools and infrastructure) we’ll never be realized; it’s better to be honest with yourself and close them rather than repeating “one day”
• Work that no one will do – these are items that someone filed, because they didn’t want to do the work (at least right away) and no one will pick up, because they;re not attractive to pull (no external value, not fun to do). Common examples include refactoring needs that got notices while doing other work. Either you do it right away or you’ll never get it done.

How we benefited

Immediate benefits included bringing to light important work items that got lost in the shuffle. We were also able to reset expectations and show the direction for the year. In the week following the cleanup a number of easy items got quickly resolved – because they were fresh on everyone’s mind and didn’t require a lot of effort.

Long-term, this should make backlog grooming easier and selection of work items (we do Kanban) more intuitive and provide better value.

As a follow-up, I want to review the items (going by priority) in future backlog groomings to make sure we got the value right and that the stories are well-defined (I already see some opportunity for improvements).

Drawing the Team Together

Although we’re part of a large SW organization that’s part of a global company, our team decided to roll our own infrastructure – at least pieces of it. This suits our velocity and processes much better than what’s offered. The good thing is that we’re leading by example and the organization is looking to copy and standardize some of our solutions.

The thing about rolling your own infrastructure – even if its mostly COTS – is the need to develop and maintain it. And when both the infrastructure and team grow rapidly, you lose sight of the whole picture. This came up in a recent team meeting – and we solved it with a picture.

Team members indicated that they want to know more about the infrastructure. When asked about which pieces, the reply was “good question”. We knew that an inventory would be needed.

The traditional approach would be to get the most experienced / knowledgeable person. They would prepare some materials (slides when possible ;)) and give a talk. Not only is this a bad way to learn, it’s also unfair to the person who has to prepare this and takes them away from doing other work.

We went with a different approach. We wanted to crowdsource the information at least at a high-level. Going round robin through the team, each person was asked to come up to the whiteboard and add a component of the infrastructure to the picture (passing was allowed – the goal was learning, not shaming). This not only showed people how much they knew, it also showed at what granularity the team thought about the concept.

Now we have a picture (well, after some cleanup) that we can point to and ask for more information. And we have a team that’s a bit closer to each other. Also, an idea to try this with the high-level architecture of our driver.

Book Review: The Lean Startup

So I have to admit – I expected more from this book. It’s been lauded as an important part of the Agile “Body of Knowledge” and I probably expected to much – especially in the context of why I read the book recently.

So what didn’t I like? First, the language of the book wasn’t easy to absorb. Some people can write so well, it’s easy to take in. Others (myself included) are more heavy-handed it makes reading more of a chore. Second – the advice in the book is very focused on quickly iterating through prototypes and MVPs. It doesn’t suit the character of the initiative I’m working on now (luckily there’s also 4DX). But that’s not the author’s fault.

Having said these negatives, I believe the book as a place in the Agile canon and definitely should be read by Agile practitioners – even if it doesn’t directly suit your needs.

Book Review: 4 Disciplines of Execution

As I was searching for good books on program management that went beyond the scope of “Agile”, this book appeared on my radar. I’m not going to bury the lead and come out and say it – I enjoyed it very much and immediately found applications in professional life.

The others iterate over the four disciplines (Focus on the Wildly Important, Act on Lead Measures, Keep a Compelling Scoreboard, Create a Cadence of Accountability) – explaining the concepts, the reason for their existence, and real-life examples of application. This method allows good internalization of the material presented.

Agile practitioners will readily recognize concepts such as focused goals, transparency, self-organization, and… daily standups.

If you’re having trouble translating Agile into a non-Agile business or just want to succeed with your next big project, this is a good read.

 

Lessons from a Nobel Prize Winner

I recently finished reading the tongue-in-cheek autobiography of Richard Feynman. I really recommend reading it. There were two things from the book I wanted to highlight here.

The first comes from the time Feynman was lecturing in Brazil and this exchanged happened:

One other thing I could never get them to do was to ask questions. Finally, a student explained it to me: “If I ask you a question during the lecture, afterwards everybody will be telling me, ‘What are you wasting our time for in the class? We’re trying to learn something. And you’re stopping him by asking a question.’”

I’ll leave it without comment.

The other is more involved and shows an interesting lesson.

During the Manhattan project, Feynman was put in charge of the Special Engineering Detachment – that is a group of “clever boys from high school who had engineering ability.” They would punch cards and run them through IBM computers, but they were never told why.

Once Richard explained what they were doing and why, the team was able to come up with improvements to the process and were generally more motivated. And the gains were quite impressive:

“although it took them nine months to do three problems before, we did nine problems in three months”

So the next time you want to hold back information, make sure you don’t want efficiency.

All quotes from Feynman, Richard P.. “Surely You’re Joking, Mr. Feynman!”: Adventures of a Curious Character. W. W. Norton & Company. Kindle Edition.

 

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.