Building Something From Scratch: Week 2

Photo by Austin Distel on Unsplash

Hello, welcome to my blog once again. Today I would like to share my experience so far with the project that I’m working on, and also I want to talk about different tools that my team and I have been using to work in an agile way.

I would like this post to be kind of a cheat sheet to be consulted in the future by anyone that wants to grasp the most basic concepts of the agile methodology for software development.

Cheatsheet: basic concepts of agile

Photo by Eden Constantino on Unsplash

Pair programming

• Build quality into your work by pairing.
• Encourage the pairs to take pride in their work.
• Work together to solve the same problem.
• Look for the simplest design possible and ideas for improvement.
• After a period of time, switch roles with your partner.
• Promotes ownership and commitment to the teammates.

Continuous integration

• Developing a system one part at a time.
• Every time a new part or feature is completed, we add it to what we already have, this is the build.
• Building and expanding the system continuously instead of building the components separately.
• Reduces risk by checking that the system is functional throughout the project.
• Integrating new code from day one and several times a day.
• Continuous integration reduces risk and helps deliver a defect-free solution.
• Offer a working solution and frequent small releases.

Frequent small releases

• The highest priority of agile teams is to satisfy the customer or product owner.
• Do that through early and continuous delivery of valuable, working solutions.
• Agile teams aim to demonstrate a production-ready release to their customer at the end of every iteration.
• The customer decides when the solution goes live not IT.

1. Feedback quickly.
2. Incorporate that feedback into future releases.
3. Quicker return on investment.

• Frequent small releases + continuous feedback = a valuable working solution + good return on investment for the customer.

Definition of done

• An agreed team definition of done is essential to working agile.
• Done: Nothing more needs to be done for a piece of work to be taken into production or go live.
• Identify what can and what can’t be done.
• Identify blockers.
• The definition of done is important for agile teams to accurately measure the progress of their work.
• A story is done when it passes all tests created based on acceptance criteria.
• Use performance tests, for example, to determine if a story is ready.

Burn-up charts

• Measure and communicate the progress of a project.
• A burn-up chart is a metric.
• Serves to monitor progress to make decisions immediately.
• Show progress during the iteration .daily
• A release burn-up chart shows the progress we are making against the release plan.

Test-driven development (TDD)

• Software development discipline where developers write automated test cases for enhancements or new features before they write any code.

1. Basic premise: Begin by writing a failing test for the simplest piece of functionality that you need to implement.
2. Write the simplest code possible to pass that test.
3. New code is reworked/refactor to ensure it meets the required standards.

• TDD helps you ensure quality by focusing on requirements before writing the code.
• Keeps code clear, simple, and testable by breaking it down into small achievable steps.
• Provides documentation for different team members.
• Repeatable tests.
• Enables rapid change.
• Unit test.
• Reworking of the code is called refactoring: happens in minutes not hours or days.
• Test-driven development helps agile teams to make rapid changes whilst, ensuring high quality.

Automated testing

• Helps agile teams to respond to change.
• Provides continuous and early feedback.
• Automated testing helps reduce risk and repeating the manual effort.
• Reliable and repeatable test.
• Reduce testing time.
• Types:
• Unit.
• Integration.
• Functional.
• Story/scenario.
• Automated testing reduces risk and saves the cost of repetitive manual testing.
• To help respond quickly and cost-effectively to change.

Planning poker and the wisdom of the crowd

• Planning poker is a tool that encourages all team members to contribute to the activity of estimation and share their opinions, thoughts, and concerns.
• Estimation happens after prioritizing the work using the Moscow method.
• Requirements on story cards.
• Each member takes a card with a number on it to estimate a story to be done, taking into account information like workload.

Retrospectives: Iterations

• Retrospectives occur after completing an iteration.
• Allows teams to pause and reflect on how they are working together.
• Allows teams to know how they can improve.
• Helps to identify what issues need clarification.
• Regular reflections = retrospectives.
• All information, feelings, and thoughts can be expressed and everyone gets a chance to speak.
• Ideally product owner/business subject matter expert would also be at the retrospective but this is not always the case.
• 3 questions to be answered:
• What worked well?
• What didn’t work well?
• What still puzzles me?
• The retrospective is a meeting where we collect feedback on how we work as a team.

Sustainable Pace

• Working at a sustainable pace ensures agile teams have time to plan, think, rest and deliver effectively.
• What we could do to improve to work smarter and not harder, we started to plan according to our capacity.
• The more relaxed and rested a team is, the better they can perform at a sustainable pace.

Success sliders

• Used to reach agreement on the desired outcomes and facilitate a sheer team understanding.
• They also assess decision-making through the life of the project.
• The sponsor and project owner, need to be involved.
• Analyze scope, cost, time, and quality (how flexible or fixed).
• Sliders are useful to define the success of the project.
• Creating the sliders diagram should happen in the very first phase of a project, also known as the concept phase (concept, initiate, deliver, deploy).

Prioritization (using MoSCow)

• Prioritize and plan the delivery of business value to their customer.
• Capture requirements on story cards.
• The product owner is important in this team effort.
• Separate features on story cards like:
• Most have this attribute or feature, non-negotiable.
• Should have this attribute or feature, should be included if possible.
• Could have this attribute or feature, less critical, “nice to have”.
• Won’t have, least critical, the lowest value would like to have in the future.
• Tasks need to be separated into columns like To do…, doing…, done…
• The power of prioritizing with MoSCow lies in the fact that it helps a team to get a sheer understanding of what is most important to the customer in terms of business value.
• A way to prioritize your stories.

Showcases

• Demonstrate completed work to the product owner, project sponsor, and other stakeholders to get feedback and present and adjust opportunities for the team to course-correct if changes need to be made.
• Separate in columns like Backlog, in progress, ready 4 reviews, in review, adjustment, ready 4 showcases.
• Showcases are meetings in which the team presents their project progress and solicits feedback from the project sponsor and any other relevant people.
• Different viewpoints help with possible course correction and adaptive planning to ensure the customer is getting what they want.

Stand-ups

• Getting together for a daily meeting, each member gives an update:
• What work did I complete yesterday?
• What do I plan to complete today?
• What blockers if any, do I face in getting my work done today?
• Brief daily meetings.
• Progress updates.
• Obstacles.

Big visible charts

• Share project information at a glance.
• It’s all about communication.
• Make our work visible to everyone.
• How your team can communicate project information openly and quickly by using big visible charts.
• Retrospectives and burn up and burn down.

Social contracts

• To create a respectful and safe work environment.
• Example of a social contract:

1. Team social contract: Daily standup meeting is at 9:30 am.
2. Be on time for meetings or pay for a round of coffee.
3. We have zero tolerance for bullying.
4. Don’t dismiss other people’s opinions, instead, listen and try to understand their point of view.
5. Ask for help.
6. Phone and face-to-face conversations with customers/other team members over emails.

• It can change over time, it’s a living document.
• Use social contracts to encourage collaborative behavior and create a respectful and safe environment.
• Have it big and visible (Big visible charts).

Story cards

• Capture user requirements and manage the delivery of user functionality.
• Identify the following to form a story:
• As a…: Who wants this piece of functionality.
• I need…: What the user wants.
• So that…: Why the user wants it, what benefit or value he/she expects to get.
• User stories should deliver business value fast and with less risk.
• Acceptance criteria: Criteria that will let the team know when a story is done.
• A story card allows you to record a compelling story that tells you:
• What the user wants, and why.

Technical things

From my project, I have learned a lot of things. I learned about a tool that slack offers to create and model your user interfaces, it is called block kit builder. This tool allows you to select from a lot of prebuilt templates the one that best suits your project and from there edit, add and create your interfaces. This tool gives you the JSON you need to show the elements that you select.

What I found very useful about this tool is that you can have an idea of the things you can create with your app so you can plan better a design accordingly to the things that the tools bring you. You can actually select from a list of elements different options, they are divided into categories like input, section, actions among others.

Other things that I learned are how to use the different permissions that you can give to your bot to achieve different tasks, those permissions are called scopes. For example, you need permissions to be able to post messages to conversations, then you need permission to send messages to public channels that your bot is not part of. We also need permissions to read messages from channels and to set our commands.

From this project, I have learned how important is to read the documentation that already exists instead of just going to check tutorials. I found fascinating the process of research a solution, try something, fail, then fail again, and finally get it right. This process has allowed me to experience how important is teamwork in this field, I have been feeling very comfortable with my work, I haven't felt overwhelmed thanks to my peers.

In general, I have learned Javascript, which is Node.js and Bolt framework. I have been feeling well working with these technologies even being completely new to them, I feel I have adapted very well thanks to reading documentation, being self-taught, and receiving help from my team solving doubts. Finally, I also think that writing documentation allows you to really understand the solution and the technology you are developing, and it's an exercise that will guide you in the future and solve problems for others.

Thank you for reading my blog, I hope you learned a lot. Have a nice day!

Photo by Niclas Illg on Unsplash