The 3 Things I Learned About Agile
This year, I’ve been to a dozen agile conferences. One thing that stood out for me is that there’s a lot of ‘air talk’. People talk about agile, scrum, agile transformation, etc. After a couple of hours, your head starts spinning and you don’t have a clue what people are talking about. I’m a thinker, so what always goes through my brain is: what’s the relation to REAL life (like eating, sleeping and creating kids)?!?!
A few weeks back I went to Agile Singapore and I was pleasantly surprised. Finally a conference with a great atmosphere and speakers sharing stuff that inspires. Here’s 3 things I learned or things that stood out for me:
1. We’re not practicing self-organization as it was intended by the Agile Fathers
Martin Fowler, one of the agile manifesto creators, started with saying: 80% is pseudo agile. We used to build software based on a ‘planning approach’. We assumed projects follow a linear path we can plan and then make teams follow that plan. In agile we throw that overboard and have teams self-organize and adapt to reality. In his own words (you can read Martin’s detailed views here):
‘Plan-driven engineering expects us to come up with a predictive plan that precedes development. The plan lays out the people, resources and timelines for the overall project. Software design is also done up-front, with implementation expected to conform to this design. Success is measured according to how well development follows this plan.
Agile plans are a baseline that we use to help us control change. Agile teams plan just as carefully as traditional teams, but the plans are constantly changing to reflect the things we learn during a project. Success is based on value delivered by the software.
Plan-driven engineering seeks a process which provides enough structure to reduce individual variations to insignificance. Such an industrial process is more predictable, copes better when people transfer and is easier to define skills and career paths.
Agile engineering sees software development as a primarily human activity, where the people involved and how they bond as a team is a primary driver behind success. Processes (and tools) can enhance a team’s effectiveness, but are always second-order influences.’
In his view, teams must decide what process they follow and how they do things. As soon as someone starts ‘pushing’ a process upon the organization (as happens in methods like scrum and scaled agile), we’re back to the planning approach. Instead of pushing an approach to software development, make sure teams share what they learn with other teams. This way, your organization keeps learning and improving.
The model an organization can use to transform into this pure agile way of working is ‘the agile fluency model‘, created by James Shore and Diana Larsen.
2. A product owner can be a liability
Mary Poppendieck is clearly not a fan of scrum. During her presentation, she indicated several times that a product owner can be a problem. In her view, having someone prioritize work for a team is an insult. We assume that the team is not able to prioritize their own work. Instead of assigning that role to someone, she believes teams need to be given a real world problem to solve, a time constraint and a person they can go to for help. Instead of chewing out user stories, the team would start from the problem and find a way to solve it. Because they have a deadline, they’ll get to work quickly and efficiently. And if they need more input, they can talk to the person within the organization they need (instead of going through a product owner).
The idea inspired me but I also think the applicability depends on the maturity of the team. What I see in my own practice is that my projects can get into trouble if there are too many people in between the team (in India) and the customer (in the EU). When the team has direct access to a customer AND is 100% responsible for the product success, they tend to behave differently. They take responsibility, make sure they get the required information and work hard to achieve their goals. The users on the customer side also take a bigger effort to be available and help the team where needed. When we add a product owner from our side, the team, as well as the customer, start communicating with the product owner. They also hold that person accountable for the results and start bugging him for every impediment. So removing any ‘in between’ makes a lot of sense.
Having said that, there’s often a gap between the knowledge about a particular product or its users within the team (again if they are mature, this gap is smaller). In that case, a person having knowledge about the product can be valuable as he translates user demands into user stories for the team. And in a distributed setup, this person is also closer to the customer (in terms of language, culture and distance), making it easier to communicate.
3. A design sprint gets the whole team immersed in a product
What I always found missing in a scrum is the interaction between the team and the users of the product they are creating. Somehow teams get isolated from reality, from the action, from real user input. Especially if they’re far away in another country. Lean startup appeals to me because it takes user feedback as the starting point. You create an MVP and using the MVP, you get feedback from users. The concept is strong, the practice is hard. I found that it’s hard to decide what an MVP is and you risk building a huge system thinking that’s what you need to test your product. Product owners tend to be the people talking to users and thinking about the MVP. The team executes. But the team should talk to the users (as well).
With the design sprint, you start a new product (or an iteration) with the full team. Everyone is engaged in thinking about the user and generating user feedback. Here’s how it works (source):
Set the Stage
Before the sprint begins, you’ll need to have the right challenge and the right team. You’ll also need time and spaceto conduct your sprint.
Monday’s structured discussions create a path for the sprint week. In the morning, you’ll start at the end and agree to a long-term goal. Next, you’ll make a map of the challenge. In the afternoon, you’ll ask the experts at your company to share what they know. Finally, you’ll pick a target: an ambitious but manageable piece of the problem that you can solve in one week.
After a full day of understanding the problem and choosing a target for your sprint, on Tuesday, you get to focus on solutions. The day starts with inspiration: a review of existing ideas to remix and improve. Then, in the afternoon, each person will sketch, following a four-step process that emphasizes critical thinking over artistry. You’ll also begin planning Friday’s customer test by recruiting customers that fit your target profile.
By Wednesday morning, you and your team will have a stack of solutions. That’s great, but it’s also a problem. You can’t prototype and test them all—you need one solid plan. In the morning, you’ll critique each solution, and decide which ones have the best chance of achieving your long-term goal. Then, in the afternoon, you’ll take the winning scenes from your sketches and weave them into a storyboard: a step-by-step plan for your prototype.
On Wednesday, you and your team created a storyboard. On Thursday, you’ll adopt a “fake it” philosophy to turn that storyboard into a prototype. A realistic façade is all you need to test with customers, and here’s the best part: by focusing on the customer-facing surface of your product or service, you can finish your prototype in just one day. On Thursday, you’ll also make sure everything is ready for Friday’s test by confirming the schedule, reviewing the prototype, and writing an interview script.
Your sprint began with a big challenge, an excellent team—and not much else. By Friday, you’ve created promising solutions, chosen the best, and built a realistic prototype. That alone would make for an impressively productive week. But you’ll take it one step further as you interview customers and learn by watching them react to your prototype. This test makes the entire sprint worthwhile: At the end of the day, you’ll know how far you have to go, and you’ll know just what to do next.
With this setup, everyone in the team thinks about the product or new feature you’re creating. You don’t have a product owner talking to users to gather requirements. The whole team thinks about the solution. This matches with the views of Martin and Mary on self-organization and not having an ‘in between’ messenger.
What I particularly like is step 2. What often happens is that some people are shy to express their views on a solution. Some people may not be able to express themselves in words. With the sketching on the second day, you enable everyone to participate. It’s not a brainstorming, but a creative process where people draw.
The developers, designers, everyone also think about the questions they’re going to ask the users. They will see real users interact with the prototype they created before they even wrote a line of code. I think this fosters a mindset often needed in tech teams. Coders like to code. They love building stuff. But that’s not always what’s needed, especially if you’re creating a new product or big feature. By thinking about the solution that’s required, by seeing the feedback from real users, their minds will work in a different way. They’ll immerse themselves into the product and its users before writing anything.
I’m a big fan of scrum. I also love the idea of ‘agility’. For me, agility means creatively experimenting with different approaches. Not getting stuck in one particular process or method. Not creating strict routines, but changing the way you work. Some of the views above are more rigid (this works, that doesn’t). As agile practitioners, I believe we should experiment with these three things:
1. Go for 100% self-organisation. Give teams a problem to solve, a time frame and a person to help them
2. Try a couple of projects without a product owner and see what happens
3. Do a design sprint (or two) and see how it brings your team closer to the product and users