A lot of @SpursOfficial fans are saying that teams have "found the solution to Ange-ball", with #Ange being lucky in the first half of the season due to being new, and so no one knew how he would play. Thus he got lucky. I have a different take. #coys
🧵 1/ The thing is, the players are NOT actually playing "Ange-ball" at all right now. There is a marked difference between what the players did early in the season and what they've done in the past 3 months or so. So it's not that other managers have "figured out Ange-ball". #coys
2/

Forget MxP; ALWAYS build the absolute MINIMUM releasable increment first – the simplest possible working product which enables the capability you are looking to provide – EVEN if you don't intend to release it (due to missing functionality desired by stakeholders).
1/ Never increase scope of your 1st releasable increment. By definition it's no longer the 1st/minimum releasable increment if you do that. Always keep everything else as options on the backlog, & have the conversation about (not) adding those things when it makes sense to do so.
2/

Just going through some of my old stuff, found with the search term "agile". Here's a live thread of what I am finding. 1/ Here's a nice little gem from 2015 which I'm quite proud I came up with (if indeed I did!):
"Allow teams to self organise and astound you".
slideshare.net/neilkillick/wh…
Also:
"Enable teams to pick the right tools for the job", and
"Use constraints rather than control mechanisms". 2/

Estimation has been officially removed from Scrum (see new Scrum Guide). Good, because people are way too obsessed with it.

Check out this thread for a non-obsessed and effective approach. 1/n 1. Slice a minimum functional implementation to deliver a useful capability to a customer
2. If number of stories > number delivered in last sprint, check again to see if you can slice further (many functional and technical slicing techniques for this)
2/n

Sometimes I write a lot of explanatory and other documentation, mainly because it helps ME distil and understand what I'm doing. This docco may or may not help anyone else, but the fact it helped me makes it valuable. 1/ How does this sit with "we value working software over comprehensive documentation?" If I am building a software product, I would never make documentation a bottleneck. I would write just enough such that my team and I know what we're doing, & could hand over to another team. 2/

This thread is a letter from a school principal (and something to keep in mind over the coming weeks).
“Dear Parents,
You might be inclined to create a minute by minute schedule for your kids. 1/n You have high hopes of hours of learning, including online activities, science experiments, and book reports. You’ll limit technology until everything is done! But here’s the thing...
Our kids are just as scared as we are right now.
2/n

Prominent experts still saying that planning equates to looking forward to a date and "making a prediction of what would be delivered by then". No! Planning is figuring out what you need to DO to meet an objective. Any "prediction" you want to take from that is a by-product. 1/ This expert's line of reasoning is like saying "it will be a 5 hour drive" equates to planning a road trip. No! Which car should we use? What do we need? What roads will we take? Where should we turn? What is the best time to leave? Where should we stop? *That's* planning. 2/

Any imposed process, explicit (e.g. you must do standups) or implicit (e.g. you must do #agile) is likely to result in anything ranging from low performance to dysfunction. 1/ High performance comes from imposing enabling constraints (e.g. ensure we have a shippable product at all times, ensure we have a frequent feedback loop with the customer, ensure you are continuously improving), not process. 2/

For questions about practices in #Scrum, there are only ever TWO answers. If the context of the question is about the framework itself, and thus the Scrum Guide explicitly answers it, then there's your answer. For all other questions, the answer is "it depends on the context". For example, I just saw a question in a #Scrum Master group: "What is the role of the PO in daily standup?" A long thread of opinionated answers ensued. NO! If you're a Scrum Master, & you are using Scrum, the answer is simple - it's the "daily scrum", & it is for the developers.

Trying a new angle for teaching story slicing, one of the biggest struggles for teams attempting #agile ways of working and arguably the most important practice to understand, given we are trying to deliver value to customers in very short cycles. Read on if you are interested. The way I see it, there are 3 levels of story slicing, each of which is beneficial and necessary to be able to deliver shippable increments consistently in 2 wks or less. I am currently calling them Capability Slicing, Functional Slicing and Implementation Slicing. What are they?