Detectting Agile Bullshit
You know you fucked up your workplace revolution, when the American Department of Defense publishes a guide for “Detecting Agile BS”. Which turns out to be pretty good and concise by the way.
Talking, Thinking, Typing
One cardinal misunderstanding burning teams, tanking projects and killing products since the dawn of software is the assumption that software development can be reduced to the aspect of producing code.
Software development is talking: Speaking and listening to peers, colleagues and stakeholders. Software development is thinking: Thinking alone by modeling data, testing abstractions, thinking through cases, thinking together by reading other people’s thoughts. Software development is typing: Writing code, but also: Comments, readmes, specifications, code reviews, tickets, mails, …
Overemphasizing one of these aspects or neglecting others is a sure fire way for personal all professional frustration.
On Avoiding Stupidity
It is remarkable how much long-term advantage people like us have gotten by trying to be consistently not stupid, instead of trying to be very intelligent.
This truly struck a cord with me. You can try being brilliant, being excellent, being the best, and I guess this is not the worst aspiration for a team. But, in the end, success in completing projects and shipping products is less about being exceptional but being non-exceptional. Not about getting one thing perfectly right, but about getting many things not wrong. Success sometimes is less about winning and more about not loosing.
I Test On Prod
Inspiring piece. The better and more advanced you get at testing your code for all eventualities and scenarios, the easier it is to loose out of sight that you will never produce perfect software, there are just too many modes of failure. Hence “Testing in Prod” is not an artifact from times long gone, it is a reality and your org needs to be able to do it.
A system’s resilience is not defined by its lack of errors; it’s defined by its ability to survive many, many, many errors.
Better Value - Sooner, Safer, Happier
Still wonderingvwhen your org will finally reap the benefits of agile? When you will get better value sooner, safer and happuer? This talk by Jon Smart holds a couple of really good pointers (Maybe skip the intro).
15 Questions to Kick Off a Project the Right Way
I am a firm believer that a couple of key decisions at the very start of a project have a tremdendous impact on a teams ability to succeed. And while my personal checklist is a bit tighter and focused, Atomic Objects’ 15 Questioms to Ask at the Start of a Software Project provides a pretty neat guide.
Pioneers vs Process People
Often overlooked while staffing: Most people excel in very specific situations, some prefer to make, some to maintain. But projects/products require different skillsets througout their lifecycle.
“[At the start] it needs builders, pioneers who come up with clever ideas and execute upon them fast. They improvise … are opinionated [and] make their own decisions.”
“[Later] it needs a lot of incremental improvements, nitty-gritty […] details […] and a developer team which […] only needs some fine-tuning.”
Really good example from Oliver Eidel.
A Good Meeting
How long since you have been in a bad meeting? A week? A day? An hour? Unfortunately it is really, really easy to botch a meeting, to make it the worst part of any given day for a whole group of people. Fortunately it is also not that hard to make it a positive and productive experience.
A Managers Playbook
A pretty neat guide to basic management interactions. I found the sections on decision making and coaching especially worthwhile.
Good, Bad & Ugly Standups
One project, three phases, three vastly different stand-up experiences: The Ugly, the Bad and the Good Standup.
Demo vs Prototype vs Minimum Viable Product
Inspired by Jacob Kaplan-Moss’ Demos, Prototypes and MVPs here comes my take: A demo shows a vision. A prototype demonstrates a capability. A Minimum Viable Product fuses the minimal core of vision and capability in order to deliver customer value.
A Ring of Snakes
I have to admit I only had the faintest idea about extreme programming until I read and understood this well written and terse summary: A Case Against Extreme Programming. One page, all you need to know.
A basic comparison of agile frameworks
Working in an agile context can feel “babylonian” at times. With everybody using the same terms, implying different things. So these charts might come in handy some time: Scrum VS Kanban VS Lean VS Extreme.
Peopleware - Productive Projects and Teams
A true trove of inspiration, open anywhere and find inspiration for everyday management work.
Tales From The Trenches: The Gitlab Outage That Wasn't
Fascinating write up how the Gitlab team avoided a major outage. Featuring expired certificates, high level tools falling short and some good old server admin skills. Loving the depth and detail!
Agile, or How to defeat bureaucracy with 7 mandatory meetings per week
Great no-bullshit intro to Agile, Scrum, backlogs, kickoffs, stand-ups, demos and retrospectives and what the whole fuzz is about by Curtis Lassam.
Scrum - The Art of Doing Twice the Work in Half the Time
There are many ways to learn about Scrum, I found this among the most entertaining.