I promised a couple of people that I would provide a sample coaching contract, along the lines of what I use when I am engaged in agile coaching. so here is one I prepared earlier, aligned to coaching a specific person.
In my last post I talked about about presenting new ideas to people.
But sometimes you need to be a little bit more convincing – Especially if you do not yet have credibility with the group or if your idea might by challenging what people currently think.
Let’s say for example, that you are telling business analysts that they are not needed anymore, or if you are explaining to a project manager that they do need a BA even though it will cost them money. People will not accept these statements at face value.
You can plead with people to believe you, but that rarely helps. You can yell and scream – but nobody will care. So what can you do?
I gave a friend some feedback on his facilitation style recently. I suggested the he “introduce new ideas really well and stuff.” Great advice, but perhaps not very specific or useful.
Then I ran a facilitation related course and gave people feedback on, among other things, presenting ideas to the team. There seemed to be a pattern where people were passionate about what they were saying, but not clear on exactly how to say it.
So what does “introducing new ideas really well and stuff” entail?
Firstly, passion and authenticity count. But there are also some basic mechanical steps that you can take to structure a message so that you are clear on what you want to say and the audience is more likely to take it in.
I went to the IIBA professional day in Melbourne and I gave the morning keynote for the day. There were about 270 business analysts their to learn about all things BA.
I thought I would publish the talk because a couple of people asked me about the content. Apparently there is still some confusion about business analysts on agile projects … and I assume also on data science, political and design thinking type projects.
I work with people going agile. Sometimes it is an awesome experience and sometimes it is quite depressing.
For example, I worked with some good, experienced people a while back. They were were pretty sad before I turned up and pretty happy that I came to help them. This is the part of the agile coaching experience that is awesome.
Before the dawn of agile:
- Business cases took longer to get approval than some projects took to deliver; and
- Worse than that, some projects took longer to die than the fading spirit of the team members on the project.
Then I arrived, crashing through the window with index cards in one hand and a mandate to free the people from tyranny in the other.
This is where I like to play.
Editor’s note – Unfortunately this article turns out to be a long read, so grab a cup of tea, or just look for some nice pictures and skip all the boring text.
I recently wrote an article on coaching where I suggested building a toolkit of different approaches to use when coaching people and teams in different things.
This is my (very basic) tool for teaching a skill – it is called “what why how”.
I use it when I want to help someone develop a specific skill that I am confident I can teach and give feedback on. For example, running agile meetings or business scoping workshops.
I was talking to someone today about “2-speed IT” and whether it is:
- An excuse to avoid going agile, while still hoping to be invited to all the cool “go digital” fun projects; or
- A recognition that different types of technology require different approaches, requiring IT teams to adopt a strategic view.
I started to explore my thinking on this when I found that the argument had already been succinctly captured elsewhere. So here is a quick summary of other people’s thinking about what “2-speed IT” means and why it is good or bad.