Month 2 - Building something from scratch

Overview of the month.

This month we did a lot of things with just 4 weeks to finish everything. We literally had nothing we didn't even work before together and some way or another we got to build something. There are a lot of things to go over, a lot of things that we learned during these 4 weeks. I have what we did in my weekly journal. Here, in my monthly journal, I'm going to do a fast overview of what we did and I'm going to try to write down what I mostly learn and that I take with me.

Activities

The goal of the phase was to work with a client to develop an application using some agile practices and some CI and CD. We had to do all this in 4 weeks and to do a demo to the client each week, seems easy but it wasn't. We had to do this in a team we had to separate in roles and do different things that we had never done.

In the first week, we had to meet our clients and know what are their needs and now their process and pain points. We did a plan on how to do an interview and what to ask to get well-defined requirements to do our plans, once we had some information we tried to understand the process and write it down. We did a proposal and show it to the client and we had to make some minor changes and well... that's week one.

The second week is when we were going to start to code and finish everything fast and iterate and try to get quick feedback, well... those were the goals. We had problems with the selected front-end technology we weren't masters and some members of the team had never coded in that technology. At this point, I considered that as a blocker and I told that team that... but they just said that we had to put more effort into what we were doing and remember from the reset phase, a technology or a language is just a tool so let's keep striving and focus and learning. That's what we did, but at that point, we didn't have something to show to the client and we had to understand at this point that not only the UI is something valuable for the user we can show other important things. That's what we did for our first demo, we did a video and showed how the back-end works using Postman, this might sound crazy but that's what we did.

In the third week, we were working on learning and striving to finish the front-end components, and yes! we did we really manage to do something, we were working fast and agile, but we had a little problem. We finished tasks but only the ones that were supposed to be finished on week 2... so we now have a delay of two weeks. Problems once again, what are we going to do now?

We learn a lot of things here, we learned that first, we have to tell our clients what's really happening and the client is someone that we have to trust and be clear with them. The second point is to negotiate to try to find the exact point where the client's scope is not reduced and on the other hand where the coding process is not that hard for us. That's exactly what we did and we simplified things trying to cover all the scope and we made a new proposal and finally, we show it to the clients and they accepted the simplified version.

In the fourth, we had to do the tasks that we didn't finish in week 3 and the actual week ones. But in this week we were working so differently from other weeks, we were kind of fast and effective, agile. We manage to finish everything and to solve bugs and do some manual testing. In the end, we had a new brand and fresh system... I'm going to share o couple of screenshots.

The login page.

One of the main pages.

In the final demo, we got positive feedback from the clients, they really liked the system and they told us that was great work based on the time that we had. They were so grateful and kind to us and we felt really good, I mean we strived and focused on getting something I think is something that we deserved. We are also really grateful because they spend time with us answering our doubts and sharing things. Thank you for your time and patience, we learned a lot of things from you guys BAMX-HMO.

Lessons learned from the phase.

- We have to learn how to work in teams and with this, I mean having the right organization and tools that work for the team. Teams have problems and they solve them but also team members support other members.

- We need to understand and use tools that are meant to be used for a purpose, remember that tools ease our lives.

- Technologies, languages, frameworks, etc are just tools, use them like a tool that shouldn't be a blocker for us.

- Sometimes at work, you have to do things that you don't like and are part of it, which is going to happen commonly. We have to see things differently, change our attitude towards those things that we don't like and the end is our responsibility.

- Teams make decisions as a team no individuals and you have to learn how to live with that, even if you feel like you are right and your team doesn't.

- The client is your friend you have to trust them and tell them the truth about everything, they will appreciate that. Also, you have to know your limits and say no when needed.

- We have to learn how to manage our time also how we use our time, is not healthy not getting some sleep, he needs to communicate when something is not going to be finished in time.

- We need to listen to our clients and what are their needs. Also by doing quick iterations we enable immediate feedback and we can make changes fast in an agile way.

- Software is built by teams there are not geniuses, we need to collaborate. Is also important to remember that software is built by humans and we have our problems.

- Estimating in software projects or any projects is not that easy, you will commonly find errors in the estimation in time or even cost. It takes time to do good estimations.

---

Videos

Agile practices

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: Things That Gain From Disorder - Nassim Taleb - Animated Book Review

• 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.

How do we heal medicine?

• Autonomy was our highest value.
• We've reached the point where we've realized, as doctors, we can't know it all. We can't do it all by ourselves.
• We have trained, hired and rewarded people to be cowboys. But it's pit crews that we need, pit crews for patients.
• That is to say, they found ways to get all of the different pieces, all of the different components, to come together into a whole.
• Having great components is not enough... we don't think too much about how it all comes together.
• Now a system, however, when things start to come together, you realize it has certain skills for acting and looking that way.
• Skill one, find where your failures are. Skill two is devise solutions.
• We looked at skyscraper construction, we looked at the aviation world, and we found that they have technology, they have training, and then they have one other thing: They have checklists.
• Designing a checklist to help people handle complexity.
• You have to think about things like pause points.
• You need to identify the moments in a process when you can actually catch a problem before it's a danger and do something about it.
• You have to identify that this is a before-takeoff checklist. And then you need to focus on the killer items.
• There's a deep resistance because using these tools forces us to confront that we're not a system, forces us to behave with a different set of values.
• This is the opposite of what we were built on: independence, self-sufficiency, autonomy.
• In every field, knowledge has exploded, but it has brought complexity, it has brought specialization. And we've come to a place where we have no choice but to recognize, as individualistic as we want to be, complexity requires group success. We all need to be pit crews now.

The Black Swan: The Impact of the Highly Improbable

• "The Black Swan: The Impact of the Highly Improbable"
• Defines a "black swan" as a highly improbable event with three principal characteristics: It is unpredictable; it carries a massive impact; and, after the fact, we concoct an explanation that makes it appear less random, and more predictable, than it was.
• Black swans underlie almost everything about our world, from the rise of religions to events in our own personal lives.
• A central idea in Taleb's book is not to attempt to predict Black Swan events, but to build robustness to negative events and an ability to exploit positive events.
• "Robustness" reflects an attitude where nothing is permitted to fail under conditions of change.
• The book asserts that a "Black Swan" event depends on the observer: for example, what may be a Black Swan surprise for a turkey is not a Black Swan surprise for its butcher.
• Hence the objective should be to "avoid being the turkey", by identifying areas of vulnerability in order to "turn the Black Swans white".
• Taleb has referred to the book as an essay or a narrative with one single idea: "our blindness with respect to randomness, particularly large deviations."