-
Notifications
You must be signed in to change notification settings - Fork 0
Potential things to blog about
No technical stories, and no sub-tasks. Just stories (and production bugs). Everything should have business value, otherwise we shouldn't do it.
Advantages:
- gets everyone thinking (and talking to each other) about business value, which is what we want.
- ensures that developers don't sneak in things they want to do but have no value
- enables the product owner to be aware of what's being worked on
This could be two related but separate blog articles actually. One for the stories and one for the sub-tasks. Sub-tasks are bad because they encourage silos and hand-offs, and lead to less focus on business value. Add some examples. Also leads to (sometimes considerably) more work being done than is needed. Quite often the culture is not great, and developers want to "just code". This has disastrous effects.
4 Accelerate metrics - all you need to accompany business metrics. Don't have maturity metrics. Don't have too many technical metrics. Use my site as an example
Go - why it’s such a good choice.
Go and JS (Gatsby) as the only languages, for everything (including e.g. replacing shell scripts) https://www.thoughtworks.com/insights/blog/praise-go-script-part-i
Coronavirus and value stream mapping - cutting out waste Might want to wait until the dust has settled before blogging this one, have a think
Ed Conway’s great article about the petty bureaucracy with the covid bank loans
Outside-in testing
Focus on the many benefits it brings:
- ensures developers have customer focus and a value-driven approach (e.g. makes it far less likely that they will go rogue and build something way more complicated than it needs to be. The customer value becomes the thing that gives them purpose. Otherwise the developers may only pay lip-service to the business value, and instead build something interesting technically to give them their fulfillment.
Explain why (in Go, for instance) considering the unit to be the package is a huge improvement on considering a struct or function to be the unit, but it’s still not “outside” enough. Instead, write the first tests based on how the behavioru of the overall system you are building, from a user perspective. Then only go lower than that if needed.
Why (when engaging with a team for the first time) starting with stand-ups, or trying to teach them the basics of an agile framework (e.g. Scrum, Kanban, etc etc) is likely to fail.
- psychological reaction is naturally going to be that change is being done to them, not with them
- they may well think of you as the scrum police
I’ve seen many coaches I work with fall into this trap, which is one reason why I’m blogging about it here. It’s natural for coaches to want to make a positive impression (and demonstrate to whoever is sponsoring them that they can make a difference quickly), but there be dragons. Good news is that you can still make a difference quickly.
Much better to go very easy on the frameworks, and instead have one to ones with the team to get to know them. Explain you’re on their side. Ask them plenty of questions, and listen (actively). Good news is that you can still get them to care about value and the bigger picture, by asking them to:
- describe their current typical day
- map out their view of the team’s current workflow, their own position within it, and how long each stage takes, roughly (i.e. value stream mapping, but don’t call it that straightaway when engaging with the team, as using jargon is not going to help your first impression with them)
- map out the bigger picture behind some of the work that the team currently does (i.e. story mapping, but don’t call it that straightaway, for the same reason as the value stream mapping).
Do all of these things collaboratively with the team using paper, post-its, tables, walls, whiteboards. To start with I like each team member to do it individually, and then do it together (sometimes gradually, using a technique like 1-2-4-all - but again, avoid the jargon if you do this, just do it). You can use your expertise in this way to subtly introduce the team to what collaborative work feels like in this way, by having them do it with you. And by doing the things above the team will also experience the benefits of them (the team) visualising their work: by seeing the bigger picture in an active way they will then start to see all sorts of potential improvements. This is gold dust and is exactly what you’re there for as a coach: to have the team sustainably and continuously care about improving.
Go very easy on the stand-ups to start with, either by not attending at all, or attending and just listening.
If you try to “fix” the stand-ups rather than doing collaborative work with the team, you won’t be working with them. They won’t really engage with what you suggest. Always do things with people, not for them.