Author: Ana Moreno

Ways to Improve Agile Retrospectives

Posted on by Ana Moreno
https://agilesphere.eu/business-transformation/focusing-on-outcomes/

If you’re not sure where a retrospective falls in a sprint, it happens at the end. The group should be able to talk about what went right and what went wrong. The purpose is to improve with each sprint. It is not to blame others of something that failed. How does this play in into everyday work life? When we talk about what we need to improve, that’s what needs to be in focus in the next sprint. It should not just be a meeting of what needs to be changed, without follow ups. However, doing the same thing in every retrospective can be boring and tiring, specially when they take longer than expected.

There are many ways to change retrospectives and make them fun. They could be easy things like bringing snacks or by being creative by taking a different approach. Here are different ways to approach retrospectives:

Start-stop-continue: This is the simple one where team members are asked what they should start  doing, stop doing, and what they should continue (Similar to what we have done in class)

www.luis-goncalves.com

Speedboat retro: The island is the vision/goal for the project. The Wind is what pushing the team to the goal. The rocks are risks that should be analyzed. and the Anchor is what could hold the team back from meeting the goal.

Rotating the retrospective facilitator: The facilitator of the meeting shouldn’t always be the Scrum master. Instead, they should let one of the team members facilitate the meetings. Every person has a different style of facilitating, so other team members will not be bored of the same person. Giving the role to a team member can also make them think differently of the meeting. Pablo Pecora says “I find it challenging to give the facilitator role to team members. It makes them think more and participate while they empower themselves” (Pecora)

What happens when the team members think they shouldn’t have a retrospective? Some team members might believe in skipping a retrospective if they don’t really have anything in mind to talk about. This is probably not the best idea for the team. Retrospectives should never be skipped because it creates a habit (Lindqvist) Reflecting what the team has done always creates feedback.

Retrospectives help not only improve future sprints, but mainly the teamwork in a group. If a group is not doing well communicating, after their first retrospective, the team should know how to better communicate with one another. It gives everyone a stage to talk about what they believe went wrong and how they can improve from there until the end.

Citations
(Pecora, Pablo) https://www.hexacta.com/2017/09/25/5-ideas-to-improve-your-next-scrum-retrospective/
( Baldauf, Corrina ) https://retromat.org/blog/what-is-a-retrospective/
(Lindqvist, Alexander) https://uxdesign.cc/why-skipping-the-retrospective-is-a-big-mistake-4a78e182e093

Scrum & Kanban

Posted on by Ana Moreno
https://www.cuelogic.com/blog/scrum-vs-kanban-a-developers-on-the-project-comparison

There are many different tools and resources a software development team can choose in order to complete a project. We will be covering Scrum and Kanban, some differences between the two, and how to choose between the two when working in a team.

“The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master”(Scrum.org) Most Scrum teams are self-driven and organized and choose the best way to complete their work. Scrum is a framework for effective teamwork collaboration that can be used by products big and small. Scrum includes daily scrum meetings and sprint plannings. At the end of the sprint, there is a sprint review. after, there is a retrospective where they discuss what they did and how to improve.

https://www.wrike.com/blog/scrum-vs-kanban-board-project-plan/

Kanban is also another framework that is also another framework used. There are 3 principles for Kanban. The first is you visualize what you do today. You need to see the work flow and the items in each context. The second is to limit the amount of work in progress (WIP). This is to balance the flow-based approach so tasks don’t stack up all at once. And the last one is to enhance flow. Once something is finished, you can pull the highest task from backlog (Collab). A Kanban board keeps your team members informed on what needs to be done, what needs to be started, etc.

There are some things that make Scrum and Kanban different. One of them is Kanban doesn’t require Product Owners and Scrum Master. Scrum involves the team working in one sprint together, while for Kanban, the board can be used by anyone working on the project because it is not cross-functional. Kanban also allows for continuous work flow, while Scrum has fixed lengths of sprints.

So which one of these would best work in your project? According to Daniel Barreto there are two main things that should decide it:

  1. “The team’s maturity” (Barreto)
  2. “The expected level of change within a project.” (Barreto)

If your team already has experience working in agile but is expecting a lot of change throughout the project, your best bet would be Kanban. If you have a team that’s just being introduced to agile and you think there will not be many changes, scrum will be easier for them. Luckily you can apply Kanban and Scrum to both teams large and small, so that will not be a problem in deciding which you should implement

Citations

(Scrum) https://www.scrum.org/resources/what-is-scrum
(Daniel Barreto) https://www.mindtree.com/blog/how-choose-between-kanban-and-scrum
(Collab) https://resources.collab.net/agile-101/what-is-kanban

How Business Analysts fit in Agile Teams

Posted on by Ana Moreno
https://www.zarantech.com/blog/why-its-great-time-to-be-business-analyst/


The Business Analyst is one of the most important roles in an Agile Team. This article will cover what the business analyst role in agile is, and why we need this in an Agile team (Should we rethink this position? What could possibly go wrong with this position?).

A Business Analyst is in charge of finding solutions and needs for stakeholders and team members. They serve as the bridge for the two. Basically gathering information from stakeholders and passing this down to the team members. You can think of the stakeholders and team members as different languages and the Business Analyst as the translator. The BA will get a clear understanding of what the other side is saying and will “translate”. This role has many duties depending on the type of project being completed and what phase is being done. There may be times where the BA is data analysis, quality testing, or project management. “We use our various skills, tools and techniques to clarify and define a business problem or opportunity, then work closely with all stakeholders to develop a solution that fully meets the business’ needs, today and tomorrow” (Skracic).

There are many reasons to have Business Analyst role in a team. According to Ambler, there are three main reasons to have a BA. These are, Developers can’t elicit requirements. Most developers lack the knowledge and communication skills to write their own requirements. Stakeholders can’t model and document their own requirements. This is one of the reasons why a BA works as a bridge/translator for stakeholders and team members since the stakeholder does not have the training and support. And third, the project needs analysis experts. Developers are more as specialist, and you need someone to analyze and have resources for the project.

Although there are many positive reasons to have BAs in an agile team, there could be times this position could bring a team down. This could be anything like the BA lacks the skills or the BA is the communication barrier of the team. Therefore it’s important to have the proper training and experience for this job. Overall, Business analysts can break or make a team project.

https://www.acorel.nl/2018/08/must-haves-in-a-business-analyst-toolkit/
(Business Analysts as a “bridge”)

Citations

(Higgins, Tony) https://www.blueprintsys.com/blog/three-ways-business-analysts-fit-into-the-agile-methodology

(Ambler, Scott) http://agilemodeling.com/essays/businessAnalysts.htm

(Skracic, Luka) https://elabor8.com.au/what-does-a-business-analyst-actually-do/

The Importance of Agile Development roles

Posted on by Ana Moreno


When we think about agile teams, the role that mostly comes to mind is the team member. Although the team members are the creators of the system, there are many roles that come to play in this production.

Starting with project executives/sponsors, they provide the goal, vision, and objectives for the project. They also provide the team with resources. However, unlike project managers or product owners, sponsors usually spend more time on the business side rather than spending time on specific projects.

On to the Product Owner, they are considered “active stakeholders.” They represent a wide range of many different stakeholders. Their responsibilitiy is defining a work item list, aka the product back log (Scott). Meaning that they should have a vision to what the item is suppose to do.

Next, it’s the Development Manager. They’re responsible for the delivery of the project. They’re the scrums of scrums, and will help out the team by clearing obstacles and make sure the team is on track of the schedule. Overall the development manager coordinates the overall team.

Below, it’s the Scrum Master. Scrum masters have many roles which include obtaining resources, supporting team rules, building high-performance teams (Scrum Master). They also provide team meetings (daily stand-ups) where they facilitate. The Scrum master is the representative of the team, and they work with other Scrum masters in the Scrum of Scrums meeting to coordinate work load.

Lastly, the Team Members. As stated before, the team members are the creators of the project. Team members responsibilities range from modeling the product, programming code, and testing for quality. They deliver business value.

Agile Development Teams include many different roles. Each role plays a crucial part in the creation of the product.


Citations

Ambler, Scott. Roles on Agile Teams: From Small to Large Teams, http://www.ambysoft.com/essays/agileRoles.html.

“A Project Sponsor Isn’t A Project Manager, Scrum Master or Product Owner!” Software Process and Measurement, 3 Sept. 2014, tcagley.wordpress.com/2014/09/03/a-project-sponsor-isnt-a-project-manager-scrum-master-or-product-owner/.

“Scrum Master.” Scaled Agile Framework, http://www.scaledagileframework.com/scrum-master/.



History of IT Project Management

Posted on by Ana Moreno

According to the website “Your Dictionary”, project management is the “practice of planning, organizing, securing, and managing the details and resources of seeing a project through the end”. For this reason, you know that we as humans have been project managing for quite awhile now. Many big structures created in the past like the great wall of china took time, planning, and resources. Many different types of management philosophies have been introduced between 1900s and now like Gannt Chart, theory of constraints, SCRUM, Work Breakdown Structure (WBS) (Which we have seen in Microsoft Project), etc.  One of the most popular methods of project management was first introduced in 1970 with the Waterfall method. As we have previously learned, The waterfall method has a downwards linear flow which includes 5 different stages: Requirements. Design, Implementation, Verification, and Maintenance. Though it does have many disadvantages, it’s still commonly used today. As projects started to become more and more complex and took more time to develop, Agile started become to be used as practice. The Agile manifesto was created in 2001 and is one of the most commonly used methods in project management. The Agile method as described in the Agile Foundations Video, contains these steps. Envision, Speculate, Explore, Adapt and close. The major difference from this and Waterfall was that after adapt, you loop and go back to speculate until you have gone through all your iterations.

https://www.yourdictionary.com/project-management
https://expertprogrammanagement.com/2010/12/a-brief-history-of-project-management/
http://www.umsl.edu/~hugheyd/is6840/waterfall.html