Earlier this year I gave a talk at Write The Docs, in Prague. I have written about the content of that talk previously. The good folks of Write The Docs have now published the talk recordings from the event. Mine included.
Once again, my thanks go to the organisers and the attendees of Write The Docs. It's a really fun event with a great mix of different participants. I cannot recommend it enough to people (or companies) that have interest in good tech writing.
Science and conspiracy has answers to all of these. Personally, I have a few questions about the last issue.
There are multiple approaches to scaling agile projects "out there". I'm not going to talk about any of them in detail. But feel free to take 10 minutes to educate yourself by clicking the links below. You'll come back, right?
Back? OK.
I'm particularly interested in LeSS, SSwS and Nexus (and somewhat in the Spotify approach) because these are, in particular, approaches to scaling Scrum. Of course each has its ups and downs. Nexus, however, has some particularly down-y downs. They bother me.
 |
| The Nexus Framework from Scrum.org |
So. Nexus. This is the official approach to scaling Scrum from the nice folks at scrum.org. It only landed very recently so it is kinda late to the party. I get the feeling it is a somewhat rushed reaction to all the other approaches coming into use first. Why do I think this? Because of two gaping holes:
Nexus is very workable because it is so simple. It takes all the same principles of Scrum and simply add some bits. No major overhaul. No demanding concepts in addition to Scrum. But these problems of scale and culture are big problems.
Why do I think Nexus does not scale very well? Simple. The authors of the framework say so themselves! Take a look at what it says on page 2 of the guide:
Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal.
Three to nine teams. THREE. TO. NINE. So between 15 (bare minimum) and 81 (absolute maximum) developers. Not very scale-y. Spotify with its 1200 developers laughs in the face of Nexus.
Why does it not scale so well? Simple: take a look at the image above. See that "Nexus Integration Team"? There's your problem. This team is constructed from the Product Owner, the ScrumMaster and the Nexus Integration Team members, who may or may not be members of the Scrum teams. For me, it makes sense for the NIT members to also be representatives of the Scrum teams. But a combination of Brooks' and Conway's laws limit the size of the NIT to about 8 or 9.
I have yet to see anything official on the matter but I have heard rumour of Nexus+ as a means for bringing greater scale. A Nexus of Nexuses. Holy Moly. No.
The one is subtle. And little hard to explain to anyone who has never "done agile". But I'll give it a try.
Scrum teams are self-organising. This is a big deal. They work together to solve their problems as best as they can. The most "senior" team members humble themselves and the most "junior" have the chance to shine. Everyone pulls together and does their best using their skills. No specialists.
I call this the "egalitarian social contract" of Scrum.
You will not find any Scrum guide telling you that this is a feature of Scrum. It isa natural result of being self-organising (something which the guides will tell you to do). "I hate being in a team of equals" said no Scrum team member ever. This attitude to teamwork is something that is just expected of a Scrum environment with decent values.
Nexus kinda breaks this. Hard. And explicitly.
Go back to that guide again and take a look at page 5:
Members of the Nexus Integration Team may also work on the Scrum Teams in that Nexus, as appropriate and necessary. If this is the case, priority must be given to the work for the Nexus Integration Team. Membership in the Nexus Integration Team takes precedence over individual Scrum Team membership. This preference helps ensure that the work to resolve issues that affect many teams has priority.
Priority must be given to the work for the Nexus Integration Team. Priority. "Sorry guys, I need to do some stuff for the NIT. I'm not going to be able to help with backlog item X today." Not. Cool.
If I am being honest, this is a little bit of nit-picking on my behalf. Scaling up to 81 is still more scale than the vast majority of development companies need to scale to. Cultural problems can always be tackled somehow. I guess my issue is that these problems were built in to the framework.
I'd love to see Nexus in action. I suspect it is so new that nobody is really doing it yet. Is anyone out their seriously wanting to give this a try? I hope so. Please shout if you are. I'm really curious to see it in action.
This is the first of two blog posts I will write about Write The Docs Europe. I'll kick-off by writing about my presentation, but later I will write about my views of the event as a whole.
I spoke at the Write The Docs Unconference in Berlin last year. At the time I talked about how Free Software projects emerge from an idea to success and some of the "laws" they abide by in order to get there. As part of that presentation I wanted to begin my personal journey of better-understanding the "laws" followed by tech writers. The subsequent workshops around this topic produced some interesting results for which the results can be read here.
In Prague I wanted to move from a "pull" to a "push" model and presented some of the laws that apply to software engineers (not just Free Software).
Really great talk by @therealpadams @ #writethedocs witty, packed with insights. Need to get him to London for the meetups :)
— Kristof Van Tomme (@kvantomme) September 1, 2015
Woah! Open source software is a "product". But the term contains engineeringeese, which is a cultural issue. @therealpadams #writethedocs
— Samuel Wright (@plaindocs) September 1, 2015
Point @therealpadams is making with these "engineering" laws is that they're not engineering laws. They're management "laws". #WriteTheDocs
— Karen Mardahl (@kmdk) September 1, 2015
Awwww ❄ @therealpadams #writethedocs pic.twitter.com/5rTjbS4obF
— Ancsur (@Ancsur2002) September 1, 2015
Miss my talk at Ignite Berlin 5? Well here's your chance to see the recording. A quick reminder:
This was a really difficult talk to prepare for. I would use this many slides in a talk that is waaaaay longer than 5 minutes. In this format, the speaker is basically forced to tell a 5 minute story and ensure ("hope") that the story progresses at the same pace as the slides.
If you head over to Peter Bihr's account on YouTube you will find all of the other talks from the same event. I highly recommend the talks from Claudia (on typewriters) and from Jessilyn and Neil (on how to ale long-distance work).
Also, in case you have not seen it, get yourself over here to see an article on the original concept art for Pac-Man. Cool stuff.
Yay @nigelbabu! Also, cool shoutout to @therealpadams just in time for @writethedocs Prague :-) #writethedocs https://t.co/rlxuTXJfsG
— Mikey Ariel (@thatdocslady) July 31, 2015
I spoke at the Write The Docs unconf in Berlin a year. It had been a long time since I had spoken at a non-engineering event. Even longer since I last spoke at an event without an explicit Free Software connection, too. I enjoyed the event and I obviously did not make a fool out of myself, because I am due to speak at the next Write The Docs European conference in Prague.
What are the rules documentarians play by?If you follow the link in the Tweet (above) or follow this link here you will find Nigel's report on what we concluded in that session. OK, so I learned a thing or two about how documents are prepared in the software product world. Cool. What's next?
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".
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:
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.
Good introductory chapter. Gentle reminder of a few things the reader should probably already know. Successfully sets the context for what is coming.
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:
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.
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.
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?"
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!
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.
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.
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.
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.