[MUSIC PLAYING]
SPEAKER: Hello.
This course covers the key steps to adopting Agile development
in your API program.
From our combined experience at Google,
the first start to any adoption is a mindset shift.
Agile software development just makes sense.
And if you've been through traditional waterfall
development, you know about the big handovers, big team silos,
and difficulty in collaborating, and plan change.
The values and principles espoused in this manifesto
will derive and underpin a broad range of software development
frameworks, but primarily seek to solve
the root causes of the software development in waterfall.
The term Agile was popularized by the Manifesto
for Agile Software Development.
Take a moment to read through it and visit their website.
Agile can be adopted in many different software settings
within the digital value chain for our course.
We focus on the Agile method of developing APIs
by the API team.
A core part of Agile is to have one cross-functional API team.
This means the API team should be
largely self-sufficient with as few dependencies as possible.
Here's what the Agile API team would look like.
The core API team is in the middle with one team made up
of the API product owner, API developers, QA engineers,
and SCRUM master in the inner ring.
They are constantly working together.
The outer ring represents also core team members
who may not be fully dedicated to the API team,
and might be partially allocated over time
to support multiple API teams.
The role of connecting with non-core team members
are represented with arrows showing
specific individuals who should take ownership
of these key activities.
We explore each one of the roles and relationships in depth
throughout this course.
For teams starting out with Agile,
one of the biggest pitfalls is taking on too much scope.
A great way to adapt to changing plans
is to reduce the size of each software scope implement.
Developing software in a new way can
be difficult for inexperienced teams.
So a smaller scope is even more ideal for them.
Size the scope of your API project right
and focus on the minimum viable product.
Ask your team, what is the least we
need to build that will still deliver business value?
The picture here shows three different ways
to build a transport device over four releases
with a business goal of getting from point A
to point B. The first example should be avoided,
which is building incrementally.
After each release, there's no business value.
Since we only get from point A to B
until the very end in release four.
The second example is better.
It achieves the goal of getting from A to B in each release
with a working device.
But it forces the team to rework the product in every release,
leading to a lot of waste and throw away effort.
The third example is the MVP approach.
We can transport from A to B in each release.
But we have minimal rework since we're
built on top of the previous releases functionality
in a smart sequence.
You can think of Agile API development in just this way.
Deliver the right MVP and pay close attention to the sequence
you are releasing your new APIs.
To be really efficient, it's not enough to release often
but to release with quality and with the least
amount of effort.
Instead of writing test cases after development is complete,
write the test cases and define the success criteria upfront
in design before the development starts.
This practice comes in two flavors,
test-driven development, and behavior driven development.
Both are very similar and achieve the same outcome.
Both methods output code that can then
be automated by QA engineers who can string together
a series of unit tests and tests written through TDD or BDD
to becoming integration level tests for the API.
By running test cases that are programmable scripts,
we can run the tests over and over again,
taking a huge load off the traditional QA bottleneck
and makes turnarounds on the QA feedback loop incredibly fast.
For more information about testing,
refer to the QA strategy course later on in this series.
The principle of automation is quality--
is an essential part of Agile transformation.
No other practice represents this
better than setting up a continuous integration
and continuous deployment pipeline.
This shortened acronym is CI/CD.
The main goal is to prevent integration hell, where
multiple developers begin integrating
large chunks of code near the later phases of the project.
To avoid this drama, the picture to the left
illustrates a recurring cycle from code check
in, to testing, to deployment, of the API bundle,
to updating the API documentation.
The purpose to do this cycle on a frequent basis or even
on a per code commit basis.
By using software like Jenkins and programming
to move code from each one of these steps,
this process can be largely automated.
This reduces human effort and increases the frequency
that the cycles run so that errors are caught early
starting from the first week of coding.
This practice of mastering the CI/CD pipeline
is essential in adopting Agile development.
Now that we have a good grasp of the fundamental strategies
and tactics of adopting Agile, let's discuss
the process of implementation.
Here's the familiar waterfall process,
long release with lengthy stages and big handover points
often from one team to another with risk and unknowns
unsurfaced until we get into that particular stage.
You've probably been through it and have some pretty
interesting stories to tell.
Teams that move away from waterfall
have a tendency to move into SCRUM fall.
It breaks the work into sprints and starts testing cycles
early on so it helps the team pivot
and provide early visibility into progress.
However, because testing is separated as a post sprint
activity and not included during requirements definition
and sprint, testing and bug fix time is elongated and long
release cycles invariably happen.
If you have large scope that you can't break apart,
this is still better than waterfall.
However, with API development, and most software development,
we can definitely go further than SCRUM fall.
The first important tactic to avoid SCRUM fall
is to merge development and QA into one sprint.
This likely means you will take on less work in the sprint
to give time for bug fixing.
But with testing and fixing merged into the sprint,
you've tested and ready to release functionality
at the end of each sprint.
This gives us the real ability to pivot.
Make this your first goal for the team.
Just testing furiously during development isn't enough.
We need to incorporate the principle of definition
of quality up front.
If developers are not fully aware of the test criteria
or QA engineers have to spend more of their time
defining their test criteria in the sprint,
precious time will be wasted in the sprint.
Have the QA engineers and the developers work
with the requirements to define the test
criteria ahead of the sprint.
This can be done using test-driven development
method or the behavior driven development
we spoke about earlier.
Go as far as having the test scripts coded so that the QA
engineers are just making minor modifications
in the sprint itself.
With testing definition brought up
in between requirements and sprints,
your last step is to automate the CI/CD pipeline.
Don't shortcut or give up on laying down
the foundation for automation, testing, and optimizing
the team's process.
With time, your team will come to trust the process
as the testing begins to speed up development and quality.
Now that we have a higher level approach down, let's dive a bit
deeper into the Agile process.
There are two common variant processes
in Agile, SCRUM and Kanban.
Please take a moment to read the descriptions.
While SCRUM has more processes with more steps
to take into account, the cycle of development
is more familiar to many teams and more friendly for new teams
being formed.
Kanban, although easy to pick up,
relies on work that are smaller chunks of effort
and less dependent on other work.
Teams that have been working well together who can really
self manage in Agile may be better at picking up Kanban.
For the purpose of this course, we
will focus on SCRUM given its complexity and higher
rates of adoption.
Whichever process you pick, commit to it.
Don't switch back and forth until you really
feel like the team has lived and learned through that process.
Since the SCRUM process can be quite complex,
we're going to step through this process one at a time.
A product owner is the starting point at step one.
It all begins with a vision.
From this vision, we develop an API roadmap.
This should be a high level scope of the components needed
to achieve this vision and deliver value
for the organization.
This roadmap can include different sets
of APIs, business adoption, apps usage, key compliance efforts,
infrastructure, and even improvements
to the developer portal.
With a product roadmap, focus on what
will be the first valuable release.
Keep in mind the MVP principle.
Now that you have the scope of your first release,
it should be quickly turned into a rank list of requirements
in step two.
These requirements are written in the form of epics and user
stories.
Often at this point, the habit is
to go into a lot of requirements detail.
Don't.
Instead of going deep, list all the high level features
and requirements.
If you're spending more than a week on this,
you're likely going to deep.
Step three is where most of the recurring action process
happens.
The API team will select the most important user stories
to work on for the coming sprint.
The user stories have to be fully fleshed out
with business, technical, and testing details.
The API team will review each user story,
break down the activities into tasks needed to build this user
story, estimate the effort, and commit
to a set of user stories for the next sprint.
Each sprint can be one to four weeks in length.
But we often see teams settle on two weeks as the happy medium.
At the end of the sprint, the user stories
should be completed and ready for go live.
Anything not finished will be carried over to the next sprint
or place back to the product backlog.
This sprint cycle repeats itself again.
Throughout the sprint cycle, the SCRUM master is the coach
and tracks the team's productivity
through burn down and burn up charts
to measure the team's progress in the form of velocity.
We will cover velocity later in this course.
In addition to tracking progress,
several ceremonies are core to SCRUM.
These key ceremonies are listed in steps four, five, and six.
In step four, the daily SCRUM is a daily 30 minute activity
where each member talks about the progress they made,
their task for the day, and any blockers.
This is the time for the team to take the pulse of the progress,
and drive action, and ask for help in step five,
a sprint review, also known as the sprint demo,
occurs at the end of the sprint.
It's generally meant to recap what has been built
and provides a moment to celebrate and to publicize
the achievements of the team.
In step six, the sprint retrospective
is a ceremony also at the end of the sprint.
The teams comes together to self reflect on what went well
and what could be improved.
Oftentimes, the best improvements
come from a team retro.
One area of confusion we encounter
is what happens in between the steps from product backlog
to finish work.
The ceremonies are fairly easy to understand
but the sequence can be a bit tricky to visualize.
Let's unpack this a bit more.
Taking another view of a sprint by sprint,
you will see a repeating pattern where the product backlog
items are refined prior to the start of development.
This repeating effort is called backlog refinement.
A team process that is usually established
in the beginning of the project is
called the definition of ready.
This checklist is the agreement within the team
of when a story is refined enough
for the developers and the QA engineers to start the sprint.
Thus, this is a clear target for even the team members doing
refinement on how far they need to go to meet
the definition of ready.
Refinement is a collaborative activity.
It's very important that the product owner, API architect,
and QA engineer all focus on the same set of user stories
in the priority order of the backlog.
After they are done with refining S1,
they move on to S2 and refine that set.
This continues until the backlog is all refined.
Once a set of user stories in sprint one is refined,
sprint planning starts as either a recurring activity
before the sprint in small chunks
or one larger session at the first activity of the sprint.
The output of sprint planning is a full set
of tasks per user story.
With this, the team goes to work on development and test
scripts writing in execution.
This process continues iteratively in sprint two,
three, and so forth.
The team also needs to set the definition
of done for a user story at the start of the project.
This is the line for the team to draw
in terms of the standard of finish and quality
that should be adhered to.
This way, there's no misunderstanding at the end
of the sprint when a user story is marked done.
It's up to the team as a whole to enforce this standard.
In the last step, finished work can
be queued for product release and bundled
in the release per sprint.
The automated CI/CD pipeline helps the last leg of process
quickly flow from test and approve code
into the main branch.
We cover a ton of concepts and strategies in this course.
To summarize, create cross-functional teams
and close the ties between IT and business.
Avoid legacy and waterfall processes
so you can deliver a smaller scope
and pivot on a regular basis.
Always look for ways to automate and reduce any big handovers.
Use methods like behavior driven development and concepts
like definition of ready and definition
of done to build quality into the process.
And align the teams on a shared expectation.
Don't worry.
You won't get it perfect on day one.
Use the feedback loops like the sprint ceremonies
to take feedback and optimize.
Every Agile team will tailor their process over time.
If there's one more last principle of Agile to remember,
this is about continuous improvement.
That's your North star.
I hope this course has helped you
get a firmer grasp on transforming into an Agile
development team.
If you want more information, please check out
the community for ebooks, articles,
and other related topics.