I run a lot of workshops, including planning workshops and retrospectives. Sometimes the crew votes on things like “what is the best feature, or how did we go this time.”
But sometimes we collect data and then want to discuss it as a team. And this presents a challenge – I like data in a spreadsheet and I like pictures on the wall but sometimes it seems hard to capture numbers in a useful way in the workshop.
But do not fear – the River Diagram is here and this is exactly what it is for.
[Editors note – this is a long an obscure article that made sense to me and some people I explained it to. If it is not making sense half way through abort rather than continuing … it either makes sense early on or does not make sense at all]
I was running an agile course on how to facilitate good work in agile teams. We had some great discussions about conflict being good and people being unleashed to create value rather than being held back by managers who try to control them to force them to add value.
But then we had a less comfortable conversation. Someone asked what you do with someone who is being a [bad person] in an agile team.
Some people believe that if you are evil then you have no values and that you will be good at office politics, but that if you are good then you will have strong values and be really bad at office politics.
I believe that regardless of whether you are good or evil, you will be really stressed if you do not know your values and you will be really bad at office politics if you do not understand and manage your personal brand.
Apparently office politics is a horrible thing that other people do.
But many of the emerging IT leaders I speak to get told they need to be better at “soft skills” and “influencing at a senior level”. What this often means is get good a politics.
Sadly a lot of office politics seems to involve people playing games to get their own way at the expense of everyone else. This skill can be learned and might seem useful, but it is not what I am going to talk about here. I am going to talk about “how do the good guys get the right outcomes when people have competing interests or needs and some people seem like knob-heads”.
I often seem to face the same problem – how can I reduce my resources, increase my scope, improve quality and go faster?
The best answer is – be clear on what you really want and decrease your scope. Sadly that is the opposite of what people want to hear, but usually delivering the right thing (done well) is better than delivering a lot (even if its done well).
But I have also found that the grinding task of trying to fit more in and failing can actually help you define what you really need. So I often find the process worthwhile even though I end up with a different scope rather than a bigger one. So here are some ideas I have tried:
I was speaking to some experienced Agilistas about whether “Agile” had a good or bad reputation at the moment.
We spoke about agile maturity models, agile certification, real agile versus pretend agile and even whether there was a right way to do agile. We did not come to any agreement about whether certification and maturity models were good or bad but we did agree there was no one formula for success in agile.
This seemed logical at first but then I thought there really should be one formula we can apply. That way we can simply measure people on whether they are using it and correct their approach for them.
So after minutes of detailed research and experimentation I came up with the following formula.
Critics of “logical communication” will quite rightly make the point that a document can be logical, but boring, irrelevant and completely un-compelling. This is true and I should get to talking about it soon.
But before I do I wanted to talk about “Bad logic”.
In my last article (“Is that logical?”) I discussed a way to test the logic of a statement. But a document filled with logical statements can still be gobbledegook if the statements are not linked together logically.
So how can we assess the overall logic of a document?