Skip to content

Blogs

Chapter on Visual Management added to What Drives Quality

Ben Linders - Wed, 08/10/2016 - 09:30

What Drive Quality coverA new chapter which explores how visual management can be used to improve quality of software products has been added to my second book What Drives Quality.

One of the principles from agile and lean software development is transparency. Making things visible helps teams to decide what to develop and to collaborate effectively with their stakeholders. It can also help to increase the quality of software. You can apply visual management to make potential quality issues visible early and prioritize solving them. The examples that I provide explain clearly why quality matters and how visualization can be used to establish, maintain and even increase the quality of software products.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

What drives quality provides insight into the factors that drive the quality software products and services. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.

The book What Drives Quality is available for a reduced price on Leanpub as long as it’s under development. If you buy the book now you will automatically get all chapters that are added in the future for free. So don’t wait too long, get your copy now!

Categories: Blogs

Why do you want to become agile?

Ben Linders - Mon, 08/08/2016 - 13:16

Why becoming agileBecoming agile can help to achieve organizational goals. But setting agile as a goal for an organization does not work. The goal for a software organization should be to achieve results by delivering valuable products and services, not to become agile. Hence my question: do you know why do you want to become agile?
Yes, seriously, why would you do agile? There are lot’s of good reasons (and also some less good ones), but what’s your reason to become agile? What do you expect from agile?

Agile transformations seriously impact organizations (they should!). It’s a reorganization of people, work, and authorities. Employees are asked to think about the way they want to do their work, and to take responsibility. Managers have to give room to their employees. There must be a good reason to do all of this. You should know the reason why you want to become agile, and let everyone involved know.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

It is important to know why you want to increase the agility of your organization and what you expect to achieve with agile. To know why would you want to work in an agile way, why you want your culture to become agile.

Again, agile is not an goal or state that needs to be reached. It’s important that every manager and employee knows why the organization starts an agile journey and what is expected from agile. Reasons to become agile

If I ask people in organizations that I work with why they want to become agile they often look surprised at first. Of course they want agile! Everybody is doing agile, so it must be good. Agile is supposed to make them faster, cheaper and better. So let’s do it. If it only was that easy … every organization should be truly agile by now.

Does knowing the reason matter? Yes, it does! If you know the reason why you want to become agile, chances of success increase significantly. If people know why they have to chance, if they see the purpose, they are more willing to do it.

Some of the reasons that I have heard in organizations on why they want to become agile are:

  • Deliver the right products and services
  • Be able to deliver faster
  • Increase customer satisfaction and win new customers
  • Create innovative products with motivated employees
  • Reduce the cost of development and management
  • Improve the quality of goods and services
  • Effective cooperation between development and management
  • (your reason here)

My advice to companies is to think about why they want to become agile. Pick one reason, and one only. State very clearly in one sentence what your main objective to become agile. What would make your agile transformation successful. Going for one goal is hard enough. Also, the reason you choose impacts the way that agile will be applied (it should!), so choose your reason carefully. What is your goal with agile?

Do you want to deliver products with good quality? Or be able to better meet the needs of your customers? Lower your costs? Increase the motivation of your employees? Whatever your reason is to become agile, contact me, and I’ll help you to get results :-).

Categories: Blogs

Books by Ben Linders on Leanpub

Ben Linders - Mon, 08/08/2016 - 11:07

Books Ben Linders LeanpubAll of the books that I have published on Leanpub are now available in a bundle: Books by Ben Linders. You get a 30% discount when you buy my books with this bundle.

Currently this bundle contains three books:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.

My book What Drives Quality helps you to prevent software problems from happening by building an shared understanding what drives software quality. It enables you to effectively take actions, saving time and money!

My book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.

My 2nd and 3rd book are being written incrementally. Currently they are only sold via Leanpub. When you buy the book on Leanpub you will automatically receive new chapters when they become available, free of charge.

All books that I will publish in the future on leanpub will be added to this bundle.

Categories: Blogs

Masterclasses at Agile Tour Kaunas

Ben Linders - Mon, 08/01/2016 - 18:49

agiletour2016kaunas I’m giving two masterclasses at Agile Tour Kaunas on October 11 and 12 on Retrospectives and on Agile and Lean. Tickets for these agile workshops can be bought on the Agile Tour Lithuania courses webpage.

The two masterclasses are:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

This is the first time that I’m giving my workshops in Lithuania. I’m grateful to Agile Lithuania for inviting me to their country.

The early bird price (till September 1st) for my masterclasses is 319 Eur (VAT not applicable). Regular price: is 379 Eur.

As an adviser, coach and trainer I helps organizations by deploying effective software development and management practices. I provide workshops and training sessions, public and private sessions. Here’s a list of my upcoming public sessions.

Categories: Blogs

A Summary of More Fearless Change in 15 Tweets

Ben Linders - Fri, 07/29/2016 - 11:58

More Fearless Change book coverThe book More Fearless Change by Mary Lynn Manns and Linda Rising provides ideas for driving change in organizations, using the format of patterns. This book is an new and extended version of their successful book Fearless Change.

I did an interview with Mary Lynn and Linda about how people are viewing change in organizations, the purpose of patterns and the benefits that organizations can get from using them, the new patterns that are described in More Fearless Change and the insights were added to the existing patterns, and their expectations about what the future will bring us in organizational change. You can read it on InfoQ: Q&A on the Book More Fearless Change. 15 Quotes from More Fearless Change


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Here’s a set of 15 quotes from the new patterns that have been added in More Fearless Change. I’m tweeting these quotes with #fearlesschange: No matter how great your new idea is and how well prepared you are, you are bound to meet some level of resistance Inspire people throughout the change initiative with a sense of optimism rather than fear When you feel discouraged, look for the bright spots among the challenges that surround you Displaying a warm smile and a willingness to be nice even when negativity surrounds you can go a long way To make progress toward your goal, state precisely what you will do as you take the next baby step To encourage adoption of a new idea, experiment with removing obstacles that might be standing in the way Change the environment in a way that will encourage people to adopt the new idea When you have a chance to introduce someone to your idea, you don’t want to stumble around for the right words to say Persuasion tactics must consider what people are logically thinking as well as what they are feeling By focusing on the future, individuals may be more motivated to let go of the past Your change initiative is a series of baby steps As you prepare to move forward, occasionally look for a quick and easy win that will have visible impact Stay in touch with your supporters—never assume that news of your progress is known across the organization Rumors need to be debunked before they take root and create significant concerns and anxieties during the change You can’t spend time and energy addressing every bit of resistance you meet Patterns can help you to drive change

If you want to truly change organizations, don’t try to plan it up front and don’t look for recipes. That won’t work (literally!). Patterns provide a useful format to convey ideas and to apply those ideas in a specific situation to do sustainable change.

Mary Lynn Manns and Linda Rising did a great job in this updated and extended version of Fearless Change. The experiences that they added to the existing patterns help you to get a deeper understanding, and the new patterns that they describe in this book are very valuable.

The patterns described in More Fearless Change help you to recognize situations and to come up with solutions for dealing with them. If you are dealing with change in organizations (and who isn’t nowadays) then I highly recommend to read this book and keep it close to you, as it will be useful at many times!

Categories: Blogs

Books with Agile Practices and Tips

Ben Linders - Thu, 07/28/2016 - 09:54

Agile Practices and Tips Books BundleA new bundle of books with agile practices and tips has been released on Leanpub. Buy these books with a 40% discount!

The bundle includes six great books from eleven authors, helping you to make your agile journey easier to travel, more successful, and fun!

  • With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.
  • A Toolbox for the Agile Coach:  96 Visualization Examples showing how great teams visualize their work.
  • The tools and techniques provided in the Forming Agile Teams workbook offer an alternative-proven way to add more structure, transparency and visibility to the work that you do when Forming Agile Teams, by combining visual explanations with techniques and tips to support Scrum Masters crucial role within the organization.
  • The Scrum Master Workbook Part 1 provides 15 weeks of accelerated learning. It teaches you ways to deal with conflict, bugs, interruptions, meetings and many more topics.
  • Patterns of Agile Journeys shares stories and patterns to help you recognize situations you may find yourself in on your own journey. Use the tips in this book to reinforce or counteract the patterns you see.
  • The book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Together these books provide many useful tips and practices for your agile journey. Buy them for $40,77 (regular price is $67,95).

There’s also the Agile Retrospectives Books Bundle with six great books that will make your agile retrospectives rock, and the Valuable Agile Retrospectives – All Languages Bundle which contains all language editions of my successful book Getting Value out of Agile Retrospectives.

Categories: Blogs

Manifesto voor Agile Veranderen

Ben Linders - Tue, 07/26/2016 - 10:47

Manifesto Agile Veranderen Ben LindersHet manifesto voor agile veranderen helpt organisaties om hun agility te verhogen. Het zorgt voor blijvende verbetering van de resultaten, tevreden klanten, en blije medewerkers. Dit eerste artikel over Agile Veranderen beschijft de uitgangspunten en waarden met behulp van het manifesto voor agile veranderen.

Agile software ontwikkeling is gebaseerd op het Manifesto voor Agile Software Ontwikkeling. Dit manifesto bevat vier waarden en twaalf principes. Het manifesto voor agile veranderen is op een zelfde manier opgebouwd. Het beschrijft mijn visie en werkwijze in organisatieverandering, samengevat in vier waarden. Mijn verander “waarden”


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

Dit zijn de waarden van mijn Manifesto voor Agile Veranderen:

  • Betrekken van professionals en ruimte geven voor ideeën over standaardisatie en voorschrijven van werkprocessen
  • Stapsgewijze evolutionaire verbetering van binnen uit over top down opleggen van veranderingen.
  • Resultaatgericht en intensief samenwerken over directieve doelen met “command & control” management.
  • Prioritiseren en flexibel inspelen op kansen over budgetteren en veranderplannen uitvoeren.

De waarden aan de rechterkant van bovenstaande statements zijn en blijven belangrijk, maar ik geef graag meer aandacht aan de waarden aan de linkerkant. Daarom geef ik bijvoorbeeld de voorkeur aan het in kaart brengen van de bestaande werkprocessen met de medewerkers en samen werken aan verbetering mbv retrospectives in plaats van organisatiebreede uitrol van Scrum met standaard trainingen. En werk ik liever met een veranderbacklog waarin de prioriteiten eenvoudig aan te passen zijn dan met een plan. Ook veranderen veranderd

Anders dan het Agile Manifesto wat al 15 jaar hetzelfde is verwacht ik dat dit manifesto wel zal veranderen. De eerste evolutie is al te zien als je het vergelijkt met het verander manifesto van veranderproject, een samenwerkingsverband van enkele jaren geleden. Bijvoorbeeld woorden als “verbinden” zijn verder uitgewerkt in “resultaatgericht en intensief samenwerken” en het manifesto voor agile veranderen benoemd de rol van de professional en een bottom up aanpak voor verandering.

In de nabije toekomst zal ik diverse artikelen publiceren waarin ik dieper in ga op de waarden van dit manifesto. Ik geef daarin o.a. voorbeelden van betrekken van professionals in verandertrajecten, top-down versus bottom up veranderen, evolutionaire versus revolutionaire verandering en resultaatgericht veranderen.

Categories: Blogs

All languages bundle for Valuable Agile Retrospectives

Ben Linders - Thu, 07/07/2016 - 16:00

Valuable agile retrospectives - all languages bundleThe successful book Getting Value out of Agile Retrospectives has been translated in many languages. The leanpub bundle Valuable Agile Retrospectives – All Languages contains all language editions, you can get 9 books for the reduced price of $24,99 (excluding VAT).

People from all over the world approach us for translating our book into their native language. We love to work together with local agile communities and agile practitioners to make our book available in their local language.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

The normal price for the 9 books is $89,91, together these books are now available for the price of $24,99, a discount of more that 70%. When you buy the bundle you will get all translations that are released in the future for free. With this bundle you will always have the latest version of our book in every language.

Our mission is to help many teams all around the world to get more value out of agile retrospectives.

At this moment out book is available in these languages on leanpub:
[Nederlands]  [Español]  [Francais]  [Japanese]  [Italiano]  [Chinese]  [русский]  [Polish]

You can buy all local language editions of Getting Value out of Agile Retrospectives at Amazon.com (and all other Amazon shops), LeanpubiTunesSmashwordsLuluBarnes & NobleKoboScribd, Oyster and Blio. Paperback editions can be bought in my webshop and on bol.com and Managementbook.nl.

Categories: Blogs

The paradox of plenty

Indefinite Articles - John Brothers - Wed, 05/04/2016 - 18:07

My customer’s coffee area used to have three urns for coffee.   The standard practice was to make a new pot if you used up the last in the current pot.

The pots were big, holding probably between 10 and 15 normal cups-sizes worth of coffee.     Unsurprisingly, I had to make coffee about once every 10-15 days.

 

More recently, there was a change to the coffee room.  Now there are six urns – two for each of the three flavors (Dark roast, regular, decaf).

Now, I make coffee almost every day.    Because when I come in, one of the two dark-roast urns is empty, and the other is half empty.  And I feel obliged to make more, since one is empty.

 

Basically, the coffee room has turned into a big conscientiousness test..  I think I’m passing.

Categories: Blogs

Coherence Busting explained

Thought Nursery - Jeffrey Fredrick - Fri, 04/08/2016 - 19:59

In Action Science workshops I teach a technique I call Coherence Busting. To understand why it is useful I ask the audience to imagine themselves making a proposal: “While you are talking you notice the main stakeholder — the person in the audience you most hope to persuade — glance at their watch. What do you do?”

I ask this question to allow the audience to experience the decision-making heuristics that Daniel Kahneman describes in this book Thinking, Fast & Slow. Kahneman models our consciousness as being two systems, our fast, automatic, unconscious System 1 and our slow, deliberate, effortful System 2. Part of what makes System 1 fast are the shortcuts it uses. Two of these shortcuts consistently arise with the watch example. The first is that we  assume that a coherent story must be correct. The second is that we limit the facts to what we can immediately recall, a process Kahneman calls What You See Is All There Is (WYSIATI).

These two shortcuts are displayed in the watch scenario.

We unconsciously construct a coherent story for what the glance means — for instance “she has somewhere else to go”. This story is based on first thoughts of what the glance might mean (WYSIATI). The coherence in our story give us the sense that our story is true. We then design our actions in response to a story we made up. This is the key lesson of the watch example: We feel as though we are responding to the reality of the situation, because WYSIATI and coherence cause us to mistake our single plausible story for the truth.

This is why we need Coherence Busting.

With the watch example, I ask the audience to describe what they think the glance means. After I have harvested the normal stories from the audience (“they’re bored”, “their attention has drifted”, “they are running short of time”) I ask them to consider other possible meanings of the glance, all of the possible reasons, even wildly implausible ones (“they have their plan for world domination written on their hand”). Now the audience generates dozens of possible reasons: it is a nervous habit, they were admiring their new watch, there could have been an alert on a smartwatch, maybe an itch on their wrist, and lots more. What makes this Coherence Busting is not just that there are lots of options but that the options are mutually incompatible. Once we can imagine conflicting explanations we are not longer trapped by the original coherent story. These options were always there, but it requires invoking System 2, our conscious and effortful thought process, to bring them to the surface. That’s not something we do when we feel we already have a good explanation. So what would trigger us to use Coherence Busting?

I’ve found Coherence Busting a useful tool to reach for when I recognize that I’m frustrated. A common pattern for me is to get frustrated when I can’t come up with a justifiable explanation for the other person’s actions, when I don’t like the explanation that System 1 has suggested for me. When I recognize that pattern I try and think of at least three incompatible motivations for why they might be behaving the way they are. The technique of Coherence Busting is a way of reminding myself that there are infinitely more possibilities than I have considered. It allows me to let go of the story I’ve made up about the other person. It reminds me that if I want to understand what the other person is thinking, I’m going to have to get out of my head and into theirs — probably starting with asking them a genuine question about what they are thinking.

Much of my work with Action Science is learning the skill of asking good questions. Coherence Busting reminds me to use those skills.

(Thanks to Douglas Squirrel for helping develop Coherence Busting. See more of our work together at ActionScienceConversations.com and the London Action Science Meetup.)

Categories: Blogs

And we’re also back

Indefinite Articles - John Brothers - Tue, 03/15/2016 - 23:11

Just like what happened on www.picobusiness.com, this wordpress site was compromised.  And I was able to restore this one in about 5 minutes, which is pretty cool.  The old style wasn’t available anymore.  Which might be a blessing 🙂

Categories: Blogs

They're going to hate you anyway

Doc On Dev - Michael Norton - Wed, 02/17/2016 - 23:30
I read an article today that was posted on LinkedIn. I'm not going to link to the article. I'm not going to tell you who wrote it. I am only telling you about the article to set the stage for what I want to write about in this quick post.

In the article, along with "taking the best from Waterfall and Agile" and mixing them together into a "perfect methodology", the author, as a self-proclaimed change agent, suggested you should force implement all CMMI Level 5 developer practices at once. Can someone point me to the list of CMMI Level 5 Developer Practices? I looked for it, but couldn't find it. Perhaps there is a walled garden somewhere with this information tucked away therein? I may be mistaken, but I believe the CMMI practices are about tracking and improving the overall process, NOT about hands-on-keys activities or anything of the sort.

But let's pretend there is a prescribed list of development practices that are classified at CMMI Level 5 so that we may continue with the discussion. The author's reasoning for forcing a list of "best practices" on the team all at once is that "They're going to hate you anyway for changing things." You might as well change everything at once and get some good results fast.
What the what?If your change management plan is to force "best practices" on people without any thought for where they are today, it's no wonder they hate you. It doesn't matter if you force one poorly chosen and misunderstood practice on them or 100. You're creating a hostile environment. You are forcing people to adopt practices they are likely not familiar with. And these practices likely don't yet fit into their overall approach to work. They probably don't even fit into the common mental model for these people.

You're actually going to make things worse for everyone. This isn't about them not being able to accept change. This is about you not taking responsibility for having no idea how to implement a change.
Meet them where they are and lead them to a better place.Organizational change usually starts slowly and builds momentum with success. I don't care if Ward Cunningham himself wrote the list of developer "best practices", you don't shock and awe anyone with them if you want to be successful.

Listen and observe. Open your mind. Look at them not from the perspective of, "Here's what you should be doing, but aren't", look at them from the perspective of, "I'd really like to understand why you do things the way you do and the benefit you gain from it."

Find something they WANT to change. Something that is causing them pain. Help them come up with something different they could try. Maybe you think they should pair program 100% of the time (presumably because it is a "best practice" [gross]). It's possible a good first step is to start talking about shared code and our agreed standards. Maybe they won't ever get to pairing. But if they get better at the things pairing helps with, isn't that pretty great?
Categories: Blogs

Leadership Teams may be a smell

Doc On Dev - Michael Norton - Mon, 02/08/2016 - 03:04
Some time in mid-January, I was thinking about various organizational patterns and how companies run. I was thinking, in particular, about the idea of a "leadership team". I dropped a thought into Hootsuite and a couple of weeks later, on February 6, that thought was broadcast over a few social media channels.
The more I ponder it, the more I'm convinced that the existence of a "leadership team" is an indication of dysfunction.— Michael (Doc) Norton (@DocOnDev) February 6, 2016 I got a few different responses, all of which amounted to "please say more about this." I want to make it clear that this is a thing I am still pondering and a lot of this post is ideas I've not shared broadly or discussed at length.

Right now, I think of a leadership team as an organizational smell. Like a code smell, an organizational smell potentially indicates a deeper problem in the system. The smell itself, in this case the existence of a leadership team, is not technically a problem. A leadership team doesn't prevent an organization from functioning. But the existence of a leadership team may indicate perceived weaknesses in the overall system. Maybe we're attempting to compensate for these weaknesses by centralizing authority and decision making.

Maybe we see no weaknesses and we can easily rationalize this centralization. After all, the members of a leadership team are nearly always the individuals at the top of the organizational chart. In such a case, we may be rationalizing the existence of a smell with a misapplied organizational design pattern.

Like software design patterns, I think of organizational design patterns as not final repeatable prescriptions, but templates. Dominator hierarchy is an organizational design pattern optimal for repeatable work. With a dominator hierarchy, there is a static pyramidal structure with a clear chain of command, decisions are made at the top and people identify with specific job titles within the hierarchy. This is the right organizational pattern for what Professor David J. Snowden refers to as the chaotic and obvious domains in the Cynefin framework. While dominator hierarchy works in both of these domains, the optimal management styles differ from command to coordination for chaotic and obvious, respectively.

For the complicated domain, the Supportive Hierarchy is an appropriate organizational design pattern. In the Supportive Hierarchy, the reporting structures are similar to dominator hierarchy, but there is an emphasis is on empowering employees. Management style moves from being controller and coordinator, to mentor. Employees have more freedom. Decision making protocols are in place, allowing employees high levels of autonomy. Servant leadership is another common and effective management style here.

Implementing a hierarchy in the complex domain is not technically a problem as it doesn't stop the organization from functioning. But hierarchy of any form is a suboptimal structure for an organization that needs to respond quickly to unpredictable changes in the market. For the complex domain, the optimal organizational design pattern is a Decentralized Network and the management style is facilitative, but the roles associated with management in the hierarchy patterns disappear. In a Decentralized Network there are no managers, directors, VPs, or SVPs. You commonly won't even find executive roles beyond those required by law. The decision making protocols used in Supportive Hierarchy are made more robust to account for all decision making, including governance decisions.

Product development in its true form falls into the complex domain. If you know precisely what you are building and how the market will respond to it, you are not developing product, you are building it. In such a case you are either square in the complicated domain or your hubris has gotten the better of you. I suspect the latter, but I suppose that's another blog post.


Let's see if we can wrap this up and attempt to clarify why a "Leadership Team" is likely an indication of dysfunction.
With Dominator Hierarchy and command management style (Chaotic), a leadership team would slow down decisions and speed is paramount to getting out of chaos, which is the primary goal of leadership when in chaos.

With Supportive Hierarchy, mentor management style, and decision making protocols, the centralization of decision-making is not necessary. A leadership team is likely an indication of failure elsewhere in the decision making process.

With Decentralized Network and facilitative management style, and robust decision making protocols (Complex), a leadership team makes no sense. There is no hierarchy of titles. Everyone is a decision maker.
A leadership team makes sense is if you have a dominator hierarchy with coordination management style (Obvious). Decisions are made at upper levels of the hierarchy and we are not in chaos, so the small amount of extra time a leadership team would take to coordinate and make a decision is a worthwhile trade-off for the increased average in value of said decisions.


So if your local fast food chain has a leadership team, that makes sense. If their headquarters has one, however, it suggests they fail to recognize the complicated or complex nature of the work they do. The leadership team is an indication they are operating under a suboptimal organizational design pattern and/or management style with insufficient decision making protocols. In other words, the existence of a leadership team at headquarters is a smell.

Categories: Blogs

Impressions of #Stretchcon

Complex and Agile - Joseph Pelrine - Tue, 12/15/2015 - 14:14

It’s been a long time since I’ve felt so moved by a conference that I felt I needed to blog about it, but it happened last week at the Stretch conference in Budapest. It’s not that the other conferences I attended recently weren’t also good – both Decepticon in Cambridge, organised by Sophie van der Zee et al., and Agile Tour Vienna, organised by Christian Hassa, Ralph Miarka et al., were excellent conferences. Stretch, though, was something different. It might be because I’ve gotten so used to attending software and psychology conferences that a leadership and management conference was a refreshing change.

Stretch is an annual conference in Budapest organised by Prezi, UStream, and others. For me, it felt like a smaller, more intimate version of TED. The speaker mix was typical – fly over some American big names, find a few interesting Europeans, and fill with local talent. I was invited by László Csereklei, who I met a few years back after a talk I gave at Ericsson. I wasn’t sure how I would fit in to such a conference, and was worried up until the point I went up on stage. As it was, things turned out quite well.

Stretch was held in the Urania theatre in Budapest, a beautiful building with gold and red velvet reminding one of the last age of the Austrian-Hungarian monarchy, and was structured as a number of presentations with an open space in the middle. Talks were limited to 40 minutes (more or less), with a 5-minute Q&A session afterwards. As the theatre seating was quite narrow, passing around microphones for questions from the audience would have very difficult to deal with. As it was, things went very well, as the conference organisers used what is one of the coolest software apps I have seen recently, Sli.do (http://www.sli.do). This web app allows people to log into the conference site via hashtag, post questions, and allows others to upvote the questions. I don’t know how long it’s been around, but I hope to see it used more often, especially since it’s also valuable for avoiding the creeping-death start of large open space sessions.

Speakers

Due to prior commitments, I only arrived in Budapest on the evening of the first day, and since I had to fly back home to Switzerland after lunch on the third and last day, I didn’t catch all speakers. There were a few of them, though, who moved and impressed me.

Doc Norton gave a talk entitled “The Experimentation Mindset”, in which he showed that there needs to be space and willingness for people to try things out, at the risk of failure, for any real innovation to occur. Although his focus came from a different direction, his ideas resonated so well with my complexity-based thoughts that I constantly felt like I needed to put up my hand, either to add a thought or to high-five him.

When I read the title of John Blakey’s talk – “The Trusted Executive” – I thought it was an oxymoron. This was the focus of his heavily “Matrix”-based talk – what is trust, and how can it be earned. His main point was that, in order to be trusted, you have to be trustworthy. How to do that? According to John, trustworthiness = deliver + coach + be consistent + be honest + be open + be humble + be kind + be brave + evangelise. I strongly agree with, and I will try to be, one of a new breed of  leaders, ones who prefer the power of trust to the trust in power.

Anne Loehr’s talk went in a similar direction. Although advertised as discussing focus and purpose, her main focus was on values. This fit in nicely with John Blakely’s emphasis on integrity, and was very useful to me. I’m currently in the process of looking for new challenges and re-positioning myself in the market, and had the chance to talk a bit one-on-one with Anne after her talk. Her personal question to me to not ask “what do I want to do”, but ask “what do I value”, has been occupying many brain cycles since then. Thanks, Anne!

Holacracy

Someone in the organising committee must be a fan of Holacracy, since there were (in my opinion) too many talks about it at Stretch. As preparation for the conference, I read Laloux’s book, needing a bit more time than Dave Snowden’s one hour (I needed two, but I was multi-tasking), and studying various materials available on the web. My opinion, which was confirmed by the talks I heard: from a scientific point of view, Holacracy has very little to do with complexity and self-organisation. It is a process and toolset (think Agile Manifesto here), an ordered-systems approach that attempts to impose on an organisation a structure that might potentially emerge in a socially complex system. It borrows terminology from complexity without really understanding what the terms mean. Holacracy might work in some situations – there was a talk from someone using it in a school in Berlin – but it’s not something I would want to have to deal with.

Other things

Many years ago, when I first met Martin Haussmann and introduced his style of visual facilitation to the agile community, I never could have imagined how popular it would become. One of the highlights of Stretch was the excellent live graphic recording of the talks. I was presented with a sketch of myself and with 2 full pages of drawings from my talk, and am happy and proud to have them now hanging in my office.

Finally, I’d like to thank a few people who made my time at Stretch very special. István Tóbiás, who organised everything having to do with my talk. Anna Budai, who took good care of me during my time in Budapest, and was an excellent conversational partner.  And last but not least, Medea Baccifava. After my talk, I mentioned to her that I liked the conference a lot, and would love to come speak again some time. 10 minutes later, she came back smiling and told me “We just freed up 30 minutes in the afternoon. Could you speak some more?” I will never forget that.

Categories: Blogs

Call for sessions XP Days Benelux 2015

xpdayslogo-webXP Days Benelux is an international conference where we learn to bring software to life and grow mature systems that support business needs.

It provides an excellent environment for exchanging ideas, hands-on exercises and extreme experiences.

What are we looking for?

wordle-xpdays7

What are you looking for? What would make it a WOW session for you and our participants?

We’re interested in:

  • Experiences with new and old techniques. What worked; what didn’t? Why? What have you learned?
  • Unexpected ideas from other disciplines and sciences. How can we cross borders? What lessons have we missed? How can we collaborate better with people from other disciplines and departments?
  • Ask for help from other participants. What scary problems confront you and your team?
  • People from outside IT with an interesting story. What can we learn from their experience?
  • Pushing the limits of techniques and organisations, doing the “impossible”. How far can you go if you challenge commonly accepted assumptions?
  • Back to basics. What happens if we really take the Extreme Programming values of Simplicity, Commmunication, Feedback, Courage and Respectseriously?
  • Taking back agile. What does “agile” really mean to you and why is it important?
  • Questioning agile. Where, when and why would you not use agile methods? Why? What can we learn about context and applicability?

The XP Days community loves highly interactive sessions where everyone participates and learns from each other.

During review and selection, your session will receive bonus points when…
  • … you have no slides. Think outside the box and sharpen your story telling skills.
  • … it appeals to both technical and functional people. Involve the geeks, challenge the managers.
  • … it has the “XP Factor”. Is it entertaining and crazy? Does it take people out of their comfort zone?
  • … you’ve had a dry run. Did you join one of our try-outs? Did you send a video introduction?
  • … your subject is fresh and original. Maybe something outside the domain of IT?
  • … it has an original format. Doing something with fruit? Are there any sports involved? Great!
  • … your session poses a question instead of giving an answer.
  • … if you’re new to presenting at XP Days. First timers receive a warm welcome…
How does it work?

You propose your idea for a session: a title and a short description.From then on, organizers and session proposers work together to refine and improve your proposal, adding more information and improving the description and session content. We’ll give feedback and provide opportunities for try-outs. In return, we expect from you that you help others to turn their idea into a WOW session.

Yes but, I haven’t presented at a conference before.

You don’t need to be an experienced presenter, you “just” need one good idea or question to start with. And then you iterate and improve your idea with the help of the other presenters and the organizers.

We offer coaching for first-time presenters. Contact sessions if you want help proposing and refining your session.

Submit your proposal now. You have until July 5th 2015 to propose your idea. The sooner you send in your idea, the more feedback you will receive.

Categories: Blogs

Call for sessions Agile Tour Brussels 2015

15582616299_95287f7324_z

Agile Tour Brussels is calling for speakers!

Agile Tour Brussels is one of the biggest agile conferences in Belgium. Last year we gathered 250 attendees and speakers from Belgium, France, U.S, U.K, Luxemburg, Netherlands and Sweden to share our passion for Agile. The purpose of this conference is to gather in one place Agile practitioners and people wanting to know more about Agile.

At Agile Tour Brussels you will meet a mix of attendees who are either completely new to Agile, experienced or experts.

This year we’re going to have different tracks, and for each of these we’re looking for two kind of sessions: Interactive Talk (Presenter is speaking for most of the time with audience interaction) or Workshop (Primarily focused on hands-on participation with the audience).

Track 1: Experience reports.

Tell us your success or failure stories about Implementing Agile in Belgium (or in Europe), What is (not) working for you? If you’re an agile coach or facilitator, bring your client with you!

Track 2: Pragmatic Track

We’re looking for small changes or fundamentals, pragmatic things that work. How do you gather requirements? How do you run an outstanding retrospective? In this track your participants will learn something they can apply the day after. It can be technical, soft-skills or a process you use.

Track 3: Let’s Play together

This Track is for Agile Games and Serious Games. It’s also the opportunity to suggest “BootCamp” sessions like Introduction to [put Agile method here] or how to estimate with Agile,…

Track 4: Agile Management

What’s the role of Managers in Agile? What’s an Agile Manager? What’s an Agile organization? This track will cover subjects such as Management 3.0, Flat organizations, Evidence Based Management,…

Track 5: Various

Do you have a favourite subject you’d like to talk about, a kick-ass workshop you’d like to run, a theme you’d like to share? This track is for you!

All Agile methods are welcome: Scrum, XP, KanBan, Lean, Devops, Leadership, Lean Startup, Coaching, System thinking, Product Aspect, Agile outside IT.

We are looking for different levels of sessions: for beginners, practitioners and experts. We welcome experienced as well as new speakers.

How to submit a session?

To submit a session, fill in the form located here: http://at2015.agiletour.org/fr/callForSpeaker.html

(you can log into the website with your existing account or create a new one).

Tips for a successful submission:

  • Don’t forget to specify that you’re applying for Agile Tour Belgium – Brussels
  • Make sure you’re in the call for speaker of Agile Tour 2015 (links to the previous editions could still be active in the platform)
  • Specify the size of the audience you’d like to have for your session
  • Sessions must be in English
  • We would prefer to have session of 1 hour maximum
  • Deadline for submission: 10th of July 2014

All information about the event will be published on http://www.atbru.be

If you cannot make it, you can still support us by tweeting about #atbru, blogging, speaking about our event.

Categories: Blogs

Major SAFe LSE Update with Big Implications

Hello Folks,

As you probably know, I’ve moved most of my blogging activity to the Scaled Agile Framework Blog. For a major update on SAFe LSE and the future of SAFe, check out this post.

I’ll be maintaining this blog for just a while longer. As the SAFe blog is dedicated to SAFe content, I plan to start my personal blogging again on my website at deanleffingwell.com. I’ll be describing a few other topics I’ve been researching lately, and some great books and background reading, all of which is too early for SAFe.

–Dean

Categories: Blogs

I Prefer This Over That

A couple weeks ago I tweeted:

I prefer: - Recovery over Perfection - Predictability over Commitment - Safety Nets over Change Control - Collaboration over Handoffs

— ElisabethHendrickson (@testobsessed) May 6, 2015

Apparently it resonated. I think that’s more retweets than anything else original I’ve said on Twitter in my seven years on the platform. (SEVEN years? Holy snack-sized sound bytes! But I digress.)

@jonathandart said, “I would love to read a fleshed out version of that tweet.”

OK, here you go.

First, a little background. Since I worked on Cloud Foundry at Pivotal for a couple years, I’ve been living the DevOps life. My days were filled with zero-downtime deployments, monitoring, configuration as code, and a deep antipathy for snowflakes. We honed our practices around deployment checklists, incident response, and no-blame post mortems.

It is within that context that I came to appreciate these four simple statements.

Recovery over Perfection

Something will go wrong. Software might behave differently with real production data or traffic than you could possibly have imagined. AWS could have an outage. Humans, being fallible, might publish secret credentials in public places. A new security vulnerability may come to light (oh hai, Heartbleed).

If we aim for perfection, we’ll be too afraid to deploy. We’ll delay deploying while we attempt to test all the things (and fail anyway because ‘all the things’ is an infinite set). Lowering the frequency with which we deploy in order to attempt perfection will ironically increase the odds of failure: we’ll have fewer turns of the crank and thus fewer opportunities to learn, so we’ll be even farther from perfect.

Perfect is indeed the enemy of good. Striving for perfection creates brittle systems.

So rather than strive for perfection, I prefer to have a Plan B. What happens if the deployment fails? Make sure we can roll back. What happens if the software exhibits bad behavior? Make sure we can update it quickly.

Predictability over Commitment

Surely you have seen at least one case where estimates were interpreted as a commitment, and a team was then pressured to deliver a fixed scope in fixed time.

Some even think such commitments light a fire under the team. They give everyone something to strive for.

It’s a trap.

Any interesting, innovative, and even slightly complex development effort will encounter unforeseen obstacles. Surprises will crop up that affect our ability to deliver. If those surprises threaten our ability to meet our commitments, we have to make painful tradeoffs: Do we live up to our commitment and sacrifice something else, like quality? Or do we break our commitment? The very notion of commitment means we probably take the tradeoff. We made a commitment, after all. Broken commitments are a sign of failure.

Commitment thus trumps sustainability. It leads to mounting technical debt. Some number of years later find themselves constantly firefighting and unable to make any progress.

The real problem with commitments is that they suggest that achieving a given goal is more important than positioning ourselves for ongoing success. It is not enough to deliver on this one thing. With each delivery, we need to improve our position to deliver in the future.

So rather than committing in the face of the unknown, I prefer to use historical information and systems that create visibility to predict outcomes. That means having a backlog that represents a single stream of work, and using velocity to enable us to predict when a given story will land. When we’re surprised by the need for additional work, we put that work in the backlog and see the implications. If we don’t like the result, we make an explicit decision to tradeoff scope and time instead of cutting corners to make a commitment.

Aiming for predictability instead of commitment allows us to adapt when we discover that our assumptions were not realistic. There is no failure, there is only learning.

Safety Nets over Change Control

If you want to prevent a given set of changes from breaking your system, you can either put in place practices to tightly control the nature of the changes, or you can make it safer to change things.

Controlling the changes typically means having mechanisms to accept or reject proposed changes: change control boards, review cycles, quality gates.

Such systems may be intended to mitigate risk, but they do so by making change more expensive. The people making changes have to navigate through the labyrinth of these control systems to deliver their work. More expensive change means less change means less risk. Unless the real risk to your business is a slogging pace of innovation in a rapidly changing market.

Thus rather than building up control systems that prevent change, I’d rather find ways to make change safe. One way is to ensure recoverability. Recovery over perfection, after all.

Fast feedback cycles make change safe too. So instead of a review board, I’d rather have CI to tell us when the system is violating expectations. And instead of a laborious code review process, I’d rather have a pair work with me in real time.

If you want to keep the status quo, change control is fine. But if you want to go fast, find ways to make change cheap and safe.

Collaboration over Handoffs

In traditional processes there are typically a variety of points where one group hands off work to another. Developers hand off to other developers, to QA for test, to Release Engineering to deliver, or to Ops to deploy. Such handoffs typically involve checklists and documentation.

But the written word cannot convey the richness of a conversation. Things will be missed. And then there will be a back and forth.

“You didn’t document foo.”
“Yes, we did. See section 3.5.1.”
“I read that. It doesn’t give me the information I need.”

The next thing you know it’s been 3 weeks and the project is stalled.

We imagine a proper handoff to be an efficient use of everyone’s time, but they’re risky. Too much can go wrong, and when it does progress stops.

Instead of throwing a set of deliverables at the next team down the line, bring people together. Embed testers in the development team. Have members of the development team rotate through Ops to help with deployment and operation for a period of time. It actually takes less time to work together than it does to create sufficient documentation to achieve a perfect handoff.

True Responsiveness over the Illusion of Control

Ultimately all these statements are about creating responsive systems.

When we design processes that attempt to corral reality into a neat little box, we set ourselves up for failure. Such systems are brittle. We may feel in control, but it’s an illusion. The real world is not constrained by our imagined boundaries. There are surprises just around the corner.

We can’t control the surprises. But we can be ready for them.

Categories: Blogs

Where Have I Been?

Oh, hai internets. It’s been a while. Did you miss me?

Let me tell you what I’ve been up to.

In the fall of 2012 I shut down my consulting practice (Quality Tree Software) and my studio (Agilistry), and took a job with Pivotal. Actually, to be precise, I joined Pivotal Labs; Pivotal did not even exist in 2012.

Pivotal came into existence in April 2013 as a spin out from EMC and VMWare. Labs is part of Pivotal, but we are more of a product company focused on cloud and data than a services company. We work on Cloud Foundry, an open source Platform-as-a-Service (PaaS), and have our own distribution as well as our hosted service. The other side of our business is data. Our Big Data Suite includes GPDB (an MPP database), HAWQ (SQL on Hadoop), and Gemfire (an in-memory data grid).

My role at Pivotal has evolved in the time I’ve been there.

For the first couple years, I was the Director of Quality Engineering on Cloud Foundry. It’s a title I swore I would never take again. But my job was different than you might imagine. I did not direct the efforts of quality engineers. Rather, I paid attention to our feedback cycles. Teams own their tests, their CI pipelines, and ultimately the quality of their deliverables. I just helped connect the dots. By the way, if you want to know more about quality and testing on Cloud Foundry, I did get out of the building long enough to give a talk on it at the Wikimedia Foundation. I also gave a talk on the Care and Feeding of Feedback cycles at DOES2014.

In the last few months I moved over to our Data organization in Palo Alto. This changed my commute substantially, so my family and I are moving this summer. That will be an adventure. We’ve been in the same house for 17 years. So wish me luck with that.

Along with the move to our data org, my title changed. We removed the word “quality” from it since what I do does not look anything like traditional quality engineering. So I’m now a director of engineering. But the work I do on a daily basis with our Data teams looks a lot like what I did with Cloud Foundry: I’m deeply involved in hiring, cross-team coordination, improving our release practices, improving builds and CI to make the developer workflow better, and coordinating with our product organization to make sure teams have a steady stream of high value work.

I’m also doing my best to climb the steep learning curve of MPP databases and Hadoop. It helps that I worked at Sybase once upon a time. But that was 20 years ago. So between the fact that I was doing very different work 20 years ago, I’ve forgotten much of what I learned, and things have changed a bit in 2 decades, my prior database experience is only helping me a little in understanding my new context.

I have to say that I love working at Pivotal. I adore the people, am fascinated by the products, and am passionate about the way we work. Coming back to Pivotal was like coming home. (After all, Pivotal Labs is where I learned Agile over a decade ago.)

Some of you have noted that I don’t get out much anymore. I’m not at conferences and I don’t travel much. Since I’m in an inward facing role it’s difficult for me to carve out time to get out into the community. I’d like to see my industry friends more often and I am always honored to be invited to speak. But I turn down the vast majority of speaking invitations. My job takes up all my available time and brain cells.

So that’s what I’m up to and why I’ve been silent here for so long. I do have things to say though. I’ve learned a lot in the last 30 months. And I’m learning more every day. So I hope to carve out time to share what I’m learning here. But no promises about when, exactly, I’ll post.

Categories: Blogs

Where Have I Been?

Oh, hai internets. It’s been a while. Did you miss me?

Let me tell you what I’ve been up to.

In the fall of 2012 I shut down my consulting practice (Quality Tree Software) and my studio (Agilistry), and took a job with Pivotal. Actually, to be precise, I joined Pivotal Labs; Pivotal did not even exist in 2012.

Pivotal came into existence in April 2013 as a spin out from EMC and VMWare. Labs is part of Pivotal, but we are more of a product company focused on cloud and data than a services company. We work on Cloud Foundry, an open source Platform-as-a-Service (PaaS), and have our own distribution as well as our hosted service. The other side of our business is data. Our Big Data Suite includes GPDB (an MPP database), HAWQ (SQL on Hadoop), and Gemfire (an in-memory data grid).

My role at Pivotal has evolved in the time I’ve been there.

For the first couple years, I was the Director of Quality Engineering on Cloud Foundry. It’s a title I swore I would never take again. But my job was different than you might imagine. I did not direct the efforts of quality engineers. Rather, I paid attention to our feedback cycles. Teams own their tests, their CI pipelines, and ultimately the quality of their deliverables. I just helped connect the dots. By the way, if you want to know more about quality and testing on Cloud Foundry, I did get out of the building long enough to give a talk on it at the Wikimedia Foundation. I also gave a talk on the Care and Feeding of Feedback cycles at DOES2014.

In the last few months I moved over to our Data organization in Palo Alto. This changed my commute substantially, so my family and I are moving this summer. That will be an adventure. We’ve been in the same house for 17 years. So wish me luck with that.

Along with the move to our data org, my title changed. We removed the word “quality” from it since what I do does not look anything like traditional quality engineering. So I’m now a director of engineering. But the work I do on a daily basis with our Data teams looks a lot like what I did with Cloud Foundry: I’m deeply involved in hiring, cross-team coordination, improving our release practices, improving builds and CI to make the developer workflow better, and coordinating with our product organization to make sure teams have a steady stream of high value work.

I’m also doing my best to climb the steep learning curve of MPP databases and Hadoop. It helps that I worked at Sybase once upon a time. But that was 20 years ago. So between the fact that I was doing very different work 20 years ago, I’ve forgotten much of what I learned, and things have changed a bit in 2 decades, my prior database experience is only helping me a little in understanding my new context.

I have to say that I love working at Pivotal. I adore the people, am fascinated by the products, and am passionate about the way we work. Coming back to Pivotal was like coming home. (After all, Pivotal Labs is where I learned Agile over a decade ago.)

Some of you have noted that I don’t get out much anymore. I’m not at conferences and I don’t travel much. Since I’m in an inward facing role it’s difficult for me to carve out time to get out into the community. I’d like to see my industry friends more often and I am always honored to be invited to speak. But I turn down the vast majority of speaking invitations. My job takes up all my available time and brain cells.

So that’s what I’m up to and why I’ve been silent here for so long. I do have things to say though. I’ve learned a lot in the last 30 months. And I’m learning more every day. So I hope to carve out time to share what I’m learning here. But no promises about when, exactly, I’ll post.

Categories: Blogs