The world has gone agile.
From fledgling startups to companies like Microsoft, it seems that everyone has adopted an agile approach to software development. They’ve put on their agile hats, scheduled a stand-up, and carved out time for the retrospective.
That makes them agile – right?
Well, maybe not.
Many teams just seem to have missed the point of agile. They pick up a particular methodology like SCRUM and follow it to the letter, but they haven’t done anything to address the underlying shifts that need to occur in order to make a team true to the agile philosophy.
Hayim Makabee, a well-known thought leader on software development, wrote a post about the death of agile altogether–because of oversimplification.
“People forgot the original Agile values and principles,” he writes in the article, “and instead follow dogmatic processes with rigid rules and rituals.”
To get more insight on the importance of agile principles at a team and organizational level, we interviewed Aaron Bjork. He’s a Program Manager at Microsoft who leads work on Visual Studio Team Services. In 2015, he did an interview with Steve Denning for Forbes where he revealed that Microsoft was practicing agile. In the article, he explained how the company focuses on instilling agile principles–ways of thinking about work–rather than emphasizing specific processes or procedures.
The “old ways” of doing software development–waterfall, et al–were built from the artifacts of physical manufacturing. They were built on the idea of an assembly line. Something enters at one end, goes through various steps, and emerges from the other end a completed product, ready to go to market.
“Agile is not something you become–it’s not something you do. It’s a cultural change in the approach for how we plan, build software, and assemble teams.”
- Aaron Bjork, Principal Group Program Manager at Microsoft
At its most basic, agile is meant as a way to destroy outdated views on what the creation of products should look like in a digital age.
Rather than only having one chance to send something through the development cycle, we can send it through over and over again, until it’s “right”. This isn’t an option when you’re manufacturing physical goods.
Agile development has come to be synonymous with things like sprints, iterations, stand-up meetings, and story points. But those are simply representations of the underlying philosophy that is agile. These are manifestations–not prescriptions.
In our interview, Bjork explained the difference. “A lot of people use the words, ‘we are agile’,” he said. “Agile is not something you become–it’s not something you do. It’s a cultural change in the approach for how we plan, build software, and assemble teams.”
It’s important to keep in mind that agile principles are first and foremost about values and mindset more so than processes and procedures.
To be an agile team does not mean to follow a prescribed methodology (e.g., SCRUM), but, instead, to champion the fundamental underpinnings of the agile way of thinking about work.
If we look at the agile manifesto and the core statements of the philosophy, we can break down “agile” into a few underlying values that should shape the way we think about software development, work, and life.
Value #1: Embrace change
Fundamental to the idea of being agile is – well – agility.
That means that teams should be willing and able to change and adapt to new information and changing needs of the ultimate consumer, user, or customer.
“Welcome changing requirements,” reads the agile manifesto, “even late in development.”
Of course, many developers find changing requirements (and thus, scope, generally) frustrating and annoying. But the point in embracing these shifts is to accept the fact that change is inevitable. And, as such, the development cycle should be iterative in response.
Whereas traditional development methods may have been extended indefinitely by scope creep and changing requirements, the shorter delivery times of an agile approach mitigate much of the risk associated with these changes.
But it’s not just a change in the way that the development process works.
Engineers must also reconsider the role of change in the process.
“Get to the point where you’re no longer surprised by change,” said Bjork. “Change will happen. Let’s figure out how to deal with it and adapt.”
Fundamentally, change is an opportunity to improve. It’s a chance to move something closer to perfect, even if it will never be entirely flawless.
This is the central shift in mindset that comes from an agile approach to software development. It’s the idea that nothing is ever “done”–that is is a constant work in progress in need of refinement. And in order to accept that, there must be an acceptance–an embrace, even–of changing needs and requirements.
Value #2: Agile is a team sport
The agile manifesto minces no words about the importance of communication.
It emphasizes both face-to-face interaction and also the importance of cross-functional teams that work together as a unit.
“Business people and developers must work together daily throughout the project,” reads one of the agile principles.
This can be a big departure from traditional business structures, in which the engineering team was often isolated and organized more as a resource pool than an actual team of functioning, thinking humans. Many companies kept the nerds in the corner, basically.
This lack of interaction and integration was harmful in a number of ways. But, it’s beyond just making the team more social.
It’s about recognizing the inherent value that comes from communication and from having teams that work together rather than individuals that work for themselves.
“Get into the mindset of thinking about teams of people,” says Bjork. “Cross-functional teams should own work end to end. Teams need a charter and they need to own and drive that charter.”
In order to achieve that level of cohesion, you need to place a lot of emphasis on regular communication and systems that allow people to work together.
Communication itself holds value for the team, so long as there is sufficient mechanism for those interactions to occur. Again, it’s not so much about the specifics of those mechanisms–daily stand-up meetings are a norm, but not a requirement–but really about the value of the communication itself.
By having a regular opportunity to communicate within and outside of our respective teams, we will create better products. That is the value to be gleaned from this important part of the agile philosophy.
This doesn’t mean the team should welcome a deluge of pointless meetings and endless planning sessions. But, they should recognize the inherent value of communication and collaboration.
Members of the team must have a mindset that a certain level of consistent communication will lead to creating better software.
Value #3: Learn and improve
Most fundamental to the agile philosophy is the shift in mindset around growth, learning, and evaluation. Waterfall development cycles were criticized because the process had engineers toiling away in isolation for months–or years–at a time, hoping to “get it right” and then spend the next several months or years fixing what they got wrong.
In agile, it’s about learning – and closing the loop – as quickly and as often as possible.
The idea of iterative planning and progress has to be embraced by the entire company. As Bjork said in our interview, many companies try to have “agile development” while still requiring long-term planning or year-long roadmaps that don’t make sense.
“You plan, you execute, and you learn,” Bjork explained.
This is one of the biggest changes to the mindset that surrounds software development. In practice, we see this commonly implemented as the use of formalized measurement (velocity, etc) and retrospective.
But, the values that this communicates may actually be more important.
Members of an agile team must be driven to achieve their own level of mastery. Their ultimate goal should not be to complete a specific task or achieve a certain milestone. Instead, they should be driven to achieve based on their own performance and their desire to improve it.
Of course, there are many ways to measure an engineer’s performance, and that’s okay. Because in agile, the drive to learn and improve is not meant to be a formalized, team-wide metric that becomes a target for everyone to achieve.
It’s about valuing the processing of learning and improvement and getting satisfaction from intrinsic rewards.
As individual members of a team, this core value allows the team to work more autonomously and without the need for constant management. The drive to improve is the motivation for working smarter, faster, or more efficiently.
This is closely related to the fourth core value of agile teams.
Value #4: Intrinsic motivation, not extrinsic reward
One more major shift in mindset and values for agile software teams is the focus on intrinsic motivation and self governance over rigid hierarchy and external motivations.
This is rooted in an even more fundamental worldview, which says that professionals do their best work when they are adequately motivated, not when they are sufficiently threatened or bribed.
At the very core, agile teams are built on a dogged faith in this mindset.
If it does not hold true–if engineers aren’t intrinsically motivated and therefore more effective because of it–then the whole premise of an agile methodology starts to unravel.
These values and the mindset that stems from the original agile manifesto are closely intertwined. Without one, many of the others will fall apart. It’s not possible to have a team that is driven by intrinsic rewards if they don’t also value their own need for mastery and learning, for instance.
Remember that the number one principle of agile states the mission clearly. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software,” it reads.
All of the other principles and the values that they represent are, ultimately, a way to fulfill this central premise.
The idea is not that one specific development process is best, but that implementing the right values and adopting the right mindset will unleash the abilities of an engineering team and allow them to do their best work.
7pace Timetracker is the only integrated, professional time management solution for teams using Azure DevOps.
Top comments (0)