A tale of two mindsets
How does a waterfall team approach a problem?
Meet Tim. Tim is a manager of the tech department of a waterfall software development shop. Tim and other managers in the department were worried because the DAU (daily active users) of their online application was in decline. So they gave themselves a goal: to increase this metric by 15% in 3 months.
They brainstormed ideas, discussed alternatives, discarded unpopular ones, and decided to revamp their website with the latest, flashiest javascript+elixir+phoenix combo. Tim was in charge of driving this effort.
So now, Tim needed to find an available software architect and designer in the department to start with the specs, wireframes, and designs of this new version of the product.
After these specs and designs were to be completed, they would be sent to some of the front-end developers, some backend developers, and maybe involve one DBA to review the persistence layer. When the development was done, they would throw it over the wall to some Quality Assurance experts (QAs) to test.
How long would this take?
Probably a lot more than the company could afford with an underperforming product.
Also, there is an important question that Tim and others were failing to ask: will revamping their online application solve the problem they were trying to solve? Not necessarily.
When sprinting, make sure you are running in the right direction.
This is the stereotypical development practice in a waterfall shop. With this mindset:
- Decisions are made at the top and given to the dev teams for implementation;
- Managers assign tasks to developers who are treated as kids that need to be reminded not to slack off, also known as command-and-control;
- The goal is 100% utilization of (human) resources. If employees are not doing what they were hired for, it’s a waste;
- Devs are treated as replaceable resources.
How would it be different on an agile team?
Enters Tina. Tina is an Agile Manager and she has a self-managed team. But wait, how does that work, a manager on a self-managed team? Exactly. Self-managed doesn’t necessarily mean that you don’t have managers per se, but means that managers will act as servant-leaders and as coaches. They give the team tools, freedom, and trust to solve problems. One of the principles of the Agile Manifesto is:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Let’s use the same problem of the example above. How would Tina interact with the team? Tina won’t tell her team to revamp the webpage. Tina will give the team the problem itself, the challenge to increase the DAU of their product by 15%, it’s up to the team to figure out what’s the best solution. We already talked about how the proposed solution might not fix the problem, so why not give the team the problem itself?
Agile teams are given problems to be solved, not solutions to be implemented.
What Agile managers won’t do is tell developers what to do. Agile teams are self-managed. They have full autonomy to decide how to solve the problem.
Tina’s team is cross-functional, which means that team members have all the skills necessary to deliver a full-fledged, full-stack solution. She has a team of experts with a few back-end and front-end developers, some designers, one DBA, and a couple of QAs working together with the support of key stakeholders.
Agile teams are cross-functional. The agile team is a team of experts.
But wait; Scrum, the most popular agile framework, doesn’t recognize different roles in the team. They are all part of the development team, who work together to deliver the product that the Product Owner (PO) requested. So which one is right? Is it a team of experts or are there no distinctions between the team members?
Well, it’s both. In an agile team, you do have a team of experts, but silos are broken down. The individuals dissolve into the team. They stop being a group of people working together and become a team where the whole is greater than the sum of the parts.
If that sounds too cliche, let’s dig deeper and look into how an agile team divides work and own its tasks:
Let’s say that the team is working on a story for a certain feature. Samantha, the back-end developer, finishes her tasks, performs all the pending code reviews, optimizes the workflow and is now ready to pick up another task. All the back-end tasks of the stories of the current sprint are already completed. However, she notices that the there is one story with many pending front-end tasks left. What should she do next? Should she work on the next back-end task that is from a story not on this Sprint?
No, she decides to sit with Peter, the front-end developer, and figure out how to complete this story together, either pair-programming with Peter or picking another front-end task to work on her own. Samantha didn’t commit with the PO that, as a back-end developer, she would complete only back-end tasks; rather, Samantha, Peter, and the others committed as a team that they would complete the stories and the features together.
The whole team owns all tasks, not individual people owns individual tasks.
To make an analogy, think of the team as a start-up and that the PO as your client. Then imagine your team might miss the deadline (and even the contract) with that client. So for your start-up to survive, it needs to focus on delivering the value to your clients, rather than the expertise of each individual member.
Agile team members slowly grow their skills on a T-shape, where they have the depth of knowledge in one area, but also the breadth of knowledge in several other areas. They are generalists and specialists at the same time.
What else is different? Well, as we’ve seen, there was no guarantee that revamping the website would be the best solution. The agile team doesn’t know what the best solution is, but it has some ideas. So it’s time to test a few of them. That’s where two components of agile shine together: ‘short-iteration loops’ and having an environment that is safe to fail.
The team can prototype a possible solution in one or two iterations, measure results, and from there decide to either discard the idea, because the solution hasn’t been proving effective, or start a new one. Because the team has complete safety to fail, they won’t be afraid of innovating; they won’t be afraid of trying something out-of-the-box, and even a bit risky, in order to achieve an outrageous positive result. If it doesn’t work, they don’t mind, because now they learned something. They are more knowledgeable about the problem at hand, and the next solution they come up with will have a better chance to succeed. Failures are celebrated as learning.
Safe to fail = innovation
Short iteration loops + Failure = Fail with short-blast radius
**
Failure= Learning**
By iterating over the solutions and measuring results, they will arrive at a more suitable solution. Tina, the manager, doesn’t need to keep assigning tasks or reminding them to do task A or task B; she trusts them to do their jobs (they are adults, after all). Since the solution was their idea, they will take ownership of the solution and be motivated to get the job done, and done with quality. The team feels empowered.
Agile teams take ownership and pride in what they do… because they are in charge of it.
Who else is in an agile team? One of the agile principles is “Business people and developers must work together daily throughout the project.” Several agile methodologies implement this differently. Extreme Programming dictates that the client is highly available in the team, preferably co-located. Scrum has the PO who ideally will have an intimate knowledge of the product and a close relationship with customers/clients/stakeholders. Another role in Scrum is the Scrum Master. But even if not implementing Scrum, it’s always recommended that teams have an agile coach to guide the team to become truly high-performing and achieve their growth goals.
Tina knows that members of the agile team don’t need to always be 100% busy. She focuses on the baton, not the runners. Developers are not supposed to always be coding; designers, be designing; QAs, be assuring quality. They need space to think, talk, teach, learn, and grow; space to improve processes and relationships; space to learn more about the business and the industry. She focuses on the value being delivered to the user.
Agile managers and teams focus on the baton, not the runners.
An agile team will also, as frequently as they deem necessary, inspect how they are doing the work, and find ways to improve it. This “continuous improvement” is based on The Toyota Way and adopted by agile teams. So their jobs become not only doing their work but also improving the way they do their work.
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
With this mindset:
- Decisions are made at the bottom, where the work is being done;
- Managers are servant-leaders, giving the team the space to do their best work;
- The goal is 100% value delivery. Any unfinished work (that is, work that hasn’t been delivered to the user) is a waste;
- Devs are not treated as resources, but as learning individuals and as adults–respected for their skills.
Tina’s agile team will have a much better chance to solve this problem than Tim’s. They will use short iterations to test their ideas and get feedback from users. They will take ownership of the solution because they are motivated by the autonomy that they experience by solving a real business problem.
Agility, in the end, is not about all these highlighted topics in this article. Agility is a mindset, a new paradigm of doing work. Just following a set of steps won’t make you agile, but having the right mindset will make you understand why certain steps should be taken and others not.
If teams can’t adapt to business, market, and technology changes, and also deliver value in small increments, they will lag behind. Nowadays, agility is not even an edge; in order to stay relevant, it’s a necessity.
Top comments (2)
Awesome! Thank you :)
This was all i needed. Thank you