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.
A good argument that agile leadership is about delegating and divesting decision making power as far down as possible into the informal network.
“[Informal authority] is emergent, opt-in, always-on, and ever-informed by the collective knowledge of the group in an Agile way that formal authority can never match.”