Agile

The agile development model is also a type of Incremental model. Agile Methods break the product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks. Every iteration involves cross-functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing, and acceptance testing.

Here’s a quick glance at waterfall practices.

• Everything is planned upfront.

• Requirements are collected in detail before implementation.

• Each step must be completed before moving on.

• The outcome is determined at the beginning.

Plan vs Adapt

I got a good example from the salesforce trailhead and let me highlight here. If you’re trying to decide which process works best for you, consider this: If you’re painting a picture, and you’ve decided your colors, your setting, how much time you will spend painting, and what your final image will look like, then you’ve made little room to make changes along the way. That's not to say the picture won’t be a Picasso, but your process isn’t set-up to incorporate new ideas or feedback that can change the final image (for the better, of course). That’s when you might use a waterfall approach.

But when you paint iteratively, you can expect to make changes based on early feedback, new ideas, or even new learnings (those colors clash!) rather than painting in a planned, incremental, order. That’s a more agile approach. 

Here’s a visual of those two painting processes:

Advantages of the Agile model

• Customer satisfaction by early and continuous delivery of valuable software
• Welcome changing requirements, even in late development
• Working software is delivered frequently (weeks rather than months)
• Close, daily cooperation between business people and developers
• Projects are built around motivated individuals, who should be trusted

Disadvantages of the Agile model

• There is a lack of emphasis on necessary designing and documentation.
• In the case of some software deliverables, especially the large ones, it is difficult to assess the effort required at the beginning of the software development life cycle.

Definition of Scrum

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules.

The Scrum Team:

The Scrum Team consists of a Product Owner (responsible for maximizing the value of the product and the work of the Development Team.), the Development Team, and a Scrum Master.

Scrum Master

The ScrumMaster is like the team mirror. This person keeps everyone accountable for their commitments and calls them out when they’re not executing. They manage the team’s delivery process, including how to inspect and adapt their process and projects. They do all this while coaching the team to excel.

Salesforce ScrumMasters:

• Remove blockers

• Don’t micromanage

• Steer the team from bad habits and inefficient processes

• Enable the team to become collaborative and high-performing

Product owner

The product owner is responsible for what and why of our process. This person works closely with customers to ensure they’re getting a good return on their Salesforce investment. They do this by prioritizing the product backlog and communicating the highest-value work. They’re also responsible for communicating the vision to internal teams by providing them with a prioritized list of work. We call that list a product backlog.

At Salesforce, the product owner:

• Facilitates communication among stakeholders, team members, and the ScrumMaster.

• Defines, prioritizes, and approves work for the team.

• Works with customers to define desired features.

Scrum Team

The team manages its own work and organizes the work to complete the sprint or cycle.

At Salesforce, teams are: 

• Self-organizing and empowered

• Consistently adjusting and updating their process and products based on lessons they’ve learned

• Autonomous

• Accountable individually

• Collaborating on commitments for each sprint

Sprint

In product development, a sprint is a set period of time during which specific work has to be completed and made ready for review. 

Story point

This is used to measure the effort required to implement a story. In simple terms it’s a number that tells the team how hard the story is. Hard could be related to complexity, Unknowns and effort.

1,2,4,8,16 or X Small, Small, Medium, Large, Extra Large. Mostly commonly used series is the Fibonacci series.

Velocity:

• At the end of each iteration, the team adds up  effort estimates associated with user stories that were completed during that iteration. This total is called velocity.
• Velocity is the delivery capacity of the team per sprint. Typically expressed in Story points(effort to complete the story). 
• Velocity is a powerful method by which we can measure the rate at which scrum development teams consistently deliver business value.  Velocity is the sum of the estimates of delivered features per iteration. "Worked example:" an agile team has started work on an iteration, planning to complete stories A and B, estimated at 2 points each, and story C, estimated at 3 points. At the end of the iteration, stories A and B are 100% complete but C is only 80% complete.

Agile teams generally acknowledge only two levels of completion, 0% done or 100% done. Therefore, C is not counted toward velocity, and velocity as of that iteration is 4 points.

How do I estimate future iterations?

Future iterations use the proven history of the team to determine how much the team can do. Therefore, velocity is the right measure to use for planning future iterations.

Product Backlog:

All work items related to a product/project, ordered by a Product Owner. What exactly is a product backlog, and what does it consist of?   

• It’s constantly refined as teams learn new information about the product.

• Higher-priority items have more detail in them so that they’re work-ready.

• It includes not just project-related work, but also support or maintenance work, non-functional requirements, and research.

• The product owner owns it, and it’s their job to prioritize the work items.

Sprint Backlog

• All work committed to and pushed into a Development Teams's upcoming Sprint/iteration as chosen by the Development Team in their Sprint Planning meeting.
• Sprint Backlog is the subset of the Product Backlog.

Definition of Done (DoD)

Here’s a scenario to consider: Imagine there’s a new piece of product functionality that you need to create. You assign this new task to your team and ask them to implement it this month. They do it, and move on. Fast-forward a few months, and the finished work item resurfaces with new problems. Perhaps there are customer complaints because integrations were not fully tested. Maybe security issues were not addressed, or performance was not up to par. The conclusion: The work item wasn’t actually finished, at least not enough to deploy.
Our definition of done is a set of guidelines that dictates everything a team is required to do before they can call the work truly done. Creating a standard for this is critical to upholding one of our core Salesforce values: trust.

• DoD is a subject not object means Team define the DoD. 
• DoD is defined by mutual agreement within the team.
• the Definition of Done provides a checklist which usefully guides pre-implementation activities: discussion, estimation, design
  having an explicit contract limits the risk of misunderstanding and conflict between the development team and the customer or product owner
• the Definition of Done limits the cost of rework once a feature has been accepted as "done"

Implement Scrum

There are two main types of Scrum meetings at Salesforce.  

1. Planning meetings: These happen at all different stages of the project—drawing it out, it looks like a layered cake. Regardless of what stage the project is in, teams regularly meet to ensure they’re aligned on the final outcome.

2. Inspect and adapt meetings: We’ve talked a lot about how important it is for teams to take new learnings and apply them to the next sprint. This is the time they do this. These meetings are geared toward improving the process and the products.

Planning Meetings

Agile teams then use this to continue their planning. 

Release Planning Every 4 Months

• We release new versions of our core platform every 4 months—and there are smaller updates even more frequently with other products. And we deploy infrastructure releases as needed. At the beginning of every major release cycle, we have a high-level planning meeting to create a roadmap for each cloud. 

• Key purposes of these meeting:

• Provide a high-level understanding of new features and functionality.
• Negotiate schedules and set expectations for delivery.
• Align on business and customer priorities.

Backlog Refinement Planning Happens Every 2 Weeks

• The next step in the planning process is to prepare for the upcoming sprint. Teams plan a couple of sprints ahead, where they review their product backlog to make sure the highest-priority items are ready to be worked on.
• What’s the purpose of these meetings? The team provides input and gets clarity on what is coming down the pipe.
• Work is broken into smaller chunks.
• Conditions of satisfaction are drafted, which help clarify desired outcomes.
• Identify work that is not ready for prime time.

Sprint Planning Happens Every 2 Weeks

• Before the sprint starts, teams get together to create a roadmap of what they intend to accomplish over the next 2 weeks. During this meeting, the team agrees and commits to a work plan. 
• Usually, at these meetings, the teams start with the product backlog, looking at what projects are at the top of the list and decide which they can commit to now. 

Daily Stand-Up Happens (Almost!) Every Day

• Although Scrum calls for daily stand-up meetings, most teams exercise the no-interruption Thursday rule, which is exactly what it sounds like: no meeting on Thursdays.
• What does it look like?
• It’s a very brief sync where team members make sure they are all focused on the right objectives for the day—and offer help where needed.
• The frequency is meant to prevent team members from spinning their wheels and bottlenecking progress.
• It provides visibility on daily progress.

Inspect and Adapt Meetings

1. Retrospective: A Look Back at the End of Every Sprint

• This is the meeting where the team can take responsibility for their progress or failures.
• Each sprint, the team spends a little time analyzing how well they worked or didn’t work. They focus on two things during this review period: process and the team. 
• At this time, the team inspects how they worked during that sprint, and then decides what to change and adapt for the next sprint. The ultimate goal is to improve the process and the deliverable every sprint.  
• It is expected for a team to have a couple of “actionable experiments” after each sprint—something new they can try in the next sprint. These new action items are added to their sprint or Kanban boards, and one person holds the team accountable to those. 

1. Sprint Demo Happens Each Sprint

• During the second of the two inspect and adapt meetings, the team presents finished work to product owners and stakeholders to get feedback and input. They inspect their deliverables, and take what they learned and adapt it to their process moving forward.
• Without these meetings, the team misses out on the opportunity to improve.

Scrum Vs Kanban

Scrum Case Study

Imagine if your team has to create a new website. The team can break down the work into the smaller projects. As the smaller work items are completed, the team can review their progress each sprint and adjust to ensure the whole project is delivered successfully. If the project needs a predictable delivery schedule, Scrum is the preferred workflow to use. 

Kanban Case Study

Does your team have to deal with service outages? That’s an example of interruption-driven work. You can’t always know about or plan for outages 2 weeks in advance. Teams that work on architectural, service, or platform support tend to work on items that just pop up and create shifting priorities.