Understanding agile

Selecting transcript lines in this section will navigate to timestamp in the video

- If you want to build a product that really excites your customer, then you have to rethink how to work
together. Your team will want to adapt to include cutting-edge new features and immediately respond to
customer feedback. That's why many teams are embracing an agile mindset. I'm Doug Rose, and I've
been coaching on this mindset for over 15 years. In this course, we'll go through how to think like an
agile team. You'll see foundational concepts in the Agile Manifesto, along with common roles and
practices. Then we'll go through some exercises to help you improve your team's agility and avoid
common obstacles. Agile teams are more predictable, more collaborative, and usually more fun. So let's
embrace our new mindset and start learning your agile foundations.

The agile mindset

Selecting transcript lines in this section will navigate to timestamp in the video

- There's an old philosophy joke where two fish are swimming in the ocean. One looks at the other and
says, "The water looks pretty cloudy today." The other fish looks back and says, "Yeah, what's water?" I
love this joke because it shows that the way we do things often becomes part of our own reality. It's the
water we're floating in without even thinking. We don't question the way we work; instead, we think
that the way we work is the only way that makes sense. But the way we work reflects a certain mindset.
It might seem natural for you to have a set of skills that makes you a specialist, maybe you're a project
manager or database engineer, so you only focus on these skills when you're working. It also might seem
natural for you to only work on detailed plans; otherwise you might have costly rework. Yet the water we
swim in isn't always so clear. In fact, it might be more efficient to have generalists instead of specialists.
Instead of having a few people who really know one area, it might make sense to have everyone know a
little bit about everything. It also might make sense to focus on short-term planning. So instead of
focusing on eliminating rework, you're actually embracing uncertainty. Some of these ideas are now
more commonly known as the agile mindset. And that's how you should think of it, as a mindset. You're
not just focusing on a different way to work; instead, you're focusing on a different way to think about
working. I've seen many organizations that try to use agile to improve their product delivery. They might
rename their project managers into scrum masters. Maybe they'll break down the requirements into
agile-style user stories. All of these agile practices are fine, but on their own, they're not going to help
you reach a higher level of productivity. To get real benefit from agile, you have to start by addressing
your team's mindset. You have to take a hard look at the reality of how your team works together. It's
better to be a team that's terrible at agile practices but understands the mindset. A truly agile team
should be able to ask tough questions about the way they work and be open to continuous
improvement. If you see agile is just an updated set of project management tools, then you'll probably
be disappointed. You don't want your team to be focused on agile practices; instead, you want to be
focused on thinking like an agile team. That's why the first step is the focus on the why. When you look
at these agile practices, don't think about mastering them; instead, think about the reasoning behind
them. Think of it this way: later you'll learn about the importance of delivering in shorter iterations or
what are commonly called sprints. These are typically two-weeks long. When you see these, you
shouldn't think how you're going to deliver your product in two weeks; instead, think about the
reasoning behind sprints. Why does shorter sprints improve your team's agility? These questions will
help you so much more when you're trying to change your team's mindset. If you're just working the
same way but in a shorter timeframe, then you're not going to see much improvement. If you
understand why you're doing things differently, then you'll be much better off as an agile team.

The rise of knowledge workers

Selecting transcript lines in this section will navigate to timestamp in the video

- In the past, a lot of times you can learn everything you need to know by moving up the corporate
ladder. Today, there are many ways that modern product delivery makes that much more difficult. So it's
important to think of the Agile mindset not just as a new thing, but as a reaction to difficult challenges
with typical product delivery. In the 1990s, many project managers recognized that they needed a way to
deliver products in a new way. What they found is that many of the people working in the organization
had changed. These different employees started to specialize, and it was difficult to find a generalist who
understood all the different specialties. So a database engineer might know a little bit about software
development, but not enough to manage a team of developers. This led to a serious challenge in
management. It put project managers in a difficult position. They were responsible for delivering the
product, but had very little knowledge on how to make key technical decisions. Software products had
also become much more complicated, so it forced many more people to specialize. It was harder to just
be a computer scientist who built an entire product. Instead, now you had software developers,
database engineers, testers, and even infrastructure specialists. Think of it this way. I grew up outside of
Detroit, and when I was a kid, most of what you needed to work in a factory was a lunch pail and a
desire to learn. So you might start out as a lineworker, twisting bolts. Then over time, you might get
promoted to a line manager. Finally, you might get a job in the office, and manage hundreds of
employees. By the time you worked in the office, you knew almost everything there was to know about
building a product. You probably start building them yourself, and then worked your way up into
management. The managers then have the knowledge of the workers they managed. Now, compare that
to a modern software project manager, who you might manage a team with many different specialists.
Each person probably spent decades building up their own expertise. There's no way that one project
manager could know all the different decisions that it takes to build a software product. They couldn't be
a database engineer, software developer, and infrastructure specialist. Even if they did, they'd never be
able to keep up with the changing technology. That's because there's a big difference between managing
workers in a factory, and managing knowledge workers developing software products. Knowledge
workers are employed for what they know. That makes it very difficult to manage them with a traditional
hierarchy. You can't direct a team of people who collectively know more about the product than anyone
else in management. So you have managers becoming less directive, and more supportive. One of the
key things that you see with Agile teams is this push to be self-organized. That's because it's difficult to
manage the team with a top-down approach. So you shouldn't have one manager who's directing the
team to deliver the product. There's no line manager like you have in a factory. Instead, you focus on
having collective decision-making. This is a very difficult change for most organizations. Many managers
like to tell their employees what needs to be done, and then they go off and get it done. They might not
be ready for a group of specialized knowledge workers coming up with their own plan on how to deliver
the product. Later, you'll see the importance of this servant leader style management with a role called
the scrum master. But this role is just part of a larger trend in self-organization. A lot of the Agile mindset
focuses on giving these knowledge workers the flexibility they need to succeed.
Challenges with software manufacturing

Selecting transcript lines in this section will navigate to timestamp in the video

- A lot of the ways we work comes out of manufacturing. That make sense because some of the first
projects work with materials like wood concrete and steel. Large companies build cars, roads, and
buildings, but when you're working with wood and concrete, you have a completely different set of
challenges than when you're working with software. You'd never start building a bridge and then change
direction midway through the project but with software that's much more common. It's easier to
reprogram software than it is to rip up steel and crack concrete, but many projects are still governed by
the ideas that came out of manufacturing. One of the most common is that there's still a lot of focus on
planning out the work. In fact, you could spend as much time planning as you do building. That's why it's
still common to hear managers say, plan the work, then work the plan. That makes a lot of sense if you're
building something like a bridge, ship or a building. How you want to plan everything that goes into the
project before you start, you also want to break up your project into phases. So first you want to play on
your bridge, then finish planning, then you want to build your bridge, then finished building, then you
want to test your bridge, then finish testing. Each of these phases happens sequentially one after the
other. It all makes sense in a world of steel and concrete, but software is much more like science than
manufacturing. When you're developing software, you're doing a mixture of building and learning. As
much as it's tempting to plan everything out, it's just too difficult to predict all the moving pieces. If you
think about even a simple software product, it might depend on an operating system like Microsoft
Windows. Then it might rely on several different open source projects. The development language might
change or get updated. All these different changes are impossible to predict. Most software products
have to deal with something called the cone of uncertainty. The best way to think about the cone of
uncertainty is to imagine the relationship between time, knowledge and costs. So think of it this way, I've
spent a fair amount of time on the east coast of Florida. This is one of the states in the US that has to
deal with a lot of tropical storms. It's sort of a strange experience to be near a tropical storm. At first, the
meteorologists only have a general idea of where the storm will land. So they might say it'll hit landfall
anywhere along the east coast, but as time passes, they gain more knowledge about the storm, so they
can warn which cities to evacuate. Then just before the storm hits, they know exactly who will be
affected. So the corner of uncertainty is the widest a few days before landfall. Then the cone narrows as
the meteorologists gain more knowledge and time passes. The problem is that the meteorologists know
the most about the storm when it's too late. This is also one of the biggest challenges with delivering
software products. You know the most about what it takes to deliver the product only when you're
nearly finished. So many of the decisions that you make at the start of your project will be the ones that
need to change. Unfortunately, as you get closer to the end of your project, it also gets more expensive
to make changes. So you need to find the balance between making the minimum amount of decisions to
get started, but still give yourself enough flexibility to make changes. This balance between making
decisions and having a flexibility to make changes is one of the key parts of the agile mindset. That way
you can help make lasting decisions, even when you're working within a cone of uncertainty.

Give feedback