I'm currently working as a team lead / delivery manager, at Triodos Bank, supporting awesome dev-teams.
This (overwhelming) curated list touching every aspect of leadership is very nice!
It has collections of links to articles about all kind of Leadership and Management related articles.
Very useful!
Also, nice that it is a Github page, written in Markdown.
https://github.com/LappleApple/awesome-leading-and-managing
In this article Simon Powers asks : “What is Agile?”
It’s a question that’s been asked (too) many times, but again, it’s in Agile’s nature to keep changing so the question will probably stay around for a while 🙂
The article is about this diagram:
The bottom line is:
Many organizations think that they’re agile with only the right tools & processes ( like Jira and Scrum).
And they have no clue about the outcome of a truly agile Mindset.
I think he’s right. We should work on Agile Mindsets. I’d like to call it Agility.
An article worth reading here
Dan Sloan aks to challenge everyone in our workspace with the (sometimes annoying) WHY-Question.
“Why” do we exist?
“Why” are we working on these particular Features? What makes it essential for our Customers?
“Why” do we use Scrum to optimize business outcomes? How can we make it better and more focused?
“Why” do we use this backend?
All very useful questions, that give reason for and purpose to some of the things we do.
You can split them into two types: Content related (“Why feature A?”) & Proces related (“Why scrum?”)
It seems that, when joining a new company, many employees tend to ‘fit in’ the existing system. They adjust themselves to the company and pick up the existing routines or tools. Which is not a problem, until…. changes need to be made.
Then the reason for a choice, system, way-of-work matters a lot. Explicitly asking for (and documenting afterwards ) the why of choices when you make them, will make future adjustments easier.
For the more proces related, the Scrum master should constantly check with the team whether the way of working is fully optimized. Of course, the issue with “fitting in” when joining a team is the same for proces. The awareness that the team itself is responsible for the way they work will be raised by the why-questions.
Dan suggests to start asking why tomorrow at work, first thing in the morning. Although the questions are important, they’re also a very hard… So they’re only valuable if asked to teams with the right mindset. A team member could not feel safe enough to express his/her own answers to the Why-questions.
So, use a retro, which has (should have) a ‘confidence-atmoshere’ by default, have lunch or coffee and ask 1 to 1.
So:
– Why is Why the most powerful word?
Because it will optimize.
– Why?
Because it will help people to challenge the status quo.
– Why?
Because no solution or proces is ever 100% ready.
Although the example talk is extensive, the message of this article is clear:
You should not expect to be able to greatly influence people if you do not spend any time with them, or if you do not hear what they have to say. If they do not talk by themselves, make them talk by asking good questions.
I’m a good listener, and still in my role as a scrummaster, it’s hard in every conversation to remember that the other person should do the talking…
http://tombartel.de/2016/05/05/if-you-want-to-be-understood-listen/
In this article, Simon Kneafsey describes his experience with a scrum master who was educated as an actor.
Laurence worked only 2 years as a tester in a scrum team when he volunteered to become a scrum master.
The only thing he could do, was learn to ask questions to make the team come up with solutions. Just because he simply didn’t know the answers. As opposed to many CSM’s who have a very technical background and quite often start acting as managers.
In this case, Laurence just learned how to act as a scrum master, which was just another role to him.
Laurence served as the conscience of the team. kept them focussed on finding the best solutions and challenged them to keep doing this.
I’d like to be like that.
The 2 Best Scrum Masters I Ever Worked With – The Master Of Coaching And Facilitation
Barry Overeem wrote a list of common pitfalls in Scrum, you might recognize (a few) in them.
Today, the one resonating with me is this one:
Demonstrating the results to the Product Owner, instead to the stakeholders
We can definitely improve on that one!
A lot is written about Scrum. And Gunther also wrote a good story about signs you may have a wrong idea of it.
Basically he states:
Scrum is not a list of artefacts, but it’s a state of mind.
I totally agree.
As a ScrumMaster, I’m not interested in having standups; I’m interesting in facilitating a way for teams to communicate about their work, their progress and their (potential) impediments. We do the things that are needed to facilitate this. So in our process we do have standups, retros, refinements and demos. But only as a result of the mindset.
Worrying interpretations of Scrum