Tag: Food for thought

I first saw Ben Linders on Twitter being quite active and responsive. I then chanced upon his blog and was overwhelmed to see myriad of topics that he has covered. One interesting thing I found out that we have one thing in common, we interview people. I decided to learn from his experiences and bring it for our audience, and here it is;

Q.1 Tell us one thing no one knows about Ben Linders?

Ben: Being very visual in many ways, at conferences, on my own website and in social media, there’s hardly anything that no one knows about me. Although most people that I am connected with professionally don’t know that I love to go scuba diving, both in the Netherlands, and in tropical waters. I’ve made 1300++ dives in 25++ countries, and counting …

Q2. What made you go Agile? Is there anyone who inspired you to do so?

Ben: When I became a project manager my line manager told me that there was a project which he wanted me to finish. Diving into this project I found out that it had been ongoing for more than a year without success. The customer was about to give up. I quickly decided that my first priority was to deliver a first part of the solution as soon as possible, something that we could show to the customer to gain trust.

The team and I divided the functionality into increments. In the first increment we addressed one of the main risks and delivered core functionality. We excluded everything else to focus on the main problem and were able to deliver a piece of software running on a PC (the application was embedded software for a CNC Milling machine).

Our customer was happily surprised when we showed him the software. The next day he called us, and told us that he had tried it and found out that worked well, except for one situation. Going through the failure on the phone we immediately understood the problem, and agreed that it would be solved in the next increment.

Each increment we added new functionality and solved problems that either the team or our customer found. Building a relationship with our customer by delivering the product in increments was beneficial for both of us. I recall a situation where the team discussed a problem and concluded that there was no feasible solution. It would need very complex software dealing with lot’s of exceptions. I called our customer, explained the situation, and asked him what the system should do. His answer was: “If this happens, just give an error message to the user and abandon processing”. If we would try to execute it, it would damage the CNC machine! We could have wasted many days trying to solve it, now it took us less than an hour to find out what the system should do by just asking our customer.

As you might guess from some of the grey hairs that I have, my first project was a while ago. To be precise, this was in 1990 when I worked as a consultant for Philips. Agile hadn’t been invented, there was no Scrum with sprints planning and product reviews. I came up with the approach to deliver value to my customer in increments because it made sense to me and my team.

When I saw the early manuscripts from Alistair Cockburn on The Cooperative Game and heard about agile at the start of the century it made a lot of sense. The values and principles are things that I’ve been doing throughout my career. Now they have a name 🙂

I have been inspired by a couple of people. One is Tom Gilb, I got a lot of great ideas reading his book Principles of Software Engineering Management. The book Peopleware by Tom DeMarco and Tim Lister helped think about how I could create the best environment for my team members. I also learned a lot from Watts Humphrey’s views on software development as a process and finding ways to improve.

Q3. How important is Retrospective in life?

Ben: Great question! Most people will do retrospectives regularly, although they might not be aware of it. When they bump into problems, they look for ways to prevent similar problems in the future by reflecting what happened. When things go great they also want to know why.

An agile retrospective, or sprint retrospective as Scrum calls it, is a practice used by teams to reflect on their way of working, and to continuously become better in what they do. The whole team attends the retrospective meeting, where they “inspect” how the iteration (sprint) has been done, and decide what and how they want to “adapt” their processes to improve.  The actions coming out of a retrospective are communicated and done in the next iteration. That makes retrospectives an effective way to do short cycled improvement.

When teams or organizations go for agile, they will go on a journey of continuous adaptation and improvement. Agile retrospectives support this journey, that makes them a vital tool for agile teams and organizations. My advice: Don’t skip them, and ensure that they can be done effectively.

Q4. What can make an Agile Transformation a failure? How can we prevent it?

Ben: Many organizations fail because they try to treat it as a project with an goal, budget and end date. Such an approach is killing for any transformation, and certainly if an organization wants to adopt agile.

First, agile has no goal or end state. Being agile means you are never done. As I mentioned before, it’s a journey of continuous improvement, you never stop looking for ways to deliver more value to your customers and stakeholders.

Second, don’t think about agile as something that will cost you money. Instead focus on the value that you can get.  Think about why you want to become agile. Is it because you want to deliver faster? Deliver the right stuff and thus more value? Become more innovative? Create an environment where people love to work and hence are more productive? Knowing why you want to become agile is crucial to be successful with your transformation.

So don’t think of agile as a project. It’s a mindset and culture change, a journey of sustainable improvement. If you want your transformation to be effective, my suggestion is to play the Agile Self-Assessment Game to find out how agile you are and how to increase your agility.

Q5. When do you realize that a person is not a team player?

Ben: A team has a shared goal where team members work together and support each other to reach it. Look at the way people behave. Do they talk to each other? Offer help or reach out when they need it? Walk over to someone when there’s a problem. If you don’t see this happening, then your team is probably in trouble.

Q6. What do you wish for the Agile Community?

Ben: My wish is that the agile community adopts a mindset of sustainable improvement. Agile is about “finding better ways”, learnings what works and what doesn’t. It’s not a process that you can roll out and implement, let’s stop wasting time on that.

Q7. Final words for our readers…

Ben: I’m sharing my experiences (and those of others) on my blog benlinders.com. And I like to hear your experiences with agile, what worked for you and what didn’t. Always eager to learn.

 

 

Ben Linders is an Independent Consultant in Agile, Lean, Quality and Continuous Improvement, based in The Netherlands. Author of Getting Value out of Agile Retrospectives, Waardevolle Agile Retrospectives, What Drives Quality and Continuous Improvement. Creator of the Agile Self-assessment Game.

As an adviser, coach and trainer he helps organizations with deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers.