For the more abstract work, it makes it a lot easier for other people to ‘read your mind’ and for you to delegate if you share as much context as possible as Anna Shipman describes here.
Category: Agile
Something that bears pointing out regularly: “Plus, contrary to popular belief, agile practices were not invented by the Agile movement. They predate it by many decades.”
https://medium.com/columbus-egg/dear-agile-im-tired-of-pretending-d39ab6a12003
I’ve never exactly followed any framework but instead, I played it by ear and mixed and matched what worked best from wherever I could find it. That’s always a bit bothersome (but easily solved) when people want to work with the exact definition of something.
Formalizing that approach as SWARMing (Scaling Without A Religious Methodology) is an interesting twist indeed.
Jez Humble – Continuous Delivery in Agile
This Jez Humble talk about Continuous Delivery is one of my all-time favorites. As a bonus at the end he also totally demolishes the Google Guy.
Tooling has become so good and so empowering that like in this tweet, many commerce ‘startups’ that are really struggling to hire and retain dev teams (and then utilize them to their potential) would be much better served using Airtable, Zapier and Pipedrive until they break.
More likely in any case that the startup will go out of business or be acquired than it hitting the limits of those kinds of tools.
With my background in behavior change, I’m very pleasantly surprised to find this quote in what is a connoisseur’s treatment of the nuances of agile/agility: “There is only one way to create business value, and that’s to change someone’s behavior.”
https://medium.com/columbus-egg/iterating-pivoting-agile-agility-940bcb1a0895
“Changes to one team’s service may be implemented by another team who needs the enhanced capability by what is called an Away Team. This team works on the Home Team’s code to add what it needs according to established engineering standards and then leaves that code in good order to be maintained by the Home Team who owns the service, with help when needed.”
Fully embedding your team in another team’s context to get something done, seems to me a very interesting compromise between autonomy and collaboration. Every team is an island, but it is ok to travel to another island and if that’s not possible, you can still build your own.
Also more than disorienting to see an in-depth piece about engineering organizations like this appear on The Register.
Putting an entire team in another team’s context is something I have considered for all the collaboration, delivery, culture etc. benefits that it will most likely yield in exchange for a minor hit in delivery.
https://www.theregister.co.uk/2019/05/14/amazons_away_teams/
A worth-while apology for Design Thinking:
“This is why I advise executives study design. If culture is driven by leadership behavior, then culture change is primarily driven by leadership behavior change. Design has a lot of techniques to offer.”
https://medium.com/columbus-egg/design-thinking-as-decision-framing-7d6795542421
The newsworthy thing about the Accenture/Hertz story is not that they failed to deliver but how badly they failed and that they are getting sued for it. Getting something that’s not very good for far too much money is an accepted part of doing business with consultancies of that size.
https://www.theregister.co.uk/2019/04/23/hertz_accenture_lawsuit/
A handy checklist of what you need to take into account when you do (remote) mob programming. Every time we’ve used mobbing as an approach it has paid off thusfar so I’m very interested in deepening the practice.