The article I found today that I want to write about is titled “My 5 Biggest Screw-Ups as a Scrum Master”. I chose this article because the title of it really jumped out and resonated with me when I read it. I figured it would give me some good insight on what it’s like to be a scrum master and possibly have some good tips or tricks on how to avoid common mistakes when you’re new to it.

The article mentions his five major mistakes and how he fixed them, which I’ll get into below.

For the first mistake, he mentioned how when he heard differing viewpoints than his own, he would be upset. He fixed this by putting himself in the other people’s shoes, and trying to understand why they were seeing it how they were. For his second mistake, as it sort of ties into the first one, any feedback he got was very tough to swallow. To fix this, he actively sorted out as much feedback as he could in order to get used to it and learn from it. For the third mistake, he pretty much just simply allowed his group to “self-manage” on their own, but it led to a lot more confusion than anything. To fix this, he set goals and clear responsibilities for all members of the group but still allowed for the sense of freedom that self-management implies. As he says “it gives a sense of direction and vision for the state they want to achieve”. The fourth issue was missing out on signs of lack of trust; meaning not realizing the group members may have issues with each other. For his solution here, it really seems he doesn’t really have one. He tried everything he could but, at the end of the day, the two group members were never going to get along. I guess the takeaway here is to just recognize this and either reconstruct the group or direct your energy elsewhere. The fifth issue, working beyond his experience, was simply just that. He thought it would be a piece of cake to be a scrum master, but it was far from it. He learned you must expand your comfort zone by going into uncomfortable situations with the intent to learn, and that honesty is extremely crucial.

Although we learned about Scrum in class, this article did a good job summarizing and explaining the issues you may experience within it, especially as a first time scrum master. It’s honestly probably something I would have never thought of and I probably would’ve made the same mistake as the writer by thinking it would be a piece of cake. Because of this article, I now know a little bit more as to what to expect whenever I have my first big project as a scrum master and HOPEFULLY I can avoid some, if not all, of the mistakes made by the person here.

Link: https://medium.com/serious-scrum/my-5-biggest-screw-ups-as-a-scrum-master-f912be2ed2d4

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

This week, I found a study on adopting design patterns in an IT organization. The study was conducted by the University of Oregon, and a link to the study can be found at the end of the blog. I selected this study due to the fact that it dove a lot into software design patterns and why, if they are implemented correctly, they can be extremely beneficial for a company to use.

The overall purpose of this study was to, as stated in the study, provide a scholarly annotated bibliography that examines software design patterns. It wants to provide IT leaders with proof that the implementation of design patterns can achieve increased operational efficiency or the delivery of strategic benefits.

By the end of this study, you can see some clear benefits of using a good design pattern. Operationally, there is a reduced development time as well as as a reduction of errors. This is due to the development process being streamlined, as well as being reusable with tested solutions. Strategically, patterns can contribute to a system that scales over time without a lot of rework, which is huge for organizations with rapidly evolving needs. Patterns also must create a shared language which inherently allows for better collaboration between different teams working on a project.

The study also goes over how it can be implemented using phased adoption; implementing patterns gradually allowing for people to adjust. On top of this, it mentions periodic review and sharing of documentation/knowledge, two very important ideas in terms of efficiently and affectively using design patterns.

Having read this study, it certainly reinforces a lot of the ideas we mentioned when discussing design patterns. I wouldn’t necessarily say everything I read was new, and the new sounding information may have just been worded in a different way, but the study certainly did a good job as sort of drilling the benefits of why a good design pattern can be highly beneficial.

This study also opened my eyes in the sense that I feel as though in my career I may keep an eye out for how different design patterns could be implemented into any projects that I’m working on. Being able to cut back on time, while still completing different jobs in an effective manner is something that will be very important and possibly put you above other people. If I demonstrate a knowledge of design patterns and can implement them well, or at least suggest them, it may at the very minimum open my companies eyes to different possibilities.

Link to study: https://scholarsbank.uoregon.edu/server/api/core/bitstreams/b5d95a74-77d6-454b-9ed5-1f2af2633f8a/content

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.