Finding the right email notification plugin for JIRA is not an easy task. You’ll find plenty of options and you’ll simply don’t know which one you should use. Also, most of them seem to be so expensive for what they offer in terms of value that you sometimes just give up on your search.
Using native JIRA notification feature is not intuitive and will require a lot of time in terms of research, configuration, notification schema setup, cross-project discussions when you’ll have multiple projects affected, in summary: frustrating and exhausting. People are even tweeting their frustrations and making fun of the situation:
JIRA offers an all-or-nothing approach according to my previous experience. You either receive a lot of email notification or none. This might be one of the weakest features of JIRA from my perspective.
The pains above plus the problem I was trying to solve were exactly the reason why I created Issue Events Mailer, an easy and flexible way to send email notifications based on JIRA Issue Events.
Give it a try for 30 days. It might be what you’re looking for.
I was simply not finding something simple and cheap at the same time – paying $1000 dollars for a plugin that sends e-mail was not an option for me and for many other companies as well. But I really wanted to solve the problem I was having at that time. Thus, I decided to create the plugin to solve my own problem and offer it to others as well as an alternative to expensive JIRA email plugins.
I’m not sure if there are any statistics about this, but last year I decided to keep track of many stuff. One of these things is which retrospective exercises I used and how often.
The idea was dead simple. I kept a text file where I recorded for every retrospective I facilitated, which exercises I used. There were 46 distinct exercises in total. You can check the full list below.
Quick note: In total, 73 retrospectives at least. Not that bad. At some point, I stopped tracking because I changed my position from Agile Coach to Tech Manager and there were some moments of transition where retrospectives were not possible as well for the teams otherwise the number would be much higher.
As you can see above, the winner was the classic brainstorming exercise. This one is a very good choice when you don’t have too much time to prepare or you’re not in the mood for an awesome session. That’s for sure a good choice for suchlike moments. I usually follow the brainstorming exercise with some solution discovery exercise such Lean Coffee so we can figure out some actionable stuff.
It was a surprise for me that the Perfection Game was one of my favourites as well. The experiences I had were always positive with this exercise. I’m not exactly sure why, but people usually like it and I do as well. Perhaps it’s because of its objectivity and quick way to figure out what to improve. If you don’t know this one, I highly recommend it for your next retrospective. Give it a try and let me know if you and the team enjoyed it as well.
Another insight from the data is that I didn’t use often the first approach we all learn when it comes to retrospectives. The “Went well, Went bad” approach. I know why this one was not used too often. It was intentional. I wanted to provide to teams different approaches and also compare same approaches between teams. I see retrospectives not only as a super opportunity to teams but also for me to experiment, learn, and compare approaches between teams in order to understand better their dynamics and peoples reactions to such exercises. This helped me so far to maximize in the great majority of cased, the return of time invested by the team on retrospectives.
Retrospectives nowadays became such a cliche that I try to be very careful not to just provide the “fun” part of it, but also make sure that the “professional” purpose of it is also delivered to the teams. By professional, I mean to use it as a tool to foster continuous improvement inside agile teams.
The funniest one, for me at least, was the Unlikely Superheroes exercise. Although I did it once, I have good memories of it and how people also had fun during the exercise while trying to portrait their strengths and weakness into a superhero character. Since this was a very personal exercise, no pictures were taken otherwise I would be able to share here the coolest superheroes that were created during the session.
What about you? Did you keep track of your retros? Which method did you use? How to know if you’re heading in the right direction? How do you know which exercise works better for you and for the teams? Share with me your perspectives and techniques. I’d love to learn more about it.
I have my own personal way of preparing for retrospectives. It’s nothing revolutionary or fancy, but it helped me a lot to facilitate and learn from each retrospective. If you’re interested in knowing about this procedure, leave a comment here or just drop me a message on Twitter @jcfausto.
I usually like to read these recommendations because I think it’s a good way to understand how the ideas on these books influenced other people’s works, Anyway, let’s jump to the review.
The book is a quick read, the type of reading you can do in a few hours. But don’t’ get yourself fooled by its size, because it’s indeed a very good book to help you understand and manager better bottlenecks. The book explains very well what a bottleneck is, the types of bottlenecks – according to Clake’s own taxonomy -, and how to deal with each type of bottleneck in order to achieve better performance without necessarily working harder.
The major contribution of the book, apart from explaining with lots of examples what a bottleneck is, is the FOCCCUS procedure, which provides as a guide on how to properly address bottlenecks.
FOCCCUS stands for:
Start again (strategically).
But, what is a bottleneck?
According to Clake’s definition, which I personally like, a bottleneck is: “a resource that can’t keep up with the demand placed on it”.
And what is a resource in this case?
“a resource is a person, a machine, a computer CPU, a traffic intersection, a slow internet connection, and even an airport runway”
I’ve said many times over my career a statement along the lines of: “This step here seems to be the bottleneck in our process”. After reading this book, I’ll probably never say that anymore. I’ll probably say something like this: “We’re seeing a bottleneck here on this step of the process, let’s figure out which resource is causing it”.
Another insight from this particular topic is that in order to analyse a bottleneck you’ll have to map which resources are involved and then figure out which of the resources is the actual bottleneck.
I remembered a story told some time ago where a coach was coaching a group or middle managers on a traditional company and once the coach entered the room, the first thing he said was: “We’re here today to find a bottleneck, but just so you know: The bottleneck is in this room”. Just a fun memory I had while writing this article. Let’s move on.
Once you find a bottleneck, it will look obvious.
That’s another interesting observation made in the book. Be aware that bottlenecks once identified will always look obvious. That’s because you’re looking at them in retrospect, and now the “Hindsight bias” is working on your brain. As said in the book: “You’ll find it invisible in a minute and deadly obvious the next”.
Some Types of Bottlenecks
Wild bottlenecks – Often hidden and they’re either unmanaged or poorly managed.
Tamed bottleneck – Don’t have as much capacity as we’d like, but they are visible and managed.
Deliberate bottleneck – Designed to deliberately limit the flow through a system.
Right-stuff bottlenecks – Are tamed bottlenecks and their work has been properly curated so they are working on the right stuff.
Right-placed bottlenecks – Are not only tamed but they are where they’re supposed to be.
A note on the “Deliberate bottleneck” type: If you’re familiar with Kanban, this is one of the reasons why we use WIP limits. WIP limits are bottlenecks, but the type of bottleneck deliberately placed to limit the flow of work in progress through the System.
Why identifying and managing bottlenecks could be a good idea for you?
The bottleneck determines a system’s output. No matter how fast other resources are performing, your global performance will be limited by the performance of your bottleneck. Sad, but true.
There’s a myth that says that “If everyone is busy, we must be productive”. Busyness is not a synonym of productivity. You don’t need to work harder to get more done, you must work smarter! If your team runs faster than your bottleneck, they’re just being busy, not productive. Take a look at the book cover illustration again. There are some people pushing rocks down, but there’s only one person moving them forward. This person is representing the bottleneck and no matter how fast others push rocks down, there could be only one rock moving forward at a time. That’s exactly what system’s thinking teach us regarding the benefits of global optimisation over local optimisation.
Be careful about easy solutions
Once you identify a bottleneck, might not be difficult to think about a solution for it. But be aware that usually the first solutions we think are usually not addressing the real issues. In order to address the real issue, you’ll have to dig deeper into the bottleneck, understand which resources are involved and their relationship and finally experiment with some solutions. This won’t come easy for you. You’ll have to open to challenge some assumptions and pre-conceived solutions.
In the book, Clake shares a story of a bottleneck involving a printer that was not printing the pages fast enough. It was not coping with the demand that was put on it. One might think that a solution would be to buy more printers or to buy a modern one that could print pages faster. But when digging deeper into the problem, it was discovered that the bottleneck was not the printer, but the software that was sending pages to the printer. Thus, the printer was just following the speed of the real bottleneck, that was not so apparent as it was the slowness of the printer.
I really recommend The Bottleneck Rules to anyone that wants to learn what a bottleneck is and especially for those who work with software development processes such Scrum or Kanban and want to get another perspective on constraints without necessarily having to read “hardcore” books. This one is accessible both in terms of price and language, practical, and will teach you a valuable tool that you can use in your work with your clients or employers.
Finally, if you read the book, please let me know what your thoughts. I’m interested to know if you also will find it as good as I did.
You can find me on twitter @jcfausto or just leave a comment here below.
PS: I didn’t say anything about the title of the book, did I? Well, read the book and you’ll know what I’m talking about!
I’m not affiliated with the author nor receive any benefits for reviewing this book. This review is totally independent and based on my own perspectives and interpretation of what I’ve read.