Following the steps of this guy I’m making the slides of my barcampt 2013 talk “eXtreme Scrumban” available on speakerdeck. Check it out and let me know what you think. They’re not heavy on content - that’s just not my type of presentation - but it might be a good pointer, especially if you attended barcamp on March 23rd.
From time to time I’m asked to update my resume, mainly for administrative reasons. I usually keep two versions of it: a personal one and formal HR-ready one. I even keep the latter in the Europass format, which I hate, just so that no one ever complains or suggests enhancements. The personal one however, is free-form. I have it in a pages document, barely formatted and a lot less corporat-y.
I do this because both versions have very different purposes and audiences. The HR version is intended to be included in formal applications to state-funded iniciatives and similar projects. My version exists because I feel the need to say what really matters about me. You know, who I am and what I do. Kind of an anti-pattern.
So if you’re wondering how different both versions are, the simple answer is: very. Indeed.
The formal resume lists facts. It is a set of raw facts including my education and past employees and a rather superficial technical snapshot. Also some nice acronyms and hiring managers buzzwords.
In the informal version of my resume I focus on what kind of person I am and what kind of worker / colleague I would be, if hired. I might not have a large technical description of my role but I think I convey important info nonetheless. I do say stuff such as:
I strongly believe in working smarter, not harder
I love crafting products no matter the technology I’m using, as long as it’s the right one for the job and open source
…which although might not be technically relevant (i.e. doesn’t say which technologies I’ve actually worked with), do say a lot about how I think and act (right?).
A new section I recently added takes this approach even further. I called it ‘stands’. Here’s the rationale: what choices do I make on a daily basis worth telling (even if just for fun)? I don’t think I came up with invaluable information but I find it interesting and refreshing. Plus, it’s got my name written all over it. Take a look and tell me what you think.
Safari over Chrome, Ruby over Python, homebrew over macports, editors over IDE’s, iOS over Android, coffee over tea, markdown over textile, trackpad over mouse, natural scrolling over classic scrolling, books over ebooks, Spotify over Rdio, Simplenote over Evernote, iTerm2 over Terminal, Latex over MS Word, HTML5 over Flash, Postgresql over MySQL, Ember.js over backbone.js.
Isn’t that a nice abstract :-)
Leading software development teams is quite different from just being part of one. You get to face new challenges and a whole set of work is expected of you, which you are not accustomed to doing. One of that challenges - and perhaps the most important one - is to get your team to dock onto a software development methodology and get it to ship.
For some time, I have struggled to actually understand the spirit of metholodies (as in the spirit of the law), beyond the written manifests and instructions. That’s the easy part: reading, doing as told and claiming you’re agile. The hard part is understanding why you’re doing that. Why every idea and instruction first came to exist. It’s mcuh easier to blindly follow instructions than to reflect on the purpose of the manifest, don’t you think?
Looking for answers, I have looked for books that could help me. Here’s some of the books I’ve read (or just re-read) in the last couple years:
- Practices of an Agile Developer, by Venkat Subramaniam and Andy Hunt
- Agile Coaching by Rachel Davies and Liz Sedley
- The Agile Samurai: How Agile Masters Deliver Great Software by Jonathan Rasmusson
- Lean from the Trenches: Managing Large-Scale Projects with Kanban by Henrik Kniberg
(Yes, I’m a big fan of the pragmatic bookshelf :-))
The last book was surprisingly the most enlightning to me. It contains a little chapter at the end focusing on the why methodologies are the way they are. It turns out that agile methodologies aren’t supposed to be picked the way you pick #teamcoco over #teamleno. Agile methodologies take the general problem of software development and shipping from a specific standpoint and define a set of practices that are valid within that scope alone. Take scrum for instance. Scrum is all about structure. It defines roles (structuring people) and backlogs (structuring work) and sprints (structuring time), and it glues these with effort estimation, cadence and commitment. The important part is that it’s from a single perspective at software development: organization and structure. That’s the scrum standpoint, that’s the problem scrum tries to solve.
The same is valid for other agile practices such as kanban and XP. Kanban for instance is all about flow and visualization. It’s not meant to help solving organization problems, instead it sets ideas and provides tools for optimizing and schedulling work based on a kanban board, free-form columns etc. EXtreme Programming (XP) is all about engineering practices: TDD, pair programming, etc. It does not describe the process nor provide any schedulling optimization tools. It’s not that either the kanban or the XP guys forgot about it, it’s just beyond their scope. It’s not their problem to solve.
In the end, agile methodologies imply the same as technologies and frameworks nowadays: you have to pick the right tool for the job. You are supposed to find different methodologies useful when facing different problems and use them in a complementary way, not mutually exclusively. There is no such thing as “one agile methodology to rule them all”.
Check out this video on Scrum Vs. Kanban by Daniel B Markham, it goes much further in explaning why scrum and kanban are different and how they can be used together.
Whenever you or your team work according to that e-mail just sent, voiding every plan and expectation you had just a while ago.
Equals chaos, if you ask me.