SUGSA Workshop: No one is as smart as all of us

/by

Research shows that the characteristics of, and conditions for, good collaboration are the same whether it is a Scrum team in a bank needing to collaborate with another team working in a waterfall way or a bunch of medical professionals needing to collaborate in the treatment of a person. The “how” of collaboration is context specific and this is where the differences lie.

These are the topics of the workshop that will be facilitated by Regina Martins at the Scrum User Group South Africa (SUGSA) meeting later this week in Cape Town.

This session is an experiential exploration of this hypothesis with people working in small groups on a specific collaboration issue of their choosing. They will leave with a variety of possible new ways to improve or reboot collaboration in their context which they can apply the next day.

LeSS and DevOps

/by

Three-fourths of the companies surveyed in the 2017 State of Agile Report are either engaged in, or planning, a DevOps initiative. And why not? Who wouldn’t want their teams’ work released as quickly and easily as possible.

As we look to expand our Agile development across multiple teams, it makes sense that we’d want to keep our DevOps intact during that effort. Now, most frameworks or even home-grown designs for team collaboration account for DevOps. Large Scale Scrum (LeSS), however, is different. It not only accounts for DevOps, but also builds it into the approach. And the more teams embrace DevOps, the better it is.

BalticServers data center

What sets LeSS apart in this? Where other approaches focus on aligning and directing team efforts, LeSS focuses instead on team collaboration. Teams in LeSS don’t just work in the same direction, they collaborate on the same product effort. We know from working with team members that fast feedback loops, frequent check-ins, and automated tests help developers collaborate and LeSS leverages those same benefits across teams. Let’s look at a few examples:
 
Continuous Integration & Deployment (CI/CD): We have learned that finding integration conflicts quickly leads to smaller problems and faster solutions. Most developers have moved from checking in code every week or so to committing multiple times per day. In LeSS, all teams must be fully integrated into a single code-base by the end of the sprint, which is distinctly different than all teams integrating at the end of a sprint. Much like within a team, the more frequently these teams integrate and build their application, the smaller their inter-team integration conflicts and faster their resolution to create overall robust scaled delivery environment.
 
Automated Testing: This serves two major purposes when collaborating between teams. First, describing the desired functionality in a test using unit tests, integration tests, or functional tests, removes ambiguity about how the application should function. This allows teams to work on the same effort more effectively without taking the application in different directions. Secondly, running automated tests at every build alerts a developer (or team) if the code changes they made accidentally interfere with someone else’s work. Done right, these alerts can happen even before integration on a CI server occurs.
 
Cross-Functional Teams: DevOps extends the idea of cross-functional teams to include the skillsets needed to deliver software to the end user. LeSS relies on this to release software. In the LeSS approach, there is no separate process for code to enter that carries it to release. Each team must be capable of releasing their features into production at any point. There is no release team or stabilizing period to hand off code to.
 
While other approaches are compatible with DevOps, LeSS is principally and structurally sets up an organization to be successful with DevOps. DevOps principles and practices find full expression in a LeSS environment and in turn enable smoother and faster development in teams working with LeSS.

Photo BalticServers data center by Wikimedia Commons

Agile Leadership for future-proof companies

/by

Fast-moving markets, economic uncertainties and progressive digitization pose major challenges for companies. Instead of responding quickly, many companies are still stuck in old structures. However, economic survival requires a high degree of adaptability. Businesses therefore have to become more agile. For this to work, in addition to intervening in the organization, a new understanding of the roles of all involved is necessary. The executives are particularly challenged here, as agile methods are largely responsible for the teams’ decision-making power. So what role do managers play in moving towards more resilience and anti-fragility in their organizations?

We have discussed these topics in a new article published by German magazine Informatik Aktuell.

The original article titled Agile Leadership macht Unternehmen fit für die Zukunft can be read online.

The nature of innovation

/by

“Innovation is not so much about having ideas as it is about making connections” – Harold Jarche

“Yesterday during a break, I went for a walk in the bush around the venue. I came across a deer in the path, and I immediately thought that I had to bring my son with me next time, as he’d love to see it. But then I realised that if I came back here expecting to see the deer again we’d probably both be disappointed.”

This story, shared by a participant of the 5-day agile42 Innovation Sprint I facilitated recently, captures the emergent and often ethereal nature of innovation. Innovation happens mostly by accident – it’s about serendipitous encounters and connections. We can create conditions where the chance is greater for it to emerge, but we can’t mandate, manage or create innovation.

How then do we go about creating containers where innovation is more likely to emerge? One learning from this workshop is the importance of how an event is framed (i.e. what we call it) as the framing creates a container within which the process unfolds, and it also creates expectations that can either be enabling or disabling.

InnovationFirstly, the expectation of this being an event that needed to lead to “innovation” introduced pressure and expectations that paradoxically may stifle more than enable innovation. Some of the participants voiced concerns about “not being particularly innovative” and many seemed to adopt a wait and see attitude about whether anything new will actually emerge. Many expressed the fear that we’ll only end up with “tweaks and fiddles” as opposed to “real, out of this world innovation” or that “ONE big idea”.

To counter this, one of the first exercises was a narrative meaning making process around innovation where the aim was to at least externalise and acknowledge problematic stories and meanings the group held around innovation so that we could work with them more intentionally. We did this by exploring the following questions:

  • What do “they” say about innovation? (They being the nebulous “other” that we often talk about, but never really know who “they” are)
  • We then broadened it to look at the context in which these things are said
  • Then we unpacked the impact of these meanings on the group

The group highlighted two emergent patterns from this exercise: one of pressure (innovate or die) and another of prejudice (only some people can innovate). Innovation was seen as “hard”, about that “ONE big idea” that had to be lucrative. It is risky – expensive if you fail. Innovation is fast and quick; it’s an imperative “innovate or die”. On the other hand it’s also a “buzz word”.

When asked to name this innovation narrative names like “we’re all confused” seemed to resonate.

This process a much more open container for the work and upon reflection later on in the week, many participants referred to this process as a key break-through moment.

Outside of the boxWe also challenged the cliché of innovation requiring us to “think outside the box”. Often we don’t know what the box is (or if even exists), so how can we think outside it? We chose instead to reframe our process as “unfolding the box”, which served to shift the perspective of the group from a focus on outcome to a focus on process and a stance of curiosity and enquiry.

agile42 has a strategic partnership with Prof. Dave Snowden, and we wanted to use this workshop to also gain deeper practical insight into the Cynefin framework and other related methods. We therefore “unfolded the agile42” box using multiple complexity based group activities such as…

  • Future backwards to understand the current reality (today), future dreams (patterns in heaven) and fears (patterns in hell) of the group as well as gain insight into the shared corporate memory (patterns in the timeline). Here the group discovered that even though they are distributed across many different countries and continents, there were golden threads that tied them together.
  • Cynefin contextualisation to surface sense-making patterns and biases.
  • Archetype extraction – prior to the workshop, we collected stories about current agile practices (best and worst) using Sensemaker. We used these to extract emergent archetypes, visualised by a cartoonist in the workshop.
  • We used appreciative interviews to surface and share success stories about client engagements as well as sales and marketing experiences. We then asked the ASHEN (Artifacts, Skills, Heuristics, Experience and Natural Talent) perspective questions and to surface key knowledge objects that exist in agile42.
  • We applied ABIDE (Attractor, Boundaries, Identity, Diversity & Environment) as perspective lenses to understand the market and “influencable” patterns.

These divergent (and often messy!) methods served to make patterns visible and keep the group from falling into their comfort zone of identifying problems and then trying to find solutions.

This was not an easy of comfortable process for the group. Many of the activities seemed disparate, each providing a different perspective or unfolding a different aspect of the box. There was no defined outcome, and no linear process where each activity built on another. Being complex methods, they were largely emergent and involved ambiguous instructions. Golden threads only became apparent on day 3, and some activities were “left hanging” and never really resolved.

As the majority of the people in the room are coaches, who are used to “being the experts” and the “ones who know”. The inherent uncertainty and ambiguity that such a divergent process brings challenged this identity and brought greater empathy for how their clients feel when they experience similar processes.

When we did finally converge on day 4, the majority of the group felt that the discomfort was worth the end result. Many felt that the value was as much as the experience of the uncertainty of the process, and the associated learnings than the eventual outcome (a portfolio of experiments and ideas that will be actioned in the next few months).

An interesting metaphor that emerged during the process is that innovation can be likened to a chef that combines existing ingredients into brand new recipes. Chefs don’t create new ingredients, they combine what is already there in unique ways. The challenge for this group was to see themselves (e.g. skills & offerings) and their markets (attractors, boundaries etc) from multiple perspectives to potentially recombine existing capability to new market opportunities.

Read more about Sonja Blignaut and More Beyond at www.morebeyond.co.za. Artwork by James Durno.

Sponsoring Agile2017

/by

Sponsor of Agile2017Agile2017, the annual North American conference of the Agile Alliance, comes to sunny Orlando, August 7-11. The event is dedicated to furthering Agile principles and providing a venue for people and ideas to flourish.

agile42 is happy to be a Silver Sponsor, meet our coaches in Florida where we can talk about Agile change and pick up an early copy of the The Hitchhiker’s Guide to Agile Coaching!

 

 

How to get your conference submissions accepted

/by

I have been part of either reviewing or organising multiple conferences, both locally and internationally. I am grateful for this because it helped me to learn about how to create a submission that has a better chance of getting accepted. During my reviewing for the AgileXX conferences I had the opportunity to pair with some experienced reviewers and agilists, which also helped me to grow and learn.

I’m going to share what I have gained from the experience, and hopefully, it can help others out there…

Conference schedule board

This is what I look for when I’m reviewing a submissions:

  • It’s new.
    It adds something that hasn’t been done or thought of before, or it combines things from different fields or thinks about things in a new way.
  • There is a takeaway.
    I feel that people will have great takeaways from it
  • It’s inspirational!
    When I read it, I think, “wow, I want to go to that.”
  • Real life experience.
    The submission shows there is real life experience behind it, not just reading.
  • It is well written and to the point.
    A well-written submission with zero buzzwords and enough information for me.
  • It shows confidence.
    I am confident that the submitter can deliver from a speaking or facilitation perspective.

Out of this list, the most important to me is the submission is well written and to the point. A great submission is well written, has zero buzzwords and has just the right information for me. Getting this right is key to getting your submissions accepted. Here are my pointers for getting it just right!

Tips for writing your submission

Short & Sweet: The Title

Your title needs to be interesting. Let it say something about your talk. Don’t make it too long unless that is an intentional learning point in your submission. Often people will decide where to go based on the title, and I can’t tell you how many times I’ve seen terrible or boring titles. As a reviewer, you often don’t want to read any further.

Punchy: The Abstract

Your abstract needs to be short and punchy. The abstract or summary is the part that goes on the program, so it needs enough information, that people know what they are getting and are excited about it. But not so much that they get bored and stop reading. Reviewers and conference participants are also not always looking for the same thing, so if you completely optimise for one, you might lose the other.

Not many people decide before a conference where to go, so the abstract is often the thing that helps them decide. If your abstract is too long, people get bored and stop reading. If your abstract is like a bad movie trailer and contains all the best bits from your talk, then people will be disappointed, because they got as much out of your talk as they did reading the abstract.

So think about a good movie trailer, an original abstract highlights the good bits, but makes sure that the meat will be in the talk itself. As a contrast, an abstract with loads of buzzwords and that looks like a sales pitch either for the submitter themselves or for something that they have developed or a book they have written, can turn a reviewer off very quickly. A good tip is to approach the abstract as if you were writing a tweet, write and rewrite until you get the key message under the (self-imposed) limit.

Sell it: Information for the program team

In this section you have the opportunity to sell your talk to the decisionmakers: the review committee. Here is where you want to be clear about what your talk or workshop is going to be about. If you have hinted at new models or exciting new thinking in your abstract, be clear about what that looks like here. If you aren’t, there is no way for the program committee to know what you will be talking about. Be clear about how your session looks. People from the program team want to know this for workshops and talks. We want to know that you have thought about this deeply and that you know how you are going to spend the time. If you are proposing a workshop, we want to know that you have thought about how to scale it. Have you thought about what it will look like for 20 people vs. 50 people vs. 100 people or even 200 people?

Let us know in detail how you will spend the time. A great submission lays out in detail how the 45 mins / 90 mins / 60 mins / 2 hours etc. will be used. If I can see that, then I know you have thought about what you are going to do. If I can picture your session in my head, either talk or workshop, and I think to myself, “Wow, I want to go to that!”, then I will rate your talk highly – and chances are, so will others.

If you are doing an experience report, here is where you highlight to the program committee the things that people will learn or take away from your talk. Here is where you explain at a high level, why your story is better than the next guys.

Checklist

The don’ts

A few things frustrate me when I’m reviewing, especially when it’s late and I’m tired. So here are some don’ts:

Don’t send links

Please do not send me to your blog or your book. I don’t have time to read your submission plus 50 blog posts on the topic, I have 100 other submissions to go through, and I just want to go to bed. If you can not get your ideas across succinctly in your submission, you will get a poor rating.

Don’t give a breakdown with no detail

What I am looking for in the breakdown is what your talk/ workshop looks like. I recieved the below breakdown recently and that doesn’t cut it. Show me what your talk or workshop looks like not what a generic structure could look like. A structure this limited, just shows me you haven’t thought about it at all.

– Intro and topic setup (10 min)

– Body of topic (20 min)

– Learning recap (5 min)

– Q&A (10 min)

Don’t tell me how awesome you are

Nothing is more frustrating than a submission that is filled with details about how fantastic the speaker is and that they just published their new book/blog/podcast…. With little or no information for me about what they are actually going to talk about, (since I haven’t read their book) and what the audience will get out of it.

You need to make an impression.

As an organiser, you are often doing this voluntarily. Meaning, you have to make time in your spare time to go through hundreds of submissions for a big conference or between sixty and a hundred for a smaller conference.

Often there are 80 – 100 submissions for maybe 25 slots. At the bigger conferences there are upwards of 200 submissions for every 20 – 25 slots available. These are the numbers, and your submission is just one of many.

Even if you have all the right detail and a great submission, most conferences will have a team of people reviewing and so there are many people you need to impress. Even if you manage to impress many people, if someone else has a similar topic or a better submission, then you are out. And if there are more submissions with new and exciting things again you will be out. Remember you need to stand out from the 100 other submissions that are vying for the 25 slots on a program, make yours the one that all the reviewers say “Wow, I want to go to that!”  There is nothing more disappointing or frustrating for a reviewer than a great title or idea, and the rest you can see took only 5 minutes to write.

You aren’t going to be successful every time, but keep going and the better you get, the better your chances will be.

Timing is everything.

More than 50% of the submissions come through on the last day that the system is open. From there, reviewers often don’t have much time to get through all of them or as many as possible so that each submission is seen by at least 3 or 4 people.

If yours comes through on the last day and is number 65 of 80 or number 45 of 50 or something like that, then chances are most people have reviewed that many already today and are grumpy with the crap submissions and probably tired. Unless yours is a “shoot the lights out” submission, it’s going to get a crap rating at that point.

One final tip.

If you submit to the AgileXX conferences and if you submit early, you can ask for help, and there will be a team of people ready to help you improve your submission. Submitting in this way is probably one of the best ways to learn!

I hope these tips help you to write a great submission. If you have other tips to share, I would love to see them in the comments!

Announcing: The Hitchhiker’s Guide to Agile Coaching

/by

As agile42 coaches we are proud to announce that our first proper coaching book has been released! This is the book we wish we had had when we started out as agile coaches, and it’s now available for download free of charge.

We take great pride in our tradition of coaching, which is continuously being adapted to the needs of our clients and our own company. Our approach is simple, but not necessarily easy. With this book we wanted to create an introductory reference for new agile coaches as well as experienced ScrumMasters. It contains much of the theory that we teach our new colleagues at agile42, and hopefully lots of insights for new coaches everywhere.

Cover of "The Hitchhiker’s Guide to Agile Coaching"

The book is primarily about coaching, but not so much about agility. We are not going to explain e.g. why it makes sense to slice large work items into smaller independent pieces, or how to choose between synchronized and unsynchronized releases. There are plenty of good books around for those purposes. We assume that all readers have adequate working knowledge of all things agile.

Instead we are going to teach you the basics of listening, how to maintain a structured conversation without inserting content, and how to facilitate conversations in teams. We’ll talk about how to help a group of people form an effective team and how you can help create heedfulness and synergy in a team. We’ll present structured means of collaborating on a team with ScrumMasters, development managers and other agile coaches. We’ll cover why change makes people nervous and discuss different ways of overcoming that. 

All of this and much more is now available in one book. Becoming an agile coach is a journey that has no end… and that’s why the name of this book is The Hitchhiker’s Guide to Agile Coaching.

Since this book was written by a team, we have chosen not to stand out individually. Instead, we have been writing this book as if it were software developed by a team. However, we can disclose that the main culprits include a number of CECs, at least one CTC, and a couple of CSTs. This is the very first public release and it will be improved and expanded with the feedback of the community. We are happy to show it to the world for the first time.

Download here the e-book in PDF or EPUB format

La chimera dell’Agile in Italia: dibattito a PyCon 8

/by

Durante la conferenza PyCon 8 di aprile, Marco Beri, Iacopo Spalletti, Gabriele Giaccari, Peter Bittner e il coach di agile42 Roberto Bettazzoni hanno dato vita a un interessante dibattito intitolato L’Italia, Python e la chimera dell’Agile per fare il punto sull’adozione delle metodologie agili in Italia e in particolari tra i programmatori Python a cui era dedicato l’evento. Sul canale YouTube di Python Italia è stato pubblicato il video integrale della sessione.

Dhaval Panchal and Dave Sharrock podcasts at Agile Amped

/by

The Agile Amped podcast is a series that brings Agile news and events to life, fueled by inspiring conversations, innovative ideas, and in-depth analysis of enterprise agility. 

Howard Sublett hosted Dave Sharrock for an Agile Amped episode during Keep Austin Agile 2017 in Austin, Texas. Howard and Dave discussed Dave’s talk What Does the Agile Manager Actually Do (full of Dilbert references) and his coaching experience. Listen in to learn how  teaching your kids how to cross the road can help you be a better agile manager.

Dhaval Panchal was a guest of Agile Amped during Mile High Agile 2017 in Denver, Colorado. He discussed Virtues of an Agile Coach, his talk at the event, and what does it mean to be an Agile Coach. Dhaval says what really matters in Agile coaching is what you do when no one is looking, because “that is what is driving you to become better at your own craft.” Dhaval invokes Aristotle and the notion of Virtues to help guide us on our path to becoming better Agile Coaches.

You can subscribe to Agile Amped in your favourite podcast app.

Bridging the Unknown

/by

Cover of AgileVox issue 3This article has been previously published in the Coaches’ Corner section of issue 3 (Spring 2017) of AgileVox, the magazine published by the Scrum Alliance.

In the climax of Indiana Jones and the Last Crusade, Indiana Jones follows three clues that lead him to the Holy Grail. One of those cluse implores him to “leap from the lion‘s head.” Faced with a deep, wide chasm – with a lion’s head on one side and empty space ahead – he must step into the unknown. In leaping from the lion’s head he suddendly finds himself standing on an invisible bridge crossing the chasm.

My intent is not to say that Agile is a leap of faith or that you must cast everything you know aside and jump into the unknown. The role of Indiana Jones is for the pioneers who first bring Agile into your organization. They deserve the credit: Whips and cool hats must be passed around.

Those that follow may have a lesser task, but a daunting one nonetheless. In the movie, Indiana Jones throws a handful of gravel and dirt onto the bridge, making it visible and easier to cross. But crossing still takes nerve, and his companions don’t simply stride across the narrow bridge. They take small steps and continually reassure themselves that the bridge is real, if hard to see.

Still from "Indiana Jones and the Last Crusade"

In an Agile transformation, those small steps are iterations or sprints, and the reassuring inspections of the bridge are the regular reviews of working product, or increments. These are not random practices; they are necessary for everyone, from managers to teams, to reassure themselves that the path being followed is trustworthy. While your company’s Indianas have identified the path to agility, your leaders and teams still require continual reassurance as the path is trodden over and over again.

The way we achieve this is paradoxical. We shorten feedback – a lot. That is, instead of keeping sprint lengths longer so that teams are able to gain experience delivering in four-week, then three-week, then two-week cycles, we encourage them to take a (small) leap of their won, going immediately to one to two weeks.

Shortening the sprint length alone isn‘t enough, though. We also need to help teams deliver working product – an increment of functionality, however small and inconsequential, that the team feels confident can be released then and there. Make this simple. Encourage teams to keep their sprints as short as they dare, and then take the smallest amount of work they feel confident they can deliver in a single sprint. If they try and fail, get them to deliver even less, but help them make what they do deliver shippable.

We know why this works. Every complete sprint allows the team to learn and adapt their ways of working. The shorter the sprint, the more opportunities to learn and adapt. However, learning is only possible when there is something tangible to inspect at the end of a sprint. Something that is complete and ready to go live allows the team to learn about all aspects of the way they work. And management gains confidence in how Agile works, turning their attention from the mechanics to the results.

An interesting thing happens as work is delivered at the end of each sprint. Teams learn and adapt, making changes that make the next piece of work easier to complete. Taking small steps and delivering shippable product creates a virtuous cycle. The leap becomes a careful crossing of a barely visible bridge, which quickly becomes a saunter across a well-traversed one.

Still from “Indiana Jones and the Last Crusade”, © 1989 Lucasfilm Ltd.