Four points, that make the difference between a good and a really good presentation. (And no, that's not me in the picture.)
We project workers spend a lot of time communicating. According to the PMBOK Guide between 75 and 90 percent. Half of this time we spend with (hopefully) active listening. The other half we are presenting, lecturing, and telling different people different things. In short, we are transporting information. And in my opinion, it is incredibly important not to transport just some thing, but the right thing. I know, right now I am sounding like a motivational poster. Na no na ned, as we say in Austria - of course. Of course, we do not communicate just something somehow. Nevertheless, I can see exactly that pretty often. But what is the essence of a good presentation?
..the nitty-gritty is less the way of presenting, but rather the content of the presentation. And yet, I am regularly seeing people standing on a stage and rattling off their NLP-Hocus Pocus. Cheap trick, so to speak. What is the talk about? Who cares. It is all right as long as the audience is mesmerized by all those sleight-of-hand tricks. Only, the audience does care. They want to hear some content.
Junior Woodchucks camp
It does not matter if someone is one of those people who are moving in with a stack of moderation cards, or - like me, I admit it - to those who prefer to conduct their presentations on the fly. In any case, there is one particular secret behind a good presentation: an incredibly intensive preparation. I'm not talking about the presentation itself, but about the topic. How can I tell others about a topic, if I am not having a good grasp of it? Not at all, in my eyes. It is necessary to know more than my listeners. Otherwise, such a lecture is a waste of time for all involved.
Walk like a duck, quack like a duck
The next duck-heading, I'm sorry, I can not help it. But it just fits too well. Let us switch the meaning of this witticism: if I wade like a duck, I will quack like one. That means, you should, and you have to pay attention to a proper posture in your presentations and moderation. Why. Two reasons:
"Here's looking at you, kid!"
Finally, our headlines are leaving Duckburg. My last point is a realization. When you are standing in front of a group of people and give a lecture, there are many faces. So virtually a 1 to n relationship. But turn the situation around. If you are one of those people in that group, technically it is still a 1 to n relationship, but for you, it feels like a 1 to 1 relationship at that moment.
Regarding that there are so few points that make the difference between a good and a bad presentation, I've already written way too much. So here is my crisp summary:
And I know, those points alone do not make a good presentation. But for me, they are the basis for one. Because without these four points, it will definitely be a not-so-good presentation. And unfortunately, there are far too many of those. But that is another topic.
What agility has to do with (much) efficiency and (often not so much) customer value, and why cookies are not always the right choice.
“Come to the dark side. We have cookies.”
First things first: I am seeing today's topic through the eyes of project management. And through that lens agility is a great idea. But what exactly is the great thing about it? Why do many people and organizations embrace "agility"? Because it is different. Another approach to getting things done. A different approach than the way many organizations are using. Because let us be honest. Even today, there is still an incredible number of companies whose leadership firmly believes that C2 - Command, and Control - is the best way to have a productive and thriving business. And if you are part of such an encrusted, sedated structure, an agile approach sounds great. Of course, it does. Daring though, but very tempting. Faster decisions, faster work-done, less time-to-market. Different.
I hate to be the naysayer again. But what is the dark side of an agile approach? And let us just ignore the arguments that I am hearing from a certain type of software developer over and over again ("Agility is bad because I've done well without agility for 20 years. That was a great time! We didn't bother about those customers and we spent every night fixing bugs.") - so, quotes, arguments, quotes. But I am sure you all have heard this a couple of times.
Not every company is manufacturing software
Agile methods have an insanely strong focus on software development. Yes, it is getting better. But whether if it is ASD, Scrum, DSDM, or - God forbid! - SAFe. In their origins, some of these methods were developed by programmers and most definitely had programmers in mind. And even the agile manifesto is still officially called Manifesto for Agile Software Development. And where do we see agile methods introduced in companies? In my observation, in the overwhelming majority of cases, it is the IT department or more specifically software development.
But what happens, when the IT is working and thinking agile, but the remaining 95% of my value chain is not? Chaos at the interfaces. And yes, Kanban can help a lot. But - and now I have to be careful - in my eyes (and the eyes of many others), Kanban is not part of the agile world. It is more Lean Management. Similar matter altogether, but another. Matter altogether. And yes, your magic-agility-coach told you otherwise, I know.
Kaizen and a steady improvement in small steps are fine and dandy. But every now and then it just takes a bit of Kaikaku. The big time. And I won't be able to achieve that if I am spending my time thinking in User Stories. Because that is contagious. And even if the strategy on the top level is good - the best strategy won't help me if the visions get shredded beyond recognition on their way to the implementation level. But that is what I am observing in many organizations that switch to agility: a rigid set of rules is replaced by another rigid set of rules. And then all are writing small User Stories and eventually everyone is thinking small. Good as gold. However, I will not experience any movement.
Standstill through prioritization
Agile methods live from constant prioritization. But, if only the currently most important things are implemented - who will take care of the right things? Those who may not be the most important at the current situation and time (and in my little world), but on a larger, more global scale. They fall by the wayside. And that is how I slow down my organization enormously in the long term. And at some point, I arrive back from where I started: Standstill. Standstill through prioritization.
Efficiency is not always the same as customer value
Agility creates teams that are maximally efficient. This pleases management and controlling. Agility thus also creates teams that have completely lost sight of the customer value. And that is also my main criticism of the way agile methods are often interpreted and lived.
But why is the customer value neglected? One word: velocity. At some point, teams only have this number in their heads. The average Story Points done per Sprint. The team's pace. And everything is subordinated to this team's pace. People will not rely on their own gut feeling. How much work I can accomplish as a team in the next few weeks. No, people are calculating. Because the Scrum Guide says so. (And here we are again with rigid systems.) So everyone is drawing down the line on their burn-down chart. How many Story Points have they done today? Rather than talking about what value has been generated for the customer. Instead of talking about how they have supported and advanced their own organization today. And many Scrum Masters participate in this madness, without even questioning it once. Because the Scrum Guide says so. (And yes, I'm just cynical and unfair now, I'm sorry!)
So what does that all mean?
What can I do better when talking about the above points? How can I avoid the negative and reinforce the positive?
The most important thing first. If I want to change my organization, I should consider whether agile project management methods are generally the right ones for the change part (ie the projects). If I am not better off looking from project to project - where am I on the complexity matrix? - and then deciding which approach to choose. Predictive, incremental, iterative, whatever.
All in all, agility is certainly a good thing - as long as I am using it for the right problems. And it's not outdated (even if agile project management methods are much older than the trend would have us believe). But maybe there is no one-size-fits-all when it comes to project management. And so maybe it is time for something new again. This time, not something different, but something better.
What good teams have in common with good bands.
As a trained guitar player I love some good jazz. Well, I love all kinds of music. But even those who are not much into jazz music at all, have to admit that they are astonished when musicians seemingly effortlessly deliver the wildest improvisations. But what is behind this genius? Dark arts? It is said that Jimi Hendrix never had a single music lesson in his life. So is it all talent? Or is there more than just pure musical sense? And what does all this have to do with teams?
First, let's clarify what jazz improvisation - or generally improvisation in music - actually is. Improvisation is when one or more people make music without previously written down fixation. That is, the played notes and melodies arise spontaneously.
Again, what does that have to do with teams?
In our daily project work, we are experiencing this every day. This interaction of people, which has not previously been fixed. And even if our planning is good and detailed and almost perfect - at the implementation level we are owing much to the spontaneous ideas and inspirations of individuals.
And here is our big 'but'. As in making music, this is only working when the people involved know exactly what they are doing, and are prepared well.
Learning from the best
Here we can learn a lot from musicians like Miles Davis, Chet Baker, or Judy Carmichael. Good improvisation has a rock solid basis. Because none of the above just went on a stage and started playing music. On the contrary, there is a lot of training and rehearsing and preparation behind it. So spontaneous improvisation is not so spontaneous at all. And it is not totally free either. There are chords and scales and a lot of formality. Does that ring a bell? Let me say it in other words: there are methods and processes and a lot of formality. Ha! Our daily business, right?
Of course, I can handle projects without these methods and processes. And there are certainly some Jimi Hendrixes of the project management world, who can do without formality and without their company going bankrupt. But personally, I have never experienced a haphazard project that did not go up in flames at some point. Did you?
So what are these good jazz bands doing and what lessons can we draw from them?
Conclusion - how can I use that for myself
It does not matter if I am building a team for a big project from scratch, or if I am working with a veteran group. But I always try to create an atmosphere in which teams can live those above points.
I can not force formality and rules. This has to come from the team. I can only pave the way and make suggestions. And mutual consent and trust can also not be created on command. They come naturally when team members feel secure. And only when everyone has agreed on basic rules and everyone knows how things are going, valuable improvisation can arise.
Oh, if anyone still wonders if it's true that Jimi Hendrix never had any music lessons: Jein, as we say in Austria. Yes and no. Billy Davis (https://en.m.wikipedia.org/wiki/Billy_Davis_(guitarist)) showed him a few things on the guitar. And Buddy Guy (https://en.m.wikipedia.org/wiki/Buddy_Guy) once claimed in an interview, that he had given Hendrix some lessons. So by and large, Jimi Hendrix is self-taught. But that is a different story.
Agility and why some organizations fail. A train of thought.