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.
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.
Interestimg piece by Jamal Mashal on how to use themes and timeboxes to create structure and focus in his work: Themed days, Timeboxing and why you should use them.
How can you successfully transform an organization towards more agile and lean ways of working? According to Jon Smart, by letting your people develop VOICE.
Amazon appears to have “Banned Powerpoint” or to phrase it a bit less clickbaitish: Made a heavily prepared agenda/discussion paper the core structure for meetings. Which I guess can pay off in certain settings by reducing time spent presenting, enabling more asynchronous collaboration and opening up - for better or worse - the classic 10 slides, 20 minutes, 30 point font structure.
In essence this is the continuation of only having meetings with a well prepared agenda I rooted for a while ago.
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.
Classic talk by Henrik Kniberg on Agile Product Ownership, compact but still refreshing, loved the section about forecasting (around minute 12).
A true treasure trove for remote leading and working: Stripes/Increments “Guide to Distributed Teams”.
Interesting how my main takeaway from Shopify’s write-up of a major refactoring - “Under Deconstruction” - is less about code and more about people.
As it is ultimately humans that produce code, refactoring a big code base is about changing code as much as it is about changing humans. Shopify used keynotes, guilds, handbooks and trainings to create “ability” and “motivation” to support the desired changes, only added “prompts” in the form of rules and tooling later afterwards. Without ability and motivation to act on them anybprompts are bound to fail ir worse followed superficially.
My second big take away is to understand (and ensure) value is created along the way and not only if and when a (maybe over idealistic) goal is reached. No product, no architecture, no code base will be perfect any day, but it can become better everyday.
Strip away the horribly misleading title and the accelerator grandezza and you get yourself some pretty solid advice for a successful and healthy career.
Not sure what I find more interesting, how tragically accurate this review of the state of personal assistants / voice interfaces is - or that the same group of scientists did an equally devastating one on the state of mobile in 2000.
Neat piece on inversion as tool for problem definition and solution.
20 years of product management experience in 25 minutes by Dave Wascha. As all good advice, easy to get, hard to consistently do.
Recently stumbled into this five part series drawing on analogies between improv theatre and consulting work. Read it in one go, will revisit for sure. Highlights: Well, consulting as improv, “Yes, and…” as strategy for collaboration, capacity building as ths consultants roe, (as opposed to problem solving) and the power of an outsiders perspective.
Work (and life) is as boring as you make it.
1. Always take the initiative.
2. There is nothing wrong with spending a night in jail if it means getting the shot you need.
3. Send out all your dogs and one might return with prey.
5. Learn to live with your mistakes.
9. Carry bolt cutters everywhere.
10. Thwart institutional cowardice.
14. Ignite the fire within and explore unknown territory.
15. Walk straight ahead, never detour.
16. Manoeuvre and mislead, but always deliver.
17. Don’t be fearful of rejection.
22. Guerrilla tactics are best.
23. Take revenge if need be.
24. Get used to the bear behind you.
Full list @ kottke.org.
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.
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.
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).
Leading a succesful team requires clarity - a leader communicating the framework for the teams performance, the vision, goals, rules and key parameters so they are easy to grasp and presence - a leader engaging, emphatizing with and enabling his or her team during said performance. David Tates Clear and Present Leadership provides a great backdrop to reflect, learn and grow in this regard.
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.
“Managing humans” means getting two things right: The very big and the very small. Michael Lopp offers plenty of advice for both.