All About Agile

What is Agile?

Agile methodologies were established in 2001 and are used throughout the industry as a way of strategically managing software development. Agile is a set of methods and practices that facilitate iterative, flexible, and dynamic development.

Agile was developed to deliver software faster which allows the team to react to the market more effectively and one of the defining features is that this faster pace of development allows the team to more effectively leverage their base of users.

If you are a new developer with an understanding of Object Oriented programming, Agile is sort of like modular task management. When you hear about self-organizing cross-functional teams, those are words associated with Agile. Agile organizes the work being done similar to a functional programming mindset where concerns are separated and flexibility is ensured. If you look at Agile like that a lot of these concepts are going to seem familiar.

"Before you dive into the content of this blog I want you to mentally prepare yourself for the concepts to be related as a web of ideas. There isn't always a clear hierarchy of concepts at play, though I have tried to organize the content in that way whenever possible and also aimed to minimize repetition. Depending on the implementation of Agile the concepts have a changing relationship to one another so keep an open mind as you make note of each element and you can put them together at the end!" -Elliot

This blog is a comprehensive beginner's guide to Agile I created by distilling topics covered in the Agile Scrum Course in 4 Hours offered by Simplilearn on Youtube and supplementing with my own independent research. This blog is also available on my GitHub.

Making Changes Quickly

Nowadays companies need to compete in a rapidly changing marketplace. We have to consider reacting to and taking advantage of an ability to adapt. We need to be ready to make changes and consider...

• Cost
• Effort
• Scope
• Time

Waterfall

Waterfall Methodology is a linear approach to development which we can briefly take a look at to put Agile methods into context.

Aspects of Waterfall Methodology

• Woks linearly.
• Works well for predictable development.
• Small companies.
• Longer development cycles.
• Make the documentation, begin development, work step by step.
• More wait time.
• Cumbersome, making changes is more involved.
• Testing stages are delayed.

Agile

An iterative approach to product delivery employed at all levels throughout an enterprise.

Aspects of Agile Methodology

• Strong relationship with user-base.
• Smaller teams working on bite-sized objectives.
• Modular work ensures quality.
• Easier to make changes.
• Easier to respond to the market.
• Goals are flexible.
• Deliver to the customer faster.
• Unit tests are easier.
• Predefined Schedule
• Predictable Costs
• High Visibility and High Transparency

Client Side

Agile emphasizes maintaining working products over creating comprehensive documentation. This makes creating documentation easier in the long run because it is delayed until the product is up and running. We make better use of customer's feedback and have a collaborative relationship with them. This means having more frequent updates and deliveries.

There is greater transparency when users observe changes incrementally. This allows them to give feedback more effectively. Clients can illuminate what features are a priority, those can be developed first, which raises the value of the product.

Developer Side

Agile gives teams more responsibility, ownership, freedom, autonomy, and trust. This means that soft skills are more important and face-to-face communication is prioritized. Teams can work simultaneously on different objectives-- different working pieces. This modular approach relies on simplicity in design.

We can also more easily predict when things will be completed and how much things will cost.

Agile Methodologies Overview

Scrum

A framework for implementing ideas, reflecting, and making adjustments. Allows for incorporating practices from other frameworks. Works when cross-functional teams are coordinating multiple "sprints" or 2-4 week chunks of development.

Scrum incorporates scrum boards and a specific iterative working pattern which shares similarities with Kanban. Kanban refers to the iterations as leaps as opposed to sprints. Scrum may be better for longer-running projects where there is a greater emphasis on the interative nature of the development process.

Kanban

Kanban is a visual workflow for organizing teams and prioritizing objectives transparently and efficiently. Tasks flow from left to right through to-do, ongoing, and done categories. Kanban emphasizes limiting the amount of tasks being done, the time being spent on those tasks, and enhances visibility across the teams. It is highly flexible and may work best for shorter timelines.

Kanban is a simple working pattern that is good for adapting to a changing environment. In Kanban changes can be made at any time, whereas scrum provides a specific pattern where changes are made during the retrospective and not during the iterations.

Kanban comes from a Japanese word meaning 'signboard' and was first developed in Japan for use in manufacturing, and was later adopted and popularized by project development teams around the world.

Extreme Programming (XP)

Works well when there are changing requirements for the software. Minimizes risk due to new technologies.

Lean

Tools and principles that can be used to ensure the work being done is the work that will provide the maximum value. Eliminating waste by reducing waiting time and extraneous efforts.

Crystal

Approach to development through the lens of people and their interactions. Allows teams to optimize their workflow based on the specific requirements of the project. Focuses on communication, integration, and user involvement.

Scrum

There may be a problem with our product and the consumer is not happy. We need to react now. We are going to make the changes immediately even if we are midway through another batch of work and even if the documentation does not reflect the new changes.

History of Scrum

1986 - Scrum is first introduced in Japan.

1995 - First early versions of Agile appear.

2001 - Agile Alliance & first formal appearance of Agile methodologies with scrum.

2002 - Scrum Alliance & certifications added.

2006 - Scrum Inc. offers certification courses privately.

2009 - Scrum.org offers those certification courses (online?).

2010 - First Scrum Guide is published and freely available.

The methodology has changed throughout its history and Agile has become more important over time.

What is Scrum?

A framework that enables teams to work together and learn from their specific experiences.

Scrum organizes around producing deliverables efficiently and taking stock based on iterative loops with collaborative checkpoints throughout. Projects are divided into smaller units called sprints. Daily Scrum Meetings occur (sometimes called stand-ups) where the sprint backlog and user feedback are reviewed.

What did we do yesterday? What will we do today? Everyone is sharing their updates so that teams are empowered to be self-organizing and all members understand what is going on with each other member. Each member is able to adjust their own strategy based on their counterparts.

Scrum Roles

• Product Owner
• Scrum Master
• Scrum Team

Each role has its own objectives and focus.

The Product Owner is focused on determining what the features are, organizing a list of priorities, and deciding what needs to be accomplished during each sprint. Adding user stories into the backlog.

The Scrum Master helps the team apply scrum, removes barriers for the team, and ensures the team is using agile practices and not being interfered with.

The Scrum Team work together to meet the requirements outlined by the product owner and stakeholders.

Scrum Artifacts

Sort of our internal documents for organizing our objectives. "Artifact" is in this sense an effective word for what the following are.

Product Backlog

• Full list of deliverables.
• New features and changes to be made.
• Bug Fixes
• Changes to Infrastructure
• Updated as the project develops. Dynamic.

Sprint Backlog

• Subset of Product Backlog
• Deliverables for this sprint.
• Negotiated between the team and product owner.
• Deciding on timelines

Product Increment

• What is already delivered + what we gained in this sprint.
• More or less what was once in the product backlog but has now been completed is in the product increment.
• A product increment should leave the software in a usable state. (release but not necessarily deployment)

Scrum artifacts used in a framework may also include the Product Vision, Release Plan, Burndown Charts, and Impedement Lists.

Scrum Workflow

This is like the workflow, timeline, loop, or path we follow when using Scrum.

This is how we incrementally move through the development cycle. It's like a fractal by which I mean the smaller scale processes resemble the larger scale processes. We take the idea of moving a product from start to finish and do it many times within the development cycle.

1) Product Backlog - Orient ourselves with respect to the goals of the project and demands of the stakeholders.
2) Sprint Planning - Determine what tasks from the Product Backlog to put on the Sprint Backlog.
3) Sprint Backlog - What actually made it into our goals for this sprint from the planning stage.
4) Daily Scrums - What do we aim to achieve in these 24 hours? What did we accomplish in the last 24 hours? This should take 10 minutes or so (sometimes called "time-boxed"). The Product Owner (PO) may sit in but does not play an active role in these check-ins.
5) Sprint Review - Once the sprint is complete we take stock of what we have accomplished. Everyone, the product owner, scrum master, and team, altogether.

Then the product owner speaks with the stakeholders and is able to make changes to the Product Backlog for moving forward.

6) Sprint Retrospective - What went well? What went wrong? What can we learn and what mistakes can we avoid before moving to the next sprint. This step is documented.

Once we have done all of this we have a Product Increment.

We can use a Scrum Board to visualize everything on the Sprint Backlog, showing all items during the daily scrum, and made available to all members of the team.

Typically this board is organized into "to do", "started", and "finished" sections (like a Kanban board).

We look at the Scrum Board during our daily Scrum Meetings, and there is a strong emphasis on communicating to team members any areas we may be stuck-- however the daily meeting is not a setting for resolving these issues, that can be done afterwards in smaller groups or pairs.

We make a new Scrum Board for each sprint.

It is advisable to use a scrum approach anytime we are moving quickly and making a lot of changes or involving the consumer's feedback regularly.

Review - Iterative Workflow (Scrum)

Agile Project Management is a flexible approach to building a project when it utilizes Scrum.

• Project Planning - Breaking the project into tasks, sprints, and estimating timeframes.
• Roadmap Creation - How the project should evolve over time until it has all the features required.
• Release Planning - Releases after each sprint, with later sprints being shorter.
• Sprint Planning - deciding what to do in the current sprint.
• Daily Meetings - Making adjustments as we go during sprints.
• Sprint Meeting & Retrospective - One meeting with stakeholders to share the release, and one to talk about what went well and what did not.

User Stories

What are User Stories?

User stories are a way for us to better understand what we need to make. Let's say we want to create a new product or add a new feature to our product. User stories are written from the perspective of end users and allow us to ensure that our product creates the most value by starting in the moment where that value expresses itself and working backwards.

User stories also force us to consider who is going to be using the software. This could mean internal end-users or external ones-- colleagues or customers-- or partner organizations. It's about putting ourselves in the user's shoes.

User stories cluster to form epics and initiatives. Epics are large groups of connected user stories and Initiatives are sets of Epics.

The approach also allows the team to look at the desired outcome independent of the reality of creating the software or product. It produces transparency and reduces risks.

Including User Stories on scrum boards allows us to pull that card as a way of prioritizing some work that needs to be done in a way that feels intuitive.

Incorporating User Stories into an Agile workflow increases visibility (which in the context of agile can sort of mean active participation and relationship-building within an organization) because it is an abstract practice that requires communication and some involvement of one's own personality.

What are the Tenants of good User Stories?

I'm not hugely into acronyms or pneumonics but we're going to use one it's called INVEST and here it is.

I - Independent and can be delivered on separately.

N - Negotiable and open for discussion.

V - Valuable-- "Why is the user excited?" this is maybe the most important one.

E - Estimatable-- meaning it is clear what would be required for the story to be true. "I use it everyday and it has made my accounting take half the time!" is not estimatable, but "I can automate my receipt entry by uploading a batch of images" is.

S - Small-- meaning we can complete it inside a single sprint, ideally in 3 to 4 days. We can break stories down into smaller ones if they are too big.

T - Testable-- we need to be able to check if the story is true at some time.

How do you write User Stories?

Template:

As a [role], I want to [action], so that [outcome].

Example:

"As a [producer], I want to [be able to find sounds similar to a selected sound programmatically], so that [when I have a snare drum that is almost working I can test out ones that are adjacent to that one until I find the correct sound]."

Lifecycle of User Stories

1. Users stories are first written on a card in a pending state. These are basic representations of the story that will lead to further discussion.
2. Prioritization happens and stories are taken from pending in the Product Backlog and put into sprints.
3. Then conversations happen between team members, users, product owners, etc. to make sure the stories make sense and are in line with the user's expectations. Previews of the stories are given to the user to get out ahead of their expectations.
4. Next, development happens and the features are implemented.
5. Finally, stories undergo confirmation to make sure the specific goals, boundaries, restrictions, and functionality are accepted by everyone including the stakeholders.
6. Once we finish a user story if we want to make changes or build on the story, we make a new story that goes into the product backlog.

User Story Maps

Stories are arranged horizontally based on prioritization and vertically based on the level of sophistication.

Meaning if we look at the above graphic, you can see that from any single user story beneath it we can see how the feature will be improved, to the right of it we can see new features, features that build on top of existing features, or will need to be implemented later in the process. Remember that all of these items are written from the perspective of what the user is actually doing. Not what the software is doing or what we need to do as a dev team.

Let's take note that user story maps are in general inherently organized according to the user's journey through the software. So for a web application, many projects might have a user story card at the top left reading "Log in to Account".

Overall user story maps help us to prioritize our work and break it into manageable pieces while maintaining a focus on the value delivered to the consumer. They also help the team remain unified and make constant improvements.

Agile at Scale

In this section we are going to talk about how Agile methods work in large organizations where there are many moving pieces that must remain in alignment.

Frameworks to Scale Agile

These frameworks provide guidelines, practices, and workflow patterns to help things work at scale. You can think of these as different flavors of Agile.

• Scaled Agile Framework
• Large Scale Scrum (LeSS) *FREE*
• Disciplined Agile (DAD)
• Scrum at Scale
• Nexus Scrum
• The Spotify Model (emphasizes culture)

Every company and organization will have its own internal practices and way of using the Agile methodologies.

Scaled Agile Framework (SAFe)

We'll soon dive into one of these practices, Scaled Agile Framework (SAFe). SAFe is designed for complex projects that involve several large teams working at different levels.

Core Values of SAFe

• Alignment - Geographically seperated teams & a changing marketplace.
• Built-In Quality - Ensure that every component, increment, and element meets the quality standards
• Transparency - Enable teams to rely on one another to act with integrity and allow for trust.
• Program Execution - An emphasis on working systems and business outcomes.

These are the conceptual ingredients in our introduction to SAFe.

Competencies of SAFe

Now, we will get specific about the structure, practices, and workflow patterns in a SAFe Agile framework.

These are things we can describe about how the entire organization is operating and how the development teams are operating in relation to the rest of the organization.

The competencies are as follows...

• Team & Technical Agility - Teams are high-performing and cross-functional, and solutions are formed collaboratively between technical teams and business members.
• Agile Product Delivery - The user is at the center of the strategy and teams are innovating and deploying continuously.
• Enterprise Solution Delivery - Using lean to build big systems aligned with the entire supply chain.
• Lean Portfolio Management - An executive strategy powered by decentralized lightweight governance optimizing operations with regard to the funding and strategy.
• Organizational Agility - A lean-agile mindset across the enterprise where teams understand what other teams are doing and opportunities and threats can be addressed quickly.
• Continuous Learning Culture - Everyone grows, learns together, creativity is emphasized, and everyone has responsibility for improvements
• Lean-Agile Leadership - Leadership models the desired behaviors and exhibit the mindset teams are expected to utilize.

Next, we will look at these enterprise competencies in depth.

Team & Technical Agility

Teams of 5-11 divide tasks into easy to manage time-boxed iterations to define, build, test, and deploy products.

Teams use scrum (and its roles) to deliver the product in increments. They have retrospectives along the way.

Agile Project Delivery

The large organization is made up of many teams, each led by a scrum master, which together form Agile Release Trains (ART) and consist of 50-125 people.

From there, each ART is also cross-functional with each other ART. In practice and throughout, Agile places a strong emphasis on individual members having a broad understanding of the business strategy and what is being accomplished in other areas of the organization.

Each ART uses time-boxed iterative agile delivery practices divided into Program Increments (PIs) the same way that Teams do.

At this moment in the blog you may think you are confused but may not actually be-- this is a good time to notice that everything is working like a fractal where the larger patterns resemble the smaller patterns.

The ARTs coordinate in PI Planning meetings and when an enterprise is working at this scale we have some new roles to consider.

• Release Train Engineer - Facilitates PI Planning process.
• Project Management - Provide the vision and backlog of tasks.
• Systems Architect - Provides architectural guidance.

These individuals use a program board to illustrate the dependencies between teams and plan across increments. After each increment all teams are gathered for a system demo which is followed by a retrospective called the Inspect and Adapt event.

The ART in this way establishes a continuous delivery pipeline in conjunction with DevOps practices. This allows for continuous exploration, learning, informed risk-taking, and value available on demand.

Enterprise Solution Delivery

Zooming out one level further, a Solution Train at the ESD level is made up of multiple ARTs.

There are new roles that function similarly at this level:

• Solution Train Engineer - Facilitates solution train events.
• Solution Management - Authorizes what needs to be built.
• Solutions Architect - Handles architecture across ARTs.

Lean Portfolio Management

Combines strategic themes with portfolio vision to enable solution development aligned with the enterprise's strategy. Ensures that defects are eliminated downstream and risk factors are eliminated. Ensures viability of and funding for value streams.

Organizational Agility

Enables portfolios with strategic agility. All areas of the enterprise from recruitment to procurement to development are able to respond with the same flexibility and speed that the project teams require.

As we keep introducing new products and services the management and operations need to remain educated about them. Operations must resolve issues to ensure the customer doesn't experience a drop in value.

Encouraging the growth of lean-thinking people and agile teams, making changes in the direction based on the scenario. Focusing on organizing and reorganizing an environment for the flow of value across the environment.

Continuous Learning Culture

This one is self-explanatory but it's important. We should be focused on continuous improvement, and can consider the enterprise to be a learning organization. This way we have the right culture in place to continue thriving.

We wanna move away from a way of thinking where we find the "right" way to do something and then celebrate the victory towards one where we are constantly making incremental changes with regard to a dynamic environment.

Lean-Agile Leadership

Ensuring that everyone is motivated by embodying, teaching, and exhibit, lean-agile mindsets, principles, and values across the organization. This ensures business agility.

SAFe Configurations

Configurations of a framework refer to different flavors and levels of comprehensiveness in that implementation.

Essential SAFe - A starting point for implementing SAFe.

Large Solution SAFe - For Large and complex solutions.

Portfolio SAFe - Enabling business strategies through SAFe.

Full SAFe - The comprehensive implementation of all seven SAFe competencies.

Review

We should now be able to answer the following questions.

What advantages does Agile offer over the Waterfall method?

"From its inception Agile was built to react to changes more rapidly and be more flexible than previous methodologies. It's right in the name-- Agile outlines strategies that work better for larger organizations and can help build a stronger relationship between the organization and its end-users."

What are some main practical differences between Agile and Waterfall?

"Waterfall works rigidly as a linear SDLC, while Agile works iteratively and as such is able to continuously deliver and adjust. The increments must be small (time-boxed), usable, and high-quality. The modular approach requires individuals in the organization to have a broad understanding of the products being built and the management must embody and exemplify Agile's core values. The awareness and cross-functionality required for Agile is supported by working patterns like Scrum that ensure teams stay organized and that high visibility is maintained through events like retrospectives and daily scrum meetings."

What are some core values of Agile?

"Transparency and visibility, communication and personal interaction (Crystal), minimizing waste (Lean), adaptability, and integrity. Working software over comprehensive documentation is one manifestation of placing the value delivered as the first priority."

Where is Agile implemented?

"When agile is comprehensively integrated, it aligns the values of the business with the strategies at all levels of the organization. It ensures that value flows efficiently across the organization, from the stakeholders to the teams and management all the way to the client."

What kind of culture does Agile emphasize?

Agile enables teams to be accountable, self-organizing, and high-integrity. This allows the business to more successfully leverage the strengths of individuals and integrate greater diversity which enhances the organization's culture.

I hope this guide helps you hit the ground running and feel more confident with Agile concepts. If you have any questions or feedback, please share below or connect with me directly here or on LinkedIn!

-Elliot