Week 5 - What I learned

2021/05/10 to 2021/05/17

Overview

This week was the start of a new phase where we are going to do different things. We have to build an APP or platform for somebody and we only have this month to do it, so we have to go through a lot of things so this is the first week of the month and this is how we started.

---

Agile practices

This was a series of videos about agile and I'm going to paste my notes here, about what I learned or notice:

Pair programming

• Working together in the same computer side by side trying to solve the same problem
• One writes code and the other one worries about other stuff.
• They change roles commonly.
• The idea is to produce higher quality work at a faster pace.

Continuous integration

• When you build a new part of the system and reviews it is added to what we already have this is what (the whole system or the build).
• Continuous integration is building and expanding the system continuously. Adding new parts constantly.
• Integrate new code often and early.
• The result is that we keep the system free of defects and we can keep adding features to it confident the real building.
• Reduces risk and helps deliver a defect-free solution.

Frequent small solutions

• Continuous delivery of valuable and working solutions
• Feedback quickly.
• Incorporate the feedback in future releases.
• Quicker return of investment.
• Deliver business value to the customer quicker.

Definition of Done

• Definition of done will help them to decide when the work is completed.
• Is important for agile teams to accurately measure the progress of their work.
• Can identify smaller checkpoints of done.
• A narrative which is my artifact to express done. These might be a sketch of feedback from a prototype screenshot and even some technical considerations.
• Work has to be reviewed by another developer and successfully integrated into the current version of the solution
• A story is done when it passes all tests created based on the acceptance criteria

Burn-up charts.

• Provide a reliable basis for decision-making and course correction.
• Plot the scope of the release, any changes to scope, and the actual delivery rate
• Is a metric
• Visibly shows information.
• The to do.

TDD

• Is a discipline where software developers write tests first that code.
• Fail-> Pass->Refactor
• Benefits: Helps ensure quality by focusing on the requirements instead of the code
• Makes code simple and clean.
• Works as documentation.
• It Helps teams make changes quickly.

Automated tests.

• Provides early feedback, helps teams reduce risks and manual work.
• Is a suite of automated tests. Is developed as the project grows.
• Automation helps to find bugs.
• Regression tests run all the previous tests.

Planning poker

• To estimate the effort required to get the work done.
• Estimation happens after having user stories.
• Everyone gets a deck of cards, each card has a number and you have to choose depending on the task to do.
• Reflects the size of the story.
• That is used to estimate all the users' stories.

Retrospectives after iterations.

• We deliver work after iterations this enables stopping and reflections, these are call retrospectives.
• Everyone gets the opportunity to speak.
• Answer three questions:
• What worked well?
• What didn't work well?
• What still puzzles me.
• We could even say what we learn.
• We are looking at how to improve the team.

Sustainable pace

• Working at a Sustainable pace ensures that agile teams have time to plan, think, rest and deliver effectively.
• Work smarter and not harder.
• Plan according to capacity.
• Find the team pace. We don't want tired and pressed developers.

Success sliders

• Indicates how scope, cost, time, and quality can move.
• Move between fixed or flexible.
• We can also see the trades-offs and adjust those things.

Prioritization using MOSCOW

• Deliver the cards with the most business value as soon as possible.
• It is a team effort.
• Must, should, could, and won't have are categories and the team discuss in which category to put the users' stories.

Showcases

• To demonstrate completed work to the product owner project, sponsor, and other stakeholders to get feedback.
• Show the stakeholders the progress of the project on a whiteboard.
• We get feedback and helps with possible course correction and adaptive planning to ensure the customer is getting what they want

Standups

• What did I do yesterday?
• What am I going to do today?
• Any blockers?
• Is a meeting where everyone stands up and answers the questions.
• No more than 15 minutes
• Everyone gets updated.
• Is not a report.

Big visible charts.

• Big visible charts. To make our work visible to everyone.
• Team members updating it constantly throughout the day.
• Here you can see the progress.
• Communicate project information openly

User stories

• To capture user requirements and to manage the delivery of user functionality.
• From the perspective of the user.
• As a ... I need ... so that...
• Deliver value
• Acceptance criteria when the story is done.
• What the user wants and why.
• Backlog.
• They work to prioritize and device the work

Antifragile

• Something that breaks is fragile, something that not is robust but there is another thing called antifragile.
• Antifragile is getting a little bit of poison to be stronger. It means becoming better through your struggles.
• Sometimes you have to fail to get to success.
• Chaos leads to growth.
• We have to learn to be antifragile.
• We have to grow from hard situations.

The optimism bias

• We tend to overestimate our likelihood of experiencing good events in our lives and underestimate our likelihood of experiencing bad events.
• We're more optimistic than realistic.
• We're not so optimistic about the guy sitting next to us.
• Most of us put ourselves above average in some abilities.
• No matter if we fail or succeed we are going to feel depending on how we interpret that event.
• Regardless of the outcome, the pure act of anticipation makes us happy.
• Without the optimism bias, we would all be slightly depressed.
• Optimism changes reality.
• Optimism makes you try harder.
• If we expect the future to be bright, stress and anxiety are reduced.
• Unrealistic optimism can lead to risky behavior, underestimate the costs and durations of projects.
• Knowing optimistic bias we should be able to strike a balance, to come up with plans and rules to protect ourselves from unrealistic optimism.
• To make any kind of progress, we need to be able to imagine a different reality, and then we need to believe that any reality is possible.

---

Activities of this week.

We did a lot of things this week. The goal of this month is to build something from scratch, software to solve some problems, we got nothing. To start to build software we have to know what we want to build, so this is what we did this week, I'm just going to write down some activities here:

Interview, process and proposal.

The first part was to meet our clients and know what was the problem and the process of their work. We had an interview with them and asked a lot of questions about the process we didn't focus on the solution yet.

We really wanted to understand the process so we wrote it down and discuss it and this really helped us to understand a lot of things. We asked questions and finally, we identified the problems the pain points.

After understanding how things work, we sat down and found the scope of the solution, and tried to brainstorm everything and that's how we build the proposal, mixing everyone's ideas.

Requirements and taskboard.

To write down the requirements we used user stories and a user story is: a user story is an informal, natural language description of one or more features of a software system and should have the following points:

That's how we wrote down the requirements and tried to choose the ones for the first iteration.

To organize and separate the tasks we used a kanban board.

We have 7 columns in our kanban board:

• Stories: We can find all the user's stories here.
• To-Do: The user's stories for this iteration.
• In progress: That ones that we are working in.
• Testing: The ones that are being tested.
• Code review: The ones that are being reviewed by our mentors or teammates.
• Done: The ones that are done and ready.
• Blockers: This is for blockers that we might have and we want everyone to notice.

Those are some things that we did to start coding.

---

Conclusions.

I have two main lessons for this week, the first one is that you don't start coding right away, you have to do a lot of things related to people and management to start a new project, so not everything is coding. Is a very hard task trying to think like a client, I mean when finding the solution for a problem it is not that easy to get to the solution that could fit your client's need so that's why you have to think like them and it is part of the project and it is not as easy at it seems.