Agile: Day 10

Please visit the primary source of the below information - Scrum Guide - Click here

Agile scrum 

Agile scrum is a way of handling complex projects that blends the agile philosophy and the scrum framework. The agile philosophy is based on delivering value to customers faster and with fewer problems by splitting the work into small, but usable, increments. The scrum framework is a set of values, principles, and practices that help teams organize and manage their work through a set of roles, meetings, and tools. Agile scrum is fit for any team that works on complex products, especially software development teams. Agile scrum enables teams to:

• Work and communicate well across different disciplines and functions

• Change and react to change quickly and continuously

• Learn from experiences, feedback, and experiments

• Deliver work in fixed-length iterations called sprints, usually less than 30 days each

• Check progress and status daily and at the end of each sprint

• Focus on customer needs, preferences, and challenges

• Support innovation and improvement"

Scrum Roles

Scrum roles are the three accountabilities or roles that form a scrum team. Scrum is a way of handling complex projects that follows the agile philosophy and the scrum framework. The agile philosophy is based on delivering value to customers faster and with fewer problems by breaking down the work into small, but usable, increments. The scrum framework is a set of values, principles, and practices that help teams structure and manage their work through a set of roles, meetings, and tools. The three scrum roles are:

• Scrum master: The scrum master is accountable for ensuring that the scrum team adheres to the scrum values, principles, and practices. The scrum master also leads the scrum events, such as sprint planning, daily scrum, sprint review, and sprint retrospective. These events help the team plan, coordinate, review, and improve their work. The scrum master also assists the team in resolving any impediments or challenges that may hinder their work. The scrum master is a servant leader who supports and coaches the team to work effectively and efficiently. I am CSM - If you wish to learn more click here

• Product owner: The product owner is accountable for defining and prioritizing the product backlog, which is a list of features and requirements that the team needs to work on. The product owner also communicates with the stakeholders and customers to understand their needs, preferences, and challenges. The product owner also works with the scrum master and the developers to ensure that the product delivers value to the customers and meets their expectations. The product owner is a visionary who guides and inspires the team to build a great product.  I am CSPO - If you wish to learn more click here

• Developers: The developers are accountable for doing the work that delivers the product. They have the skills and expertise needed to design, build, test, and deploy the product. They also work with the product owner and the scrum master to plan and execute the sprints, which are fixed-length iterations of work. They also inspect and adapt their work based on feedback and experiments. The developers are a creative and collaborative team who delivers high-quality products.

These three roles work together as a self-organizing and cross-functional team to deliver complex products faster and with fewer impediments. They share a common goal, vision, and responsibility for the product. 

Scrum Events

Scrum events are the five events that occur within each sprint. Scrum is a way of working on complex projects that follows the agile philosophy and the scrum framework. The five scrum events are: 

• Sprint planning: Sprint planning is an event where the scrum team plans the work for the upcoming sprint. The scrum team consists of the product owner, the scrum master, and the developers. The product owner presents the product backlog items that are the most valuable and important for the product. The developers estimate how much work they can complete in the sprint and select the product backlog items accordingly. The scrum master facilitates the discussion and ensures that everyone understands the scope and expectations of the work. The scrum team also creates a sprint goal that describes the outcome and benefit of the sprint for the customers and stakeholders.

• Daily scrum: A daily scrum is a short event where the developers synchronize their work every day. The developers meet at the same time and place for 15 minutes or less. Each developer answers three questions: What did I do yesterday that helped the team meet the sprint goal? What will I do today to help the team meet the sprint goal? Do I see any impediment that prevents me or the team from meeting the sprint goal? The daily scrum helps the developers stay focused, aligned, and accountable for their work. It also helps them identify and resolve any issues or dependencies that may affect their progress.

• Sprint review: A sprint review is an event where the scrum team demonstrates the product increment they created during the sprint to the stakeholders and customers. The product increment is a potentially releasable piece of functionality that meets the definition of done. The stakeholders and customers provide feedback and suggestions for improvement. They may also express new or changed requirements or priorities for the product. The product owner updates the product backlog based on this feedback. The sprint review helps the scrum team inspect and adapt the product based on customer needs and expectations. It also helps them validate their assumptions and hypotheses about the product value.

• Sprint retrospective: A sprint retrospective is an event where the scrum team reflects on their performance during the sprint and identifies what went well, what can be improved, and what actions they will take to improve. The scrum team discusses how they worked together as a team, how they followed the scrum values, principles, and practices, and how they used their tools and processes. The scrum master facilitates the discussion and ensures that everyone participates and feels safe to share their opinions. The scrum team agrees on one or more improvement actions that they will implement in the next sprint. The sprint retrospective helps the scrum team inspect and adapt their process and teamwork. It also helps them enhance their skills, knowledge, and collaboration.

• Sprint: The sprint is a time-boxed period of one month or less where the scrum team works to deliver a potentially releasable product increment that meets the sprint goal. The sprint goal is a short statement that summarizes why the team is building this increment. The sprint contains all the other events: sprint planning, daily scrum, sprint review, and sprint retrospective. The sprint starts with sprint planning and ends with sprint review and retrospective. No changes are made to the scope of work during the sprint that would endanger the quality or value of the product increment. The sprint is the main container for delivering value to customers.

These five events provide a structure and rhythm for the scrum team to work effectively and efficiently. They enable transparency, collaboration, adaptation, and feedback among the scrum team and the stakeholders. They also help the scrum team deliver products that meet customer needs and expectations faster and with fewer impediments.

Scrum Artifacts

Scrum artifacts are the information sources that a scrum team uses to define the product they are building, the work they are doing, and the value they are delivering. Scrum artifacts help the scrum team and the stakeholders to be transparent, inspect, and adapt throughout the product development process. The three scrum artifacts are:

• Product backlog: The product backlog is a prioritized list of everything that the product needs based on the product goal. It includes features, enhancements, bug fixes, tasks, or work requirements for the product. The product backlog changes and grows as the product evolves. It is owned and ordered by the product owner who communicates with the stakeholders and customers to understand their wants, needs, and problems¹².

• Sprint backlog: The sprint backlog is a list of product backlog items that the scrum team agrees to work on during a sprint. It also shows how the scrum team will do the work. The sprint backlog is created during the sprint planning event where the scrum team selects the most valuable and important product backlog items for the sprint and splits them into smaller, doable tasks. The sprint backlog is controlled and updated by the developers who can add, remove, or change tasks as needed during the sprint¹².

• Product increment: The product increment is a potentially shippable piece of functionality that meets the definition of done and the sprint goal. It is created during the sprint by completing the tasks in the sprint backlog. It is shown to the stakeholders and customers during the sprint review event where the scrum team gathers feedback and ideas for improvement. The product increment adds value to the product and meets customer needs and expectations

Scrum is a simple framework that consists of a few roles, events, artifacts, and rules. However, applying scrum effectively requires a lot of discipline, collaboration, and continuous improvement from the scrum team and the organization. Scrum challenges the traditional ways of working and thinking and demands a shift in mindset and culture. Therefore, scrum is easy to comprehend but hard to put into practice

Agile DevOps is a methodology that combines agile software development with devops practices to help organizations deliver features and updates faster and more efficiently. The main goal of Agile DevOps is to shorten the feedback loop between developers and operations teams so that changes can be made quickly and efficiently.

Agile DevOps is a comprehensive agile methodology for product development. Unlike how Agile replaced conventional waterfall project management, DevOps is a succession to agile and not a replacement. Agile methods are often called frameworks and are comprehensive approaches to phases of the DevOps lifecycle: planning, development, delivery, and operations. They prescribe a method for accomplishing work, with clear guidance and principles. Scrum is the most common Agile framework.

Benefits

• Quicker delivery leading to better customer satisfaction

• Automation saving time and promoting innovation

• Breaking down silos and communication barriers

• Technological innovation leading to digital transformation

• Increased productivity of the organization

• Improved customer experience and satisfaction

• Smooth functioning of the organization

• Lowered cost of production and maintenance

Steps

1. Plan: Think of what you want to make, who will make it, and what you need to make it. For example, you want to make a website for a bookstore. You need a team of developers, designers, testers, and IT people. You also need a budget, a timeline, and a list of features.

2. Develop: Write the code for the website using good practices and tools. Work with the IT people to make sure the code can run well on different servers. For example, you use GitHub to store and share your code, Visual Studio Code to write and edit your code, and Azure DevOps to build and test your code.

3. Test: Check the code for errors and bugs before you release it. Use tools to automate testing and get feedback on how well the code works. For example, you use Selenium to test the website’s functionality, SonarQube to check the code quality, and Azure DevOps to run the tests and report the results.

4. Release: Send the code to the servers where the website will run. Use tools to automate the release process and make sure the code works on different environments. For example, you use Ansible to configure the servers, Docker to package the code, and Azure DevOps to deploy the code.

5. Monitor: Watch how the website performs after you release it. Use tools to collect data on how fast, reliable, and secure the website is. For example, you use Prometheus to measure the website’s performance, Grafana to visualize the data, and Azure DevOps to alert you if something goes wrong.

6. Feedback: Listen to what the users and customers say about the website. Use tools to gather feedback on how they like the website’s features, design, and usability. For example, you use Google Analytics to track how users interact with the website, SurveyMonkey to ask them questions, and Azure DevOps to analyze their responses.

7. Optimize: Use the data from monitoring and feedback to improve the website. Make changes to the code based on what the users and customers want and need. For example, you use A/B testing to compare different versions of the website, Google Optimize to optimize the website’s layout, and Azure DevOps to update the code.

8. Repeat: Go back to step 1 and start planning for the next cycle of making software faster and better.

Challenges & How to Overcome

• Changing the culture

  • Dev ops needs a new way of working together and learning from each other.

  • To solve this, create a positive and transparent culture that values feedback, learning, and innovation.

• Switching from legacy infrastructure to microservices

  • Dev ops needs modern and flexible architectures that can support faster and more frequent deployments.

  • To solve this, use configuration management, automation, and continuous integration and delivery tools to migrate to microservices gradually and safely.

• Adopting new tools and integrating them

  • Dev ops needs various tools for development, testing, deployment, monitoring, and feedback. These tools need to be compatible with each other and with the existing infrastructure. They also need to meet security and compliance requirements.

  • To solve this, agree on a common set of tools that can support the dev ops process flow. Train your teams on how to use these tools effectively.

• Managing multiple environments

  • Dev ops needs multiple environments for different stages of the software lifecycle. These environments need to be consistent, reliable, and secure.

  • To solve this, use automation tools that can provision, configure, orchestrate, and deploy software across different environments. Monitor these environments for any issues or anomalies.

• Balancing automation with people skills

  • Dev ops relies on automation tools to speed up and optimize processes. However, automation alone is not enough to ensure quality and reliability. Dev ops also requires people skills such as communication, collaboration, problem-solving, and creativity.

  • To solve this, invest in developing your teams’ soft skills as well as their hard skills. Encourage a culture of learning and experimentation.

Learn More - Click here

Extreme programming (XP) is a way of making software that helps the team work better and make the customer happier. It means making small changes often, instead of big changes once in a while. It also means checking with the customer often, and making sure the software works well and is easy to change.

Benefits

• It makes it easier to change the software when the customer wants something different.

• It helps the team and the customer talk and works together better by doing things like coding in pairs, looking at each other’s code, and giving feedback often.

• It makes the software better and less buggy by doing things like writing tests before code, fixing problems quickly, and improving the code often.

• It makes the software simpler and faster by doing only what is needed and avoiding extra features.

• It makes the customer happier and more trusting by giving them working software often and letting them be part of the process.

Extreme programming is good for projects that change a lot, have a short time limit, have a small team that works together in one place and have tools that can test the software automatically. But it may not be good for projects that have a complicated or fixed structure, have a big team that works in different places, or have a customer that is not involved much.

Steps

Extreme programming has five main steps that are done over and over for each part of the software. They are:

• Planning: The team and the customer decide what things to make next, based on how important and hard they are. The things are written as stories on cards and guessed by the team.

• Managing: The project manager helps the team do their best by giving them what they need, like tools and advice. The project manager also checks how well and fast the project is going using numbers and feedback.

• Designing: The team starts with the easiest way to make something and makes it better as they go. The way should be easy to change and check, and avoid extra stuff or problems.

• Coding: The team writes the instructions for the stories, following some rules and ways to write. The team also works in pairs, looks at each other’s code, fixes and improves the code, and makes sure the code works together.

• Testing: The team writes and runs checks for the code, using some methods and tools that do it automatically. The team also checks with the customer if the code does what they want.

These steps are done in short times of one to four weeks, called cycles. At the end of each cycle, the team gives working software to the customer and gets feedback for making it better.

Rules and ways to write a code

• Coding standards: Tips on how to write code that is easy to see, follow, and understand. They include things like how to give names to things, how to arrange and space the code, and how to explain the code with words.

• Pair programming: Way of coding where two people work together on the same code at the same time. One person writes the code while the other watches and checks it. They change roles often and share thoughts and feedback.

• Continuous integration: Way of coding where the code is joined and checked often, usually many times a day, which helps to find and fix mistakes quickly and avoid problems or bugs in the code.

• Collective code ownership: Way of coding where the code is shared by the whole team, not by individual people. This means that any person can change any part of the code if they need to. This also means that people have to follow the coding standards and write good-quality code.