Agile Methodology
As per, https://www.atlassian.com/agile, The Agile methodology is a project management approach that involves breaking the project into phases and emphasizes continuous collaboration and improvement. Teams follow a cycle of planning, executing, and evaluating.
Whereas the traditional "waterfall" approach has one discipline contribute to the project, then "throw it over the wall" to the next contributor, agile calls for collaborative cross-functional teams. Open communication, collaboration, adaptation, and trust amongst team members are at the heart of agile. Although the project lead or product owner typically prioritizes the work to be delivered, the team takes the lead on deciding how the work will get done, self-organizing around granular tasks and assignments.
Agile isn't defined by a set of ceremonies or specific development techniques. Rather, agile is a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement.
The original Agile Manifesto didn't prescribe two-week iterations or an ideal team size. It simply laid out a set of core values that put people first. The way you and your team live those values today – whether you do scrum by the book, or blend elements of kanban and XP – is entirely up to you.
Teams choose agile so they can respond to changes in the marketplace or feedback from customers quickly without derailing a year's worth of plans. "Just enough" planning and shipping in small, frequent increments lets your team gather feedback on each change and integrate it into future plans at minimal cost.
But it's not just a numbers game—first and foremost, it's about people. As described by the Agile Manifesto, authentic human interactions are more important than rigid processes. Collaborating with customers and teammates is more important than predefined arrangements. And delivering a working solution to the customer's problem is more important than hyper-detailed documentation.
An agile team unites under a shared vision, then brings it to life the way they know is best. Each team sets their own standards for quality, usability, and completeness. Their "definition of done" then informs how fast they'll churn the work out. Although it can be scary at first, company leaders find that when they put their trust in an agile team, that team feels a greater sense of ownership and rises to meet (or exceed) management's expectations.
The publication of the Agile Manifesto in 2001 marks the birth of agile as a methodology. Since then, many agile frameworks have emerged such as scrum, kanban, lean, and Extreme Programming (XP). Each embodies the core principles of frequent iteration, continuous learning, and high quality in its own way. Scrum and XP are favored by software development teams, while kanban is a darling among service-oriented teams like IT or human resources.
Today, many agile teams combine practices from a few different frameworks, spiced up with practices unique to the team. Some teams adopt some agile rituals (like regular stand-ups, retros, backlogs, etc.), while others created a new agile practice (agile marketing teams who adhere to the Agile Marketing Manifesto).
The agile teams of tomorrow will value their own effectiveness over adherence to doctrine. Openness, trust, and autonomy are emerging as the cultural currency for companies who want to attract the best people and get the most out of them. Such companies are already proving that practices can vary across teams, as long as they're guided by the right principles.
As per, https://www.atlassian.com/agile/scrum, Scrum is an agile project management framework that helps teams structure and manage their work through a set of values, principles, and practices. Much like a rugby team (where it gets its name) training for the big game, scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve.
While the scrum I’m talking about is most frequently used by software development teams, its principles and lessons can be applied to all kinds of teamwork. This is one of the reasons scrum is so popular. Often thought of as an agile project management framework, scrum describes a set of meetings, tools, and roles that work in concert to help teams structure and manage their work.
In this article, we’ll discuss how a traditional scrum framework is comprised with the help of the Scrum Guide
People often think scrum and agile are the same thing because scrum is centered around continuous improvement, which is a core principle of agile. However, scrum is a framework for getting work done, whereas agile is a philosophy. The agile philosophy centers around continuous incremental improvement through small and frequent releases. You can’t really “go agile”, as it takes dedication from the whole team to change the way they think about delivering value to your customers. But you can use a framework like scrum to help you start thinking that way and to practice building agile principles into your everyday communication and work.
The difference between agile and the definition of scrum can be found in the Scrum guide and the Agile manifesto. The Agile manifesto outlines four values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
The definition of scrum is based on empiricism and lean thinking. Empiricism says that knowledge comes from experience and that decisions are made based on what is observed. Lean thinking reduces waste and focuses on essentials. The scrum framework is heuristic; it’s based on continuous learning and adjustment to fluctuating factors. It acknowledges that the team doesn’t know everything at the start of a project and will evolve through experience. Scrum is structured to help teams naturally adapt to changing conditions and user requirements, with re-prioritization built into the process and short release cycles so your team can constantly learn and improve.
While scrum is structured, it is not entirely rigid. Its execution can be tailored to the needs of any organization. There are many theories about how exactly scrum teams must work in order to be successful. However, after more than a decade of helping agile teams get work done at Atlassian, we’ve learned that clear communication, transparency, and a dedication to continuous improvement should always remain at the center of whatever framework you choose. And the rest is up to you.
The scrum framework outlines a set of values, principles, and practices that scrum teams follow to deliver a product or service. It details the members of a scrum team and their accountabilities, “artifacts” that define the product and work to create the product, and scrum ceremonies that guide the scrum team through work.
A scrum team is a small and nimble team dedicated to delivering committed product increments. A scrum team’s size is typically small, at around 10 people, but it’s large enough to complete a substantial amount of work within a sprint. A scrum team needs three specific roles: product owner, scrum master, and the development team. And because scrum teams are cross-functional, the development team includes testers, designers, UX specialists, and ops engineers in addition to developers.
Product owners are the champions for their product. They are focused on understanding business, customer, and market requirements, then prioritizing the work to be done by the engineering team accordingly. Effective product owners:
Build and manage the product backlog.
Closely partner with the business and the team to ensure everyone understands the work items in the product backlog.
Give the team clear guidance on which features to deliver next.
Decide when to ship the product with a predisposition towards more frequent delivery.
The product owner is not always the product manager. Product owners focus on ensuring the development team delivers the most value to the business. Also, it's important that the product owner be an individual. No development team wants mixed guidance from multiple product owners.
Scrum masters are the champions of scrum within their teams. They coach teams, product owners, and the business on the scrum process, and look for ways to fine-tune their practice of it.
An effective scrum master deeply understands the work being done by the team and can help the team optimize their transparency and delivery flow. As the facilitator-in-chief, he/she schedules the needed resources (both human and logistical) for sprint planning, stand-up, sprint review, and the sprint retrospective.
Scrum teams get s*%& done. They are the champions for sustainable development practices. The most effective scrum teams are tight-knit, co-located, and usually five to seven members. One way to work out the team size is to use the famous ‘two pizza rule’ coined by Jeff Bezos, the CEO of Amazon (the team should be small enough to share two pizzas).
Team members have differing skill sets, and cross-train each other so no one person becomes a bottleneck in the delivery of work. Strong scrum teams are self-organizing and approach their projects with a clear ‘we’ attitude. All members of the team help one another to ensure a successful sprint completion.
The scrum team drives the plan for each sprint. They forecast how much work they believe they can complete over the iteration using their historical velocity as a guide. Keeping the iteration length fixed gives the development team important feedback on their estimation and delivery process, which in turn makes their forecasts increasingly accurate over time.
Scrum artifacts are important information used by the scrum team that helps define the product and what work to be done to create the product. There are three artifacts in scrum: product backlog, a sprint backlog, and an increment with your definition of “done”. They are the three constants a scrum team should reflect on during sprints and over time.
Product Backlog is the primary list of work that needs to get done and maintained by the product owner or product manager. This is a dynamic list of features, requirements, enhancements, and fixes that acts as the input for the sprint backlog. It is, essentially, the team’s “To Do” list. The product backlog is constantly revisited, re-prioritized and maintained by the Product Owner because, as we learn more or as the market changes, items may no longer be relevant or problems may get solved in other ways.
Sprint Backlog is the list of items, user stories, or bug fixes, selected by the development team for implementation in the current sprint cycle. Before each sprint, in the sprint planning meeting (which we’ll discuss later in the article) the team chooses which items it will work on for the sprint from the product backlog. A sprint backlog may be flexible and can evolve during a sprint. However, the fundamental sprint goal – what the team wants to achieve from the current sprint – cannot be compromised.
Increment (or Sprint Goal) is the usable end-product from a sprint. At Atlassian, we usually demonstrate the “increment” during the end-of-sprint demo, where the team shows what was completed in the sprint. You may not hear the word “increment” out in the world, as it’s often referred to as the team’s definition of “Done”, a milestone, the sprint goal, or even a full version or a shipped epic. It just depends on how your teams defines “Done” and how you define your sprint goals. For example, some teams choose to release something to their customers at the end of every sprint. So their definition of ‘done’ would be ‘shipped’. However, this may not be realistic of other types of teams. Say you work on a server-based product that can only ship to your customers every quarter. You may still choose to work in 2-week sprints, but your definition of ‘done’ may be finishing part of a larger version that you plan to ship together. But of course, the longer it takes to release software, the higher the risk that software will miss the mark.
As you can tell, there are lots of variations, even within artifacts, that your team can choose to define. That’s why it’s important to be remain open to evolving how you maintain even your artifacts. Perhaps your definition of ‘done’ provides undo stress on your team, and you need to go back and pick a new definition.
The scrum framework includes scrum practices, ceremonies, and meetings that scrum teams perform on a regular basis. The agile ceremonies are where we see the most variations for teams. For example, some teams find doing all of these ceremonies cumbersome and repetitive, while others use them as a necessary check-in. Our advice is to start out using all of the ceremonies for two sprints and see how it feels. You can then perform a quick retro and see where you might need to adjust.
Below is a list of all the key ceremonies a scrum team might partake in:
Organize the backlog: Sometimes known as backlog grooming, this event is the responsibility of the product owner. The product owner’s main jobs are to drive the product towards its product vision and have a constant pulse on the market and the customer. Therefore, he/she maintains this list using feedback from users and the development team to help prioritize and keep the list clean and ready to be worked on at any given time. You can read more about maintaining a healthy backlog here.
Sprint planning: The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific user stories are then added to the sprint from the product backlog. These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.
At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered.
Sprint: A sprint is the actual time period when the scrum team works together to finish an increment. Two weeks is a pretty typical length for a sprint, though some teams find a week to be easier to scope or a month to be easier to deliver a valuable increment. Dave West, from Scrum.org advises that the more complex the work and the more unknowns, the shorter the sprint should be. But it’s really up to your team, and you shouldn’t be afraid to change it if it’s not working! During this period, the scope can be re-negotiated between the product owner and the development team if necessary. This forms the crux of the empirical nature of scrum.
All the events — from planning to retrospective — happen during the sprint. Once a certain time interval for a sprint is established, it has to remain consistent throughout the development period. This helps the team learn from past experiences and apply that insight to future sprints.
Daily scrum or stand up: This is a daily super-short meeting that happens at the same time (usually mornings) and a place to keep it simple. Many teams try to complete the meeting in 15 minutes, but that’s just a guideline. This meeting is also called a ‘daily stand-up’ emphasizing that it needs to be a quick one. The goal of the daily scrum is for everyone on the team to be on the same page, aligned with the sprint goal, and to get a plan out for the next 24 hours.
The stand up is the time to voice any concerns you have with meeting the sprint goal or any blockers.
A common way to conduct a stand up is for every team member to answer three questions in the context of achieving the sprint goal:
• What did I do yesterday?
• What do I plan to do today?
• Are there any obstacles?
However, we’ve seen the meeting quickly turn into people reading from their calendars from yesterday and for the next day. The theory behind the stand up is that it keeps distracting chatter to a daily meeting, so the team can focus on the work for the rest of the day. So if it turns into a daily calendar read-out, don’t be afraid to change it up and get creative.
Sprint review: At the end of the sprint, the team gets together for an informal session to view a demo of, or inspect, the increment. The development team showcases the backlog items that are now ‘Done’ to stakeholders and teammates for feedback. The product owner can decide whether or not to release the increment, although in most cases the increment is released.
This review meeting is also when the product owner reworks the product backlog based on the current sprint, which can feed into the next sprint planning session. For a one-month sprint, consider time-boxing your sprint review to a maximum of four hours.
Sprint retrospective: The retrospective is where the team comes together to document and discuss what worked and what didn’t work in a sprint, a project, people or relationships, tools, or even for certain ceremonies. The idea is to create a place where the team can focus on what went well and what needs to be improved for the next time, and less about what went wrong.
In 2016, five scrum values were added to the Scrum Guide. These values provide direction toward work, actions, and the behavior of the scrum team. They are considered essential to a scrum team’s success.
Because scrum teams are small and agile, each team member plays a significant role in the team’s success. Therefore, each team member should agree to commit to performing tasks they can complete and not overcommit. There should be frequent communication regarding work progress, often in stand-ups.
Courage for a scrum team is simply the bravery to question the status quo or anything that hampers its ability to succeed. Scrum team members should have the courage, and feel safe enough, to try new things. A scrum team should have the courage and feel safe to be transparent about roadblocks, project progress, delays, and so on.
At the heart of the workflow for scrum teams is the sprint, a focused and specified period of time where the team completes a set amount of work. The sprint provides structure but also focus to complete the planned amount of work.
The daily stand-up fosters an openness that allows teams to talk openly about work in progress and blockers. At Atlassian we often have our scrum teams address these questions:
What did I work on yesterday?
What am I working on today?
What issues are blocking me?
This helps to highlight progress and identify blockers. It also helps to strengthen the team when everyone shares progress.
The strength of an agile team lies in its collaboration and recognizing that each team member contributes to work in a sprint. They celebrate each other’s accomplishments and are respectful to one another, the product owner, stakeholders, and the scrum master.
Scrum is such a popular agile framework that scrum and agile are often misunderstood to be the same thing. But there are other frameworks, like kanban, which is a popular alternative. Some companies even choose to follow a hybrid model of scrum and kanban, which has acquired the name of "Scrumban" or "Kanplan," which is Kanban with a backlog.
Both scrum and kanban use visual methods such as the scrum board or kanban board to track the progress of work. Both emphasize efficiency and splitting complex tasks into smaller chunks of manageable work, but their approaches towards that goal are different.
Scrum focuses on smaller, fixed-length iterations. Once the time period for a sprint is finalized, the stories or product backlog entries that can be implemented during this sprint cycle are then determined. In kanban, however, the number of tasks or the work in progress (WIP limit) to be implemented in the current cycle is fixed at first. The time taken to implement these features is then calculated backward.
Kanban is not as structured as scrum. Other than the WIP limit, it is fairly open to interpretation. Scrum, however, has several categorical concepts enforced as part of its implementation such as sprint review, retrospective, daily scrum, etc. It also insists on cross-functionality, which is the ability of a scrum team to not depend on external members to achieve their goals. Putting together a cross-functional team is not straightforward. In that sense, kanban is easier to adapt whereas scrum can be considered as a fundamental shift in the thought process and functioning of a development team.
The scrum framework itself is simple. The rules, artifacts, events, and roles are easy to understand. Its semi-prescriptive approach actually helps remove the ambiguities in the development process, while giving sufficient space for companies to introduce their individual flavor to it.
The organization of complex tasks into manageable user stories makes it ideal for difficult projects. Also, the clear demarcation of roles and planned events ensure that there is transparency and collective ownership throughout the development cycle. Quick releases keep the team motivated and the users happy as they can see progress in a short amount of time.
However, scrum could take time to fully understand, especially if the development team is acclimatized to a typical waterfall model. The concepts of smaller iterations, daily scrum meetings, sprint reviews, and identifying a scrum master could be a challenging cultural shift for a new team.
But, the long-term benefits far outweigh the initial learning curve. Scrum’s success in developing complex hardware and software products across diverse industries and verticals makes it a compelling framework to adopt for your organization.
To learn scrum with Jira Software, check out this tutorial.
As per https://www.atlassian.com/devops
DevOps is a set of practices, tools, and a cultural philosophy that automate and integrate the processes between software development and IT teams. It emphasizes team empowerment, cross-team communication and collaboration, and technology automation.
The DevOps movement began around 2007 when the software development and IT operations communities raised concerns about the traditional software development model, where developers who wrote code worked apart from operations who deployed and supported the code. The term DevOps, a combination of the words development and operations, reflects the process of integrating these disciplines into one, continuous process.
A DevOps team includes developers and IT operations working collaboratively throughout the product lifecycle, in order to increase the speed and quality of software deployment. It’s a new way of working, a cultural shift, that has significant implications for teams and the organizations they work for.
Under a DevOps model, development and operations teams are no longer “siloed.” Sometimes, these two teams merge into a single team where the engineers work across the entire application lifecycle — from development and test to deployment and operations — and have a range of multidisciplinary skills.
DevOps teams use tools to automate and accelerate processes, which helps to increase reliability. A DevOps toolchain helps teams tackle important DevOps fundamentals including continuous integration, continuous delivery, automation, and collaboration.
DevOps values are sometimes applied to teams other than development. When security teams adopt a DevOps approach, security is an active and integrated part of the development process. This is called DevSecOps.
Because of the continuous nature of DevOps, practitioners use the infinity loop to show how the phases of the DevOps lifecycle relate to each other. Despite appearing to flow sequentially, the loop symbolizes the need for constant collaboration and iterative improvement throughout the entire lifecycle.
The DevOps lifecycle consists of eight phases representing the processes, capabilities, and tools needed for development (on the left side of the loop) and operations (on the right side of the loop). Throughout each phase, teams collaborate and communicate to maintain alignment, velocity, and quality.
DevOps tools address the key phases of the DevOps lifecycle. They empower DevOps practices by helping to improve collaboration, reduce context-switching, introduce automation, and enable observability and monitoring.
DevOps toolchains usually follow two approaches: an all-in-one or open toolchain. An all-in-one toolchain offers a complete solution that usually doesn’t integrate with other third-party tools, while an open toolchain allows for customization with different tools. There are pros and cons to both approaches.
An example of an open DevOps toolchain is Atlassian’s Open DevOps solution, which includes Jira as a foundation and integrates with leading vendors and marketplace apps.
In Atlassian’s 2020 DevOps Trends survey, 99 percent of respondents said that DevOps had a positive impact on their organization. The benefits of DevOps include faster and easier releases, team efficiency, increased security, higher quality products, and consequently happier teams and customers.
The foundation of DevOps is a culture of collaboration between developers and operations teams, who share responsibilities and combine work. This makes teams more efficient and saves time related to work handoffs and creating code that is designed for the environment where it runs.
By increasing the frequency and velocity of releases, DevOps teams improve products rapidly. A competitive advantage can be gained by quickly releasing new features and repairing bugs.
Practices like continuous integration and continuous delivery ensure changes are functional and safe, which improves the quality of a software product. Monitoring helps teams keep informed of performance in real-time.
By integrating security into a continuous integration, continuous delivery, and continuous deployment pipeline, DevSecOps is an active, integrated part of the development process. Security is built into the product by integrating active security audits and security testing into agile development and DevOps workflows.
Habits are hard to break. Teams entrenched in siloed ways of working can struggle with, or even be resistant to, overhauling team structures to embrace DevOps practices. Some teams may mistakenly believe new tools are sufficient to adopt DevOps. Yet, DevOps is a combination of people, tools, and culture. Everyone on a DevOps team must understand the entire value stream — from ideation, to development, to the end user experience. It requires breaking down silos in order to collaborate throughout the product lifecycle.
Moving from a legacy infrastructure to using Infrastructure as Code (IaC) and microservices can offer faster development and innovation, but the increased operational workload can be challenging. It’s best to build out a strong foundation of automation, configuration management, and continuous delivery practices to help ease the load.
An over-reliance on tools can detract teams from the necessary foundations of DevOps: the team and organization structure. Once a structure is established, the processes and team should come next and the tools should follow.
Adopting DevOps first requires a commitment to evaluating and possibly changing or removing any teams, tools, or processes your organization currently uses. It means building the necessary infrastructure to give teams the autonomy to build, deploy, and manage their products without having to rely too heavily on external teams.
A DevOps culture is where teams embrace new ways of working that involve greater collaboration and communication. It’s an alignment of people, processes, and tools toward a more unified customer focus. Multidisciplinary teams take accountability for the entire lifecycle of a product.
Organizations that do DevOps well are places where experimentation and some amount of risk-taking are encouraged. Where thinking outside the box is the norm, and failure is understood to be a natural part of learning and improving.
Agile methodologies are immensely popular in the software industry since they empower teams to be inherently flexible, well-organized, and capable of responding to change. DevOps is a cultural shift that fosters collaboration between those who build and maintain software. When used together, agile and DevOps result in high efficiency and reliability.
Continuous integration is the practice of automating the integration of code changes into a software project. It allows developers to frequently merge code changes into a central repository where builds and tests are executed. This helps DevOps teams address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.
Learn about continuous integration
Continuous delivery expands upon continuous integration by automatically deploying code changes to a testing/production environment. It follows a continuous delivery pipeline, where automated builds, tests, and deployments are orchestrated as one release workflow.
Learn about continuous delivery
It is vital for every member of the organization to have access to the data they need to do their job as effectively and quickly as possible. Team members need to be alerted of failures in the deployment pipeline — whether systemic or due to failed tests — and receive timely updates on the health and performance of applications running in production. Metrics, logs, traces, monitoring, and alerts are all essential sources of feedback teams need to inform their work.
Automation is one of the most important DevOps practices because it enables teams to move much more quickly through the process of developing and deploying high-quality software. With automation the simple act of pushing code changes to a source code repository can trigger a build, test, and deployment process that significantly reduces the time these steps take.
Learn about DevOps automation best practices
Whether your organization has an on-premise data center or is completely in the cloud, having the ability to quickly and consistently provision, configure, and manage infrastructure is key to successful DevOps adoption. Infrastructure as Code (IaC) goes beyond simply scripting infrastructure configuration to treating your infrastructure definitions as actual code: using source control, code reviews, tests, etc.
Learn about Infrastructure as Code
Microservices is an architectural technique where an application is built as a collection of smaller services that can be deployed and operated independently from each other. Each service has its own processes and communicates with other services through an interface. This separation of concerns and decoupled independent function allows for DevOps practices like continuous delivery and continuous integration.
DevOps teams monitor the entire development lifecycle — from planning, development, integration and testing, deployment, and operations. This allows teams to respond to any degradation in the customer experience, quickly and automatically. More importantly, it allows teams to “shift left” to earlier stages in development and minimize broken production changes.
Email ID: easycoachingtraining@gmail.com