Ben: Being very visual in many ways, at conferences, on my own website and in social media, there\u2019s hardly anything that no one knows about me. Although most people that I am connected with professionally don\u2019t know that I love to go scuba diving, both in the Netherlands, and in tropical waters. I\u2019ve made 1300++ dives in 25++ countries, and counting …<\/span><\/p>\n Q2. What made you go Agile? Is there anyone who inspired you to do so?<\/strong><\/p>\n 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. <\/span><\/p>\n 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).<\/span><\/p>\n 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.<\/span><\/p>\n 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\u2019s of exceptions. I called our customer, explained the situation, and asked him what the system should do. His answer was: \u201cIf this happens, just give an error message to the user and abandon processing\u201d. 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.<\/span><\/p>\n 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\u2019t 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.<\/span><\/p>\n 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\u2019ve been doing throughout my career. Now they have a name \ud83d\ude42<\/span><\/p>\n 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\u2019s views on software development as a process and finding ways to improve.<\/span><\/p>\n Q3. How important is Retrospective in life? <\/strong><\/p>\n 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. <\/span><\/p>\n An <\/span>agile retrospective<\/span><\/a>, 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 \u201cinspect\u201d how the iteration (sprint) has been done, and decide what and how they want to \u201cadapt\u201d their processes to improve. \u00a0The 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.<\/span><\/p>\n 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.<\/span><\/p>\n Q4. What can make an Agile Transformation a failure? How can we prevent it?<\/strong><\/p>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n Second, don\u2019t think about agile as something that will cost you money. Instead focus on the value that you can get. \u00a0Think 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.<\/span><\/p>\n 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 <\/span>Agile Self-Assessment Game<\/span><\/a> to find out how agile you are and how to increase your agility.<\/span><\/p>\n Q5. When do you realize that a person is not a team player?<\/strong><\/p>\n 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\u2019s a problem. If you don\u2019t see this happening, then your team is probably in trouble.<\/span><\/p>\n Q6. What do you wish for the Agile Community?<\/strong><\/p>\n Ben: My wish is that the agile community adopts a mindset of sustainable improvement. Agile is about \u201cfinding better ways\u201d, learnings what works and what doesn\u2019t. It\u2019s not a process that you can roll out and implement, let\u2019s stop wasting time on that.<\/span><\/p>\n Q7. Final words for our readers\u2026<\/strong><\/p>\n Ben: I\u2019m sharing my experiences (and those of others) on my blog <\/span>benlinders.com<\/span><\/a>. And I like to hear your experiences with agile, what worked for you and what didn\u2019t. Always eager to learn.<\/span><\/p>\n <\/p>\n <\/p>\n Ben Linders\u00a0is an Independent Consultant in Agile, Lean, Quality and Continuous Improvement, based in The Netherlands. Author of\u00a0Getting Value out of Agile Retrospectives<\/a>,\u00a0Waardevolle Agile Retrospectives<\/a>,\u00a0What Drives Quality<\/a>\u00a0and Continuous Improvement<\/a>. Creator of the Agile Self-assessment Game<\/a>.<\/p>\n![\"\"](\"https:\/\/i0.wp.com\/innoroo.com\/blog\/wp-content\/uploads\/2017\/07\/Ben-Linders-287-X-300.png?resize=150%2C150\")
<\/p>\n