Author: Ezra Jesalva

There are many tools and tricks incorporated into agile to ensure quality software is distributed. Of these tools are a set that focus on learning on your past actions. The two most prominent ones are Retrospectives and Post Mortems. In this article we shall discuss both of them, and talk about the differences between them.

The first one we shall talk about are agile retrospectives. Agile retrospectives happen at the end of each iteration, when the current sprint is just released. In the retrospective, the point is to look back and praise the things that were done well, but more importantly point out things that could’ve gone better. The article, “Agile Retrospectives” goes deeper into this.

The article splits retrospectives into an agenda, which includes these things: the prime directive, the appreciations, and the goal setting. The prime directive is spent mostly talking about things that weren’t as smooth, and brainstorming better alternatives. The author makes it clear that in retrospectives, facilitators should trust that everyone did their best, and that it should not turn into a name and shame game. Appreciations talk briefly about the good, and goal setting is important as well.

In goal setting, often times people work on making SMART goals, so that in the future they know what they can focus on to make sure that the retrospective was a success. The other type is Post Mortems.

The main on-paper difference between retrospectives and post-mortems is that post mortems happen after the end of a whole project (Post Morts Vs. Agile Retrospectives). Due to this, a lot of times there is not a lot people can do to improve the project. While agile has retrospectives at the end of a sprint, meaning that there are more to come, Post mortems happen at the end so any feedback or critique would have to be used on a  completely different project. There are other differences too though.

Retrospectives are often handled and facilitated by upper management. Because of this, there is a lot of nice, clean documentation that talks well about the things that were accomplished, and then “placed on a shelf and ignored (Post Morts Vs. Agile Retrospectives).” It’s a very sterile, procedural thing that many employees just have to do. While agile retrospectives can also be turned into “just-another-procedure”, because Post Mortems are set after a project end  this feeling is much more prominent.

These are the differences between retrospectives and Post Mortems, hope you learned a lot and will use this on your next project!

Works Cited

“Agile Retrospectives.” Agile Pain Relief, 28 Feb. 2019, agilepainrelief.com/notesfromatooluser/2010/05/agile-retrospectives.html#.XMdtWuhKhEZ.

SoftwareDevTools. “Post Mortems Vs. Agile Retrospectives.” SoftwareDevTools, SoftwareDevTools, 22 June 2018, softwaredevtools.com/blog/post-mortem-vs-retrospectives/.

“Https://Www.yodiz.com/Blog/Wp-Content/Uploads/2015/11/Agile-Retrospective-Yodiz.png.”

In agile we have several principles and ideals that we have to uphold. Making sure that everyone is aligned with these values is an important piece to effective agile software development. At the forefront of this housekeeping is the scrummaster. In this article, we shall discuss what exactly a scrummaster does, and all of the responsibilities therein.

The scrummaster is a team member seen specifically in the scrum methodology of agile. As a scrummaster, you are expected to be very knowledgeable in the ways of the scrum, and agile in general. Because of this, you are able to tweak the scrum practice to best fit your teams needs (What is a scrum master?) Having someone who is an expert in agile that can serve as a coach for using best agile practices has a lot of benefits.

The main overall benefit for having a scrummaster in the team is a more streamlined process. Scrum Masters are focused on increasing the quality and level of output, and they do that either directly or indirectly. Some examples of doing things indirectly would be things like coaching other team members on the ways of scrum, helping facilitate conflict resolution, and more. More direct examples, (as we shall discuss later) include things like introducing tools to make the process more efficient.

Day to day, the responsibilities of a scrum master include “clearing obstacles”, “establishing an environment where a team can be effective”, “protecting the team from outside distractions. (What is a scrum master?) ” This all sounds very abstract, so what does it mean?

Scrum Masters are usually the facilitators in the daily standups. They are also supposed to act as servant-leaders. They help protect the team by even advocating for them to higher ups (like stakeholders) so that the higher-ups are more understanding of these new processes. They also serve in other ways too. (What does a Scrum Master do)

They help facilitate other “scrum ceremonies”, like sprint retrospectives. They also do more talking for the team like talking to funders to get better tools to act in a more agile way. Since they are so good with scrum and agile and maybe even other methodologies, they are familiar with a wide array of different tools to help speed up the process. One way this would be helpful is that the Scrum Master might introduce tools like Kanban, and Burndown charts. They “establish an environment where a team can be effective” in a lot of ways.

This is what Scrum Masters do, hope that helps paint a better picture!

Works Cited

“Https://Hematestingstuff.files.wordpress.com/2015/07/Scrum-Master-Rr.jpg.” Https://Hematestingstuff.files.wordpress.com/2015/07/Scrum-Master-Rr.jpg.

“What Does a ScrumMaster Do on a Daily Basis.” Agile Velocity, 8 Mar. 2019, agilevelocity.com/scrummaster/what-does-a-scrummaster-do-anyway/.“What Is a Scrum Master?” Agile Alliance, 3 Dec. 2018,

http://www.agilealliance.org/glossary/scrum-master/#q=~(infinite~false~filters~(postType~(~’page~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)~tags~(~’scrum*20master))~searchTerm~’~sort~false~sortDirection~’asc~page~1).

As a business analyst, you know that you are the liaison between the product team  and the guys with the money.You need to make sure requirements are communicated and documented out so the developers know what to build. A key part of being a good analyst is understanding how to interact with the stakeholders. In this article we shall discuss key topics to grow in this regard.

(Business-Analyst-Role)

The first topic is about developing empathy for your stakeholder. This is a very important part of good communication and understanding with stakeholders. When you put yourself in your stakeholders point of view, it allows you to ask deeper questions that further cement your understanding and increase the quality of your documentation. Some good questions to ask yourself when meeting the stakeholder would be like, “Why would the stakeholder want this certain feature in this particular way?” “What is the overall business value of this piece of the product?”

When you put yourself in the stakeholder’s shoes, it allows the you to better negotiate with them (10 proven stakeholder tactics). Let’s say for example your team wishes to switch to the agile methodology and you are explaining this to the stakeholder. By thinking beforehand about what sort of counter-arguments they might come up with, it allows you to better prepare yourself. “They might want to stick to this particular methodology because they were the ones who originally proposed it,” would be an example of a good thought to have.

The second topic for better communicating with stakeholders is involving them more in the team. Within agile, this is a key principle. Stakeholders are not just passive people from above. Yes, the business analyst should make sure that the stakeholders are getting what they want, and a part of doing this is involving the stakeholders more.

Why is this important? When people want a certain thing done, often times they are not good at articulating it. However, “people are fairly good at indicating what they think they want and then when an option is presented to them what they like and don’t like about it (Building Empathy).” When we encourage the stakeholders to take on a more active role, misunderstandings and communication greatly increase.

One way to do this would be allowing Stakeholders to attend standups. When the stakeholder knows what the developers are actually doing day to day, it would do a number of things. First, the stakeholder is able to feasibly measure just how well the progress is going. Second, it allows the stakeholder to talk about the different activities that are going on and even reduce certain activities when they realize how long they are taking.

These are ways to increase your communication with stakeholders. I hope this helps and that you use it in future projects!

Works Cited

Maier, Andrew. “Digital Service Delivery | Build Empathy with Stakeholder Interviews, Part 2: Conversation.” 18F, 22 July 2016, 18f.gsa.gov/2016/07/22/building-empathy-with-stakeholder-interviews-part-2-conversation/.

Wolpers, Stefan. “10 Proven Stakeholder Communication Tactics.” Age of Product, 9 Dec. 2017, age-of-product.com/stakeholder-communication/.

“Http://Businessanalyst.techcanvass.com/Wp-Content/Uploads/2017/08/Business-Analyst-Role-1024×576.Jpg.” Http://Businessanalyst.techcanvass.com/Wp-Content/Uploads/2017/08/Business-Analyst-Role-1024×576.Jpg.

Agile development is development following a set of rules and principles to guide the way work is produced, and the way teams and individuals work together. In this article, we shall discuss the agile method of failing fast.

In Agile, there are 12 principles to follow (“12 Principles Behind the Agile Manifesto”). Failing fast is relevant to “Continuous Attention to Technical Excellence”, and Delivering Working Software Frequently. In agile, we value working fast and getting stuff done over meticulously planning for every detail. We know that stuff happens, and we adapt a framework to account for that unpredictability.

Image of the Manifesto –  AgileManifesto.png

What is Failing fast? When we fail fast, we don’t worry too much about the consequences of our actions; it is about doing things rather than sitting back and fearing failure. It is the very opposite of laborious planning; it is prototyping and re-iterating and learning from your mistakes. It is about trying something and then getting feedback: Does it work? How can it be improved?

Why should we do this? Many times when you communicate with your stakeholders, you could have everything laid out, and you are both on the same page. Prototyping goes even further than this. It shows the stakeholders something feasible. It gives the stakeholders something to experiment with and it establishes a baseline to come up with even better ideas. With prototyping, it allows you to make something quick and dirty (sometimes not even 100% functional) so that you avoid making something with the best quality but then having to redo everything. Prototyping goes a long way into saving time and ensuring quality for the final product. There are other reasons too.

In day to day development, there is a phenomenon known as “paralysis analysis.” Let’s pretend a certain developer knows what he or she needs to do – implement feature x. However as they start thinking about how to do it, they realize they can use option a, or option b, but then option c! They get stuck, running in circles analyzing the drawbacks and benefits of each, stressing about the “perfect solution.”

This is where the beauty of failing fast happens. Rather than creating all that stress, after enough consideration just choose one, and see how it works. Failing fast allows developers to say that there is not a perfect solution, just one that works at the time within reason.

And that’s about if for failing fast! Hopefully you would have understood exactly what failing fast means, and even gotten some ideas on how to implement it in future projects.

Works Cited

“12 Principles Behind the Agile Manifesto.” Agile Alliance, 15 Nov. 2017, http://www.agilealliance.org/agile101/12-principles-behind-the-agile-manifesto/.

http://Blog.itil.org/Wp-Content/Uploads/2014/08/AgileManifesto.png.