Ignite Berlin #5

Ignite is a really interesting set of events held in over 100 cities globally. Unashamedly aimed at geeks, speakers are asked to have a point to make, but make it quickly! 20 slides, auto-transitioning every 15 seconds to give a 5 minute talk. I gave a talk on Pac-Man and how a programming error made it impossible to win. I already had the content/knowledge and was inspired by a similar presentation I saw at Enthusiasticon. The evening was split into two halves: the first seven talks were a mixed-bag on topics as varied as bees (and beekeeping), pole dancing, love (and death) and, of course Pac-Man; the second set of talks related to the importance of typewriters, supporting kids as the next generation of hackers, why the future of innovation is not just "dinosaurs" and "unicorns"... and much more! Special kudos goes to the couple who gave a talk on how they maintain their long-distance relationship through music. Ignite 5 was a really fun event. Content came quickly and slickly. Audience of roughly 100 was very receptive given how wide-ranging the content was. I'd go along next time for sure. Given that it is a "mixed-bag" I'm not sure I'd actually like to know what is being presented in advance... Just turn-up and see what happens!

Agile Estimating and Planing (Part I: The Problem and the Goal)

For all engineers working at KDAB, "The Clean Coder" is compulsory reading. It is a very interesting read because it is almost a lifestyle guide, rather than the usual dry text on personal time management. It covers all the common tasks faced by software engineers: estimating, refactoring, testing, coding... the lot. As proclaimed by the back cover, "[the book] covers more than technique: it is about attitude." It's a great introduction to software craftsmanship. Impressed with this book, I picked up a copy of "Agile Estimating and Planning" which is in the same series of books from Prentice Hall.

I am a fan of "The Clean Coder" and so grabbed me a copy of "Agile Estimating and Planning" from the same series. pic.twitter.com/AxlfG0Z7Hm

— Paul Adams (@therealpadams) July 22, 2015

The book is separated into 7 parts and 23 chapters. I will not bombard you all with a lengthy review of the whole thing all at once. Instead, I'll drip-feed you my thoughts one part at a time. Starting with the beginning: "Part I: The Problem and the Goal".

Chapter 1: The Purpose of Planning

This chapter should provide nothing new to anyone who has been through "Project Management 101" and is nicely couched in the context of software development. Ultimately we are asked "Why bother with planning at all?" and are presented with the following reasons:

• Reduce risk
• Reduce uncertainty
• Support better decision making
• Establishing trust
• Conveying information

Fred Brooks (in a pre-agile era) famously told us that we needed to throw one plan away, so we should plan to do so:

The corollary to this is that if you plan to throw one away, you will end up throwing away two.This is and has been an impractical suggestion. Plan to build something as quickly as possible and modify it as needed in the future.

Planning is very important. Plans are not. Fred Brooks saw agility coming. Hero.

Paul's Thoughts...

Good introductory chapter. Gentle reminder of a few things the reader should probably already know. Successfully sets the context for what is coming.

Chapter 2: Why Planning Fails

So now we start to get a little more in-depth with agility. Again, nothing too taxing at this point and certainly familiar ground for anyone who is an experienced ScrumMaster or Product Owner. This time we are simply asked "Why does planning fail?" There is, of course, plenty evidence for failed planning: how many people reading this have been involved in projects where scope, quality and/or timelines have been "off"? I know I have. Let's face it, we all have.

In this chapter the primary reasons for failure are cited as:

• Planing activities and not features
• Too much multitasking
• Features not developed by priority
• Not embracing uncertainty
• Estimates as commitments

The second point on this list is my favourite and one that often goes misunderstood... Once upon a time I thought I was Godlike for handling so much work. I was the multitasking master. Education and experience has taught me that multitasking is actually the productivity killer. Do one thing. Get it done. Move on. I actually control my tasks at work with a Kanban chart which has been specifically designed so that I cannot fit too many tasks into the "Work In Progress" state. In short: multitasking causes a lack of focus, increases the number of ramp-up periods/context switches, increases stress and, most importantly, delays the delivery of results, which may impact other people's work. The book contains a genius "why did I not think of that?" diagram to illustrate this.

Paul's Thoughts...

Great reminder of the factors behind planning failures and good description (without too much tedious detail) of why these factors happen in old planning styles.

Chapter 3: An Agile Approach

A good plan violently executed now is better than a perfect plan executed next week. --- General George S. Patton

Chapter 3, opens with an epic quote. Otherwise, the first half of this chapter is a little unnecessary; the history and fundamental concepts of agility are presented. In all honesty, I skipped through a lot of this. There is nothing new in here and it is all content I would expect the reader to have a good grounding in. I assume this was thrown in "just in case" the reader gets this far with no knowledge of agility at all.

Thankfully the second half of the chapter gets us back on point.

In the second half of the chapter we are reminded that planning is actually only as useful as the horizon; if you are trying to reach a target 20 miles away, you're going to need to check your progress and reassess 5 times, because the horizon is roughly 4 miles away. So what are the horizons in software engineering projects?

Paul == Artist

Typically it is the three innermost of these that we care about. The inner two are certainly familiar with any Scrum practitioners (daily scrum and sprint planning/retrospective). Release planning is about determining what user stories are going into the next version of the product. If anything, it is about creating a "vision" that the team can buy into. Iteration planning is more in-depth: "What are the tasks we can associate with the user stories? What are the priorities?". Daily planning is hugely important, too: "What am I working on? Who/what am I blocking? Who/what is blocking me? Is progress as expected?"

Paul's Thoughts...

An interesting read for anyone who needs an introduction to agility and how to structure planning in an agile environment. I was left thinking "just cut to the chase!". The next part of the book, and my next post on this topic, is called "Estimating Size". Now we're talking!

Overall Thoughts on Part 1

It is satisfying to be reading a book that I can easily relate to my own experiences of both classical and agile project management. The background information is undoubtedly important for some readers. For me, however, there was just a little too much. Any experienced project manager (especially Scrum Masters/Product Owners) could skim through this and head straight to Part II, I think.

A Tale of Two Talks

My day-to-day contribution to Free Software has changed quite dramatically in the last couple of  years. I'm no-longer as involved with any one project than I used to be. Somewhat correlated with my declining active contribution to Free Software projects is my decline in public speaking.

You wait forever for a bus and then two come along at the same time!

I shall be delivering two very different talks in the coming months: one in which I will remind the audience that PacMan is a real asshole and in the other I will talking about documentation communities within Free Software.

"PacMan: The Original Troll", Ignite Berlin

Thursday, July 30th at 19:00. IXDS studio, Paul-Lincke-Ufer 39/40, 10999 Berlin

"PacMan: The Original Troll. PacMan is one of the best-known, well-loved and often-copied games of all time. But PacMan is mocking you. You cannot beat PacMan; nobody can beat PacMan. He laughs in your face."

I recently attended Enthusiasticon where one of the talks was about Pokémon and, more specifically, about how a programming error (almost certainly caused by an engineer wrestling with the GameBoy's very limited architecture) made the game bizarrely winnable. If you knew how. This inspired to get up and talk about PacMan; a game which has the opposite problem.

As an Ignite talk, I will only have 5 minutes. PacMan needs no introduction, so I can save some time there. So I will cut straight to the ghosts, the map and why you're doomed to never beat PacMan.

Spoiler alert: the "waka waka" noise that PacMan makes... that's him laughing in your face.

More of the event details can be found at the Ignite Berlin website.

"Judas Priest Ate My ScrumMaster", Write The Docs Europe

Monday, August 31st and Tuesday, September 1st at 09:00. Club Lavka, Novotného lávka 201/1, 110 00 Prague

"Community Management in Free Software communities is still an emerging field and has produced a spectrum of practitioners: from master-manipulators of social media, to those more focused on metrics and data as a means to driving process. Either way, the state of the art is still largely driven by the needs of technical contributors to projects. Good documentation is a crucial component in a software product and yet often technical writers are overlooked as important stakeholders of the process. Within the community, there are undoubtedly common problems between engineers and technical writers. Software Engineering is full of laws; can we show that these laws apply to technical writers as a means to help bridge the chasm between developers and technical writers?? In this talk Paul walks us through a selection of his favourite laws of software engineering and explores how developers measure them and if technical writers must also obey them. Or not. And what that means for the success of documentation in a Free Software project."

This will be the second time that I have spoken at a Write The Docs event. These are very friendly events and very welcoming given my "deliberate outsider" position. As a software engineer I think it is fun and useful to engage with events like Write The Docs in order to reach and say "here is how I think document writers and engineers can work together better" from the engineering perspective.

In this particular talk I will be exploring some of the rules and laws of software engineering and showing how I think these laws equally apply to document creation. Do these common problems create a bridge between document creation and coding? A common "platform" to work from?

Spoiler alert: 90% of this talk will be crap.

More of the event details can be found at the Write The Docs Europe website.