Tag Archives: Agile

The Agile lightning talk cheatsheet

Leave a reply
14740975856_15b4e8fe12_h

Image from p.173 “Crayon and character: truth made clear through eye and ear or ten minute talks with colored chalks”, (1913), Flickr Commons

In choosing a lightning talk topic, stories of failure are as useful as stories of success! In fact, choosing a sensational topic is actually half the work. I’m reminded of an embarrassing episode in my childhood, when I definitely got it wrong.

A long time ago now, when I was a small child, perhaps 8 years old, my parents decided I needed to get some religious education. They sent me to a youth group summer camp, with lots of groovy young leaders who modelled the behaviour expected of people who were passionate about religious observance. We kids were engaged in outdoor activities, (on a religious theme), lots of singing, (on a religious theme), indoor games, (on a religious theme). Well you probably get the idea.

The highlight of the camp was when the parents and the religious leader of the congregation came to visit. The passionate enthusiastic youth leaders assembled everyone with their mums and dads in a big circle to show off the kids’ newly acquired religious knowledge. The coolest of all the youth leaders welcomed everyone and explained, after the rousing welcome song, that now the kids had an opportunity to ask the religious leader a really good question.

I was, unsurprisingly, the first child to raise my hand. In fact I sprung out of my mother’s lap, barely able to contain my excitement at the incredible question I had to ask. I faced the revered religious leader, and in a loud and confident voice I asked, “Why do we have freckles?”

Laugh you may. I had clearly not understood the first rule of engaging an audience – choose the right topic!

So what is the right topic for a lightning talk?

A good lightning talks tells a story that the audience is not likely to have heard before. Like a TED talk, it is an idea worth sharing. Here are some prompts to help you think up a topic:

  • Great ways to…
  • Great ideas for…
  • What we can learn from…
  • How to … in 3 easy steps

Some of the lightning talks I’ve delivered are:

  • 5 great ways to seed Agile curiosity in your organisation
  • 5 great ideas for competitions that build your team’s Agile knowledge
  • 5 great ways to introduce or reinforce Agile behaviours into a team
  • The Great Pancake Cook up – teaching collaboration
  • What we can learn from our Lean cousins at Alcoa
  • How to make the most of a field trip to another workplace
  • Help – my team has list its mojo!

Telling the story

Bearing in mind that a lightning talk is no longer than 10 minutes, how do you tell the story in just 10 minutes?

Like all good stories, a lightning talk needs a beginning, a middle and an end. Here’s the framework:

  • Introduce your topic
  • Explain something to the audience
  • Parting words

Simple hey?!

Well it should be. The right amount of content is about the amount of content that another person could convey if they were asked, “What was that lightning talk about?”

A lightning talk isn’t…

A lightning talk isn’t a conversation, a rant, a PowerPoint presentation, a video, a sales pitch or a commercial platform for your company or career.

You talk because you love the idea of sharing an idea. As with a TED talk, it “takes the listener on a journey and provides an insight into the subject that they did not have before”*.

How do you tell a good story?

Consider telling a story. Our brains are programmed to enjoy them. Good stories set the scene, they include build up, and of course resolution. They often make the audience laugh, or connect and hopefully reflect on the theme of the lightning talk.

If you are using slides, make them scant and of few words. Where folks are reading, they aren’t listening.

A great lightning talk expresses your curiosity and enthusiasm for your topic. In putting your lightning talk together, ask the question, “How can I convey what excited me about this topic”. This question will help you shape the few dot points that are the middle of your lightning talk”.

Refine, refine, refine, using each sentence for maximum value. Your adrenaline will prevent you from thinking straight, so don’t plan to invent your talk from a few dot points on a cue card. Know every masterfully picked word.

A few words can evoke a world of thought. Think about how a pithy quote can express or cement the ideas you are trying to convey. It’s sometimes a great way to end a lightning talk.

Preparing to deliver

Because a lightning talk is not a speech, a lesson or a lecture, you need to TALK it. Have a run through with your friends and colleagues, practice it in the mirror, tell it to your pot plants, but don’t get up on stage with a script.

One the day

I have little advice for you except to say that those in the audience are unlikely to see your legs shaking.

Go slow. Not only will it make it easier for people to understand you, but they will also be able to absorb what you are saying and reflect on it.

Are lighting talks for the beginner presenter?

I would absolutely encourage a beginner presenter to give it a go. Contrary to popular opinion though, it takes more skill to deliver a fabulous lightning talk than a half hour presentation. Don’t be discouraged. Instead reflect on these top 5 reasons why you should consider giving a lightning talk:

  1. It “gives you a rare opportunity to spend time thinking about a specific topic [you are passionate about] and distilling it down into something you can quickly and effectively communicate to others”**
  2. It is the magnet to connect with other people thinking about the same things as you
  3. For that moment in time, you are a thought leader
  4. It’s an awesome icebreaker at the post conference drinks
  5. It’s scary good.

 

* http://tedxmelbourne.com/apply/

** http://businessofsoftware.org/2013/07/why-you-should-give-a-lightning-talk-2/

 

Agile leadership – questions for innovation & continuous improvement

Leave a reply
Brick 101 - LEGO Ideas Research Institute - Flickr Commons

Brick 101, LEGO Ideas Research Institute, Flickr Commons

What are the questions great Agile leaders ask themselves to drive continuous improvement and innovation?

My previous blog explained how great Agile leaders, as coaches, business drivers, purveyors of purpose and enablers, acknowledge the success of their teams and reward right behaviour. How do these four roles shape leaders’ approach to continuous improvement and innovation?

Applying the coaching lens to continuous improvement, great leaders ask: Do I teach my teams how to embed continuous improvement through Lean and Agile techniques such as retros, kaizen and improvement katas?

Applying the business lens to continuous improvement, great leaders ask: Do I reward individuals and teams who regularly implement improvement activities to maximise lifecycle profits?

Applying the purpose lens to continuous improvement, great leaders ask: Do I energise and engage my people to drive continuous improvement?

Applying the enablement lens to continuous improvement, great leaders ask: Do I make time for my team to implement improvement? Do my people have the autonomy to implement improvement?

Jez Humble and Barry O’Reilly’s 2014 Lean Enterprise: How High Performance Organizations Innovate at Scale is truly a wonderful blueprint for developing the sort of generative company culture that leads to innovation.

These are some questions that Agile leaders ask to create such a generative culture.

Applying the coaching lens to innovation, great leaders ask: Do I model and teach collaboration, risk sharing and acceptance of failure in order to learn?

Applying the business lens to innovation, great leaders ask: Do I promote ways of working that foster innovation through continuous experimentation?

Do I run hack days?

Do I reward great ideas?

Applying the purpose lens to innovation, great leaders ask: Do I recognise that without autonomy, there will be no opportunity for my people to innovate?

Applying the enablement lens to innovation, great leaders ask: Do I create a generative culture that enables my people to think innovatively to resolve impediments?

Appelo makes it sound easy when he says, “We aim for a more powerful system, not better controlled people”.

What other questions, can we, as leaders ask, to propel continuous improvement and innovation?

Agile leadership – rewarding right behaviour & acknowledging success

Leave a reply
Doughnuts - Amy - Flickr Commons

Doughnuts, Amy, Flickr Commons

What are the questions great Agile leaders ask themselves about acknowledging success and rewarding right behaviour?

My previous blog explained how great Agile leaders support learning, as coaches, business drivers, purveyors of purpose and enablers. How do these four roles shape leaders’ approach to acknowledging success and rewarding right behaviour?

Applying the coaching lens to entrenching success and rewarding right behaviour, great leaders ask: Do I teach individuals and teams that it is important to acknowledge and celebrate success?

Applying the business lens to entrenching success and rewarding right behaviour, great leaders ask: Do I measure the success of individuals and teams simply by their output, or by their focus on activities that relate to the core value stream?

Do I bring doughnuts when we get through a tough story or sprint? Do I know when my teams have got through a tough story or sprint?

Laugh you may, but what I’m emphasising is a leadership style that recognises the connection between acknowledging people’s effort and business success.

Do I wait until release of a product to acknowledge the effort of those involved, or do I thank my team regularly?

Applying the purpose lens to entrenching success and rewarding right behaviour, great leaders ask: Do my people feel valued? How do I know this?

Applying the enablement lens to entrenching success and rewarding right behaviour, great leaders ask: Do I reward people who resolve problems across the entire value stream?

I guess the antithesis of this is managers who reward people who do whatever it takes to get something across the line, regardless of whether it creates other issues, such as technical debt, poor staff morale or unsustainable processes.

I perceived the joy on a fellow’s face this week, when a leader acknowledged how the work he had done directly contributed to relieving a bunch of problem tickets in a service delivery queue. It’s not hard to acknowledge success and reward right behaviour. Are your leaders doing this?

Read on to learn the questions great Agile leaders ask to drive innovation and continuous improvement.

Agile leadership & learning – a new paradigm

Leave a reply
Scrumtrooper Image - Axis Agile - Used with permission

Scrumtrooper image, Axis Agile, Used with permission

What are the questions great Agile leaders ask themselves about learning?

My previous blog explained how great Agile leaders support delivery, as coaches, business drivers, purveyors of purpose and enablers. How do these four roles shape leaders’ approach to learning?

Applying the coaching lens to learning, great leaders ask: Do I share knowledge, skills and perspectives with my people, to foster their professional growth?

Do I understand the role that mastery plays in helping individuals feel more engaged in the work they do?

Do I emphasise and model the value of life-long learning?

Am I the person recommending books, meetups and stuff I’ve read on the Internet?

Do I blog, respond to blogs or start conversations on Slack or Twitter?

Applying the business lens to learning, great leaders ask: Do I foster practices that drive experimentation and learning, to maximise product lifecycle profits?

Applying the purpose lens to learning, great leaders ask: Do I help my people understand the value of what they’re delivering, so that they develop a sense of purpose?

This of course references Dan Pink’s 2009 publication Drive: The Surprising Truth About What Motivates Us. W. Edwards Deming in fact predates Pink when he writes in Out of the Crisis in 1982, “The aim of leadership should be to …bring pride of workmanship to people”. In 1988 Deming revised this phrase to “joy of workmanship” and it refers to purpose.

Since Pink’s 2009 publication there have been a flurry of books on the topic of purpose, including Appelo in 2011 and unsurprisingly a couple of great little TED books from last year, Beyond Measure: The Big Impact of Small Changes, by Margaret Heffernan and Why We Work by Barry Schwartz.

I really like the work of Steve Denning on the topic of purpose and delivery, so I’ll quote him here:
“Delighting other people is inherently motivating…
The meaning of work isn’t in the bread that we’re baking; it’s in the enjoyment the customers get from eating the bread.
The meaning of work isn’t in the words the actor is reciting; it’s in the response of the audience to those words.”

So I’ll add to the list of questions that great leaders ask themselves: Do I expose my people to customers, suppliers and other world views to connect them with customers?

Applying the enablement lens to learning, great leaders ask: Do I create a culture where it is safe to fail? This question of course comes from an understanding that we learn from both failure and success.

Do I reward teams that experiment to learn?

Do I take a systems approach to learning, understanding that to resolve impediments I must see the whole, rather than just the component parts?

Do I use lean techniques to focus on the entire value stream, to measure and learn?

Am I am a driver for development of strong chapters and communities of practice, to support both new and expert practitioners?

In an interview online, Carsales.com CIO Ajay Bhatia talks about his leaders’ engagement in communities of practice:
“We run a book club for the leadership team across product and technology, where we discuss the most important things we picked out from the book and go away and try and implement those things among our teams… Our book club has been so successful that now it is no longer only limited to the leadership team and the number of members is ever increasing. This is creating a culture where we are constantly picking up new ideas and ensuring what we build in Australia is no less than world class.”

Jeff Smith, CIO of IBM, said in the keynote address at Agile Australia 2016, “it’s important for people to try stuff, but not get the OK from me to do it”.

Great Agile leaders know that learning isn’t just about sitting with individuals once a year to set a learning plan. It’s about always asking, “What did you try? What did you learn?”

Do you model these behaviours? Do you know leaders who have changed the paradigm?

Read on to learn the questions great Agile leaders ask about rewarding right behaviour and celebrating success.

Agile leadership & delivery – it’s not about pizza boxes

Leave a reply
190310 - Losers of Friday Night Rejoice - Lis Ferla - Flickr Commons

Losers of Friday Night Rejoice, Lis Ferla, Flickr Commons

What are the questions great Agile leaders ask about themselves about delivery?

My previous blog explained how great Agile leaders communicate as coaches, business drivers, purveyors of purpose and enablers. How do these four roles shape leaders’ approach to delivery?

Applying the coaching lens to delivery, great leaders ask themselves: Do I give my people the Agile expertise and tools to deliver?

Applying the business lens to delivery, great leaders ask: Do I ensure that my teams work at a sustainable rate to maximise delivery?

You guys know that the best measure of this is the smell of pizza – right? Where you see a stack of empty pizza boxes in the office on Monday morning, then a team has worked over the weekend. When the smell of pizza on a Monday morning is the norm, then the team isn’t working at a sustainable pace.

Tom DeMarco in his classic 2001 book, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, says that “an increasingly common bit of organizational folklore holds that pressure improves performance and that maximum performance can occur only in the presence of maximum pressure. This idea, though deeply embedded in our culture, doesn’t stand up to examination in the light of day”

Managers who encourage their people to commit to the right amount of work and who reward those who meet the goals of the sprint time and time again, understand that sustainable delivery leads to predictable business outcomes.

Applying the purpose lens to delivery, great leaders ask: Do I provide the goal and strategic direction, allowing my people to define how they meet requirements? Do I trust my people to figure out how to meet requirements?

Nigel Dalton, CIO of REA Group, comments in an ITNews interview online, on the paradigm of leaders providing strategic direction and thus allowing people to deliver. He describes that Toyota has strict rules about what executives spend their time focused on:
“In Toyota’s hierarchy, the president and executive are only permitted to think about horizons two and three,
The people at the coalface must run and operate horizon one.
As a CIO, I am always drawn to the challenges of today – challenges around IT security, developer recruitment, or how we use cloud. But I have to trust the teams to manage horizon one.”

Applying the enablement lens to delivery, great leaders ask: Do I trust my people to resolve problems? Do I challenge them to balance delivery with managing accrual of technical debt?

Dipesh Pala, IBM’s Agile Capability Leader for Asia Pacific, exhorted leaders at Agile Australia 2016 to “shift from managing results, to designing environments that encourage results”.

At the same conference, Jeff Smith, CIO of IBM, remarked, in reference to a customer service help desk, that using Kanban was critical in delivery. He explained that “the ability to pull tasks, rather than being given them” was what created swift and effective delivery.

He went on to explain that “if we fundamentally change the way things work, it gets better”. I was struck by the simplicity and sense in this statement. Great Agile leaders are enablers for delivery. That is their job!

Are your leaders asking the right questions about delivery?

Read on to understand the new Agile leadership paradigm for learning.

Agile leadership & communication – so many opportunities

Leave a reply
The Garage - Peter Kaminski - Flickr Commons

The HP Garage, Peter Kaminski, Flickr Commons

What are the questions great Agile leaders ask themselves about communication?

My previous blog explained how great Agile leaders apply their role as coaches, business drivers, purveyors of purpose and enablers to decision making. How do these four roles shape how leaders approach communication?

Applying the coaching lens to communication, great leaders ask: Is communication with my people face to face, authentic and regular? Do my people feel comfortable to initiate contact with me as much as I do with them?

Bill Hewlett and David Packard of Hewlett Packard fame, incepted the practice of “management by walking around”. Until they stepped down from HP in the 1970s, they interacted with their employees in an unplanned way to check equipment, understand the status of work and engage people in authentic conversations.

Appelo describes “management by sitting around” which of course means taking the opportunity to sit with your various teams, hear what they are working on and interact with them. If this isn’t possible, then he suggests “management by Skyping around” which is unfortunately less spontaneous.

I remain astonished by my observations in workplaces, of how frequently managers miss opportunities to interact with their people in an authentic and regular way. Standup is the time to hear how teams are progressing, showcases, even more so.

Do I know those I manage on a personal level?

Appelo suggests imagining a personal map of your people. Do I know what my people like to do outside of work, how many kids they have, who they are friendly with in the workplace? When you start this exercise you might be astounded at how little you know about your people.

Am I open to being influenced by those I manage?

Have I created an environment where individuals and teams are able to disagree where appropriate, negotiate, compromise, agree and commit?

Applying the business lens to communication, great leaders ask: Do I have a Kanban board to communicate progress on my goals?

Do I use Agile practices like standups, information radiators, blogs and conversation platforms like Slack, to establish the sort of two way communication required to maximise product lifecycle profits?

Do I insist on right fit ways to communicate the status of work, such as through conversations, standups, information radiators and A3 canvases, instead of reports and gannt charts?

Applying the purpose lens to communication, great leaders ask: Am I out and about interacting with my people to create opportunities for two-way conversations and interactions about our organisation’s purpose and strategy? Do I favour two-way communication to convey purpose and strategy, over group emails and formal forum events?

I’m not suggesting that whole organisation events shouldn’t happen, but where these are a one way conversation, with leaders pushing information to folks, and folks feeling uncomfortable in asking a question, it isn’t an effective two-way conversation about strategy.

Applying the enablement lens to communication, great leaders ask: Am I effective communicating across organisational boundaries and hierarchies? Is my communication underpinned by an understanding of the complexity of the organisation? Do I communicate to effect change within a complex system?

Connected communication is at the heart of effective leadership. Do the Agile leaders you know ask themselves these questions?

Read on to learn how great Agile leaders succeed at delivery.

 

Agile leadership & decision making – new patterns, new questions

Leave a reply
Brain - Chris White - Flickr Commons.jpg

Brain, Chris White, Flikr Commons

What are the questions great Agile leaders ask about themselves decision making?

My previous blog explained how Agile leaders of today understand themselves to be coaches, business drivers, purveyors of purpose and enablers. How do these four roles shape how leaders approach decision making?

Applying a coaching lens to decision making and problem solving, great leaders ask: Do I teach my teams a model of delegated decision making?

Jurgen Appelo explains that “we can only escape [the] typical management trap and increase the quality of work when we distribute control in our organisation.” Comparing an organisation to a brain, Appelo continues that “all around us (and inside us) complex systems self-organise successfully because control is rarely centralised.”

The level of delegation will of course depend on the maturity of the team, the status of its work and the impact of decisions on the organisation.

Drawing on Reinertson’s work in Managing the Design Factory Appelo encourages teams to create delegation boards that clarify what level of authority teams have across different activities.

The seven levels of delegation that Appelo defines are:

  1. Tell – making the decision as the manager
  2. Sell – convincing people of the decision
  3. Consult – getting input from the team before decision
  4. Agree – making the decision together with team
  5. Advise – influencing the decision made by team
  6. Inquire – seeking feedback after decision by the team
  7. Delegate – no influencing, just letting the team work it out

Applying a business lens to decision making and problem solving, great leaders ask: Do I delegate enough control to allow my people to maximise product lifecycle profits?

A Product Owner, responsible for defining the features for a new app, needs the right level of authority to make decisions about which features should be built first second or not at all.

A Scrum Master shaping people and processes within a team needs authority to ensure folks in the team have the right equipment to build profitable products.

Applying a purpose lens to decision making and problem solving, great leaders ask: Have I conveyed the organisation’s strategy to my people, so that they have the right information for decision making?

I think about one organisation in which I worked where strategy visualisation happened on walls in a glass meeting room, but where those walls were covered in brown paper to prevent people outside the room seeing the information.

How different is this from the strategy boards on full view at companies like REA Group, Carsales and Envato. Where strategic conversations happen behind closed doors, teams simply won’t have the information they need to produce the right output.

Applying an enablement lens to decision making and problem solving, great leaders ask: Does my team have a delegation board that encourages them to make decisions and solve problems as appropriate?

David Marquet’s Turn the Ship Around talks about shifting the psychological ownership of problems and solutions using a simple change in language from a “Leader-Follower” pattern to a “Leader-Leader” pattern. Marquet, a former U.S. Navy Submarine Commander, achieved in the leadership and productivity guru Stephen Covey’s words, “the most empowered organisation he’d ever experienced.”

Marquet describes a conversation in the traditional Leader-Follower language sounding like this:
Captain: “Submerge the ship”
Subordinate: “Submerge the ship, aye”

In the Leader-Leader language it would sound like this:
Subordinate: “Captain, I intend to submerge the ship. All crew are below decks, the hatches are shut, the ship is rigged for dive, and we’ve checked the bottom depth.”
Captain: “Is it the right thing to do?”
Subordinate: “Yes sir, our mission requires that we submerge now in order to complete this exercise”
Captain: “Very Well”

An ability to appropriately delegate decision making and problem solving characterises Agile leadership. Do your Agile leaders ask themselves these questions?

Read on to learn the communication questions great Agile leaders ask.

Who is the new Agile leader?

Leave a reply
Into the Unknown - Thomas Hawk - Flickr Commons

Into the Unknown, Thomas Hawk, Flikr Commons

My previous blog put a case for why we need a new style of Agile leadership. To enable self-managing teams to contribute and thrive within the complex ecosystem that is the organisation of today, Agile leaders need to understand their role as fourfold:

  1. As a coach; to share knowledge, skills and perspectives to development people
  2. As business driver; to maximise product lifecycle profits
  3. As purveyor of purpose; to connect people with the purpose of what they do
  4. As an enabler; to support  people to thrive within their environment

Even for traditional managers, there’s probably nothing controversial about these four roles, inspired loosely by the thinking of Michael Hamman and Michael Spayd. In fact to varying degrees, traditional managers might even feel that they fulfil these four roles now.

Traditional managers may perceive themselves as coach, in that they expect individuals to develop a learning plan, and if time and budget permit, they support an employee achieving it.

Nigel Dalton, CIO of REA Group, described in an ITNews interview online as, the Godfather of Agile in Australia, describes the role of Agile leader as coach:

“The company is divided into a set of teams focused on a kind of consumer ecosystem where each one is discreet from the others. Commercial property owners is mine; which is the smallest one. [The others are residential property owners and property developers]. We have understood that [there] is a kind of …‘unique customer experience’ in each one of these ecosystems.

[We asked] what if we put a full multidisciplinary team on those, and we chose a collective group to manage it?

Thus, I am not the general manager of commercial real estate – there isn’t one. I am the steward or coach of a group of seven people who are IT, sales, marketing, product, legal, finance, and human resources. Young managers in their thirties, who’ve got every competency to work as a team, and run that 40 million dollar business. I am there as their coach and all the Agile techniques come in under that. It is pretty self-contained and self-directed. It has its purpose and goal that flow down from the main company purpose. We have replicated that across the company – this is the primary structure.”

In traditional management the focus will largely be on the business role. The narrative on this would be “I reward individuals and teams who do whatever it takes to get over the line”.

The purpose role is a tricky one. Barely a middle to large sized enterprise today exists without some sort of mission statement. In traditional management, the existence of this mission statement and some resultant values might be perceived as bringing purpose to people working in an organisation. I can tell you from experience though, that the yearly exercise of requesting folks shoehorn their performance into the predetermined values of the company doesn’t yield much sense of purpose.

And finally to the enablement role. Traditional managers no doubt perceive themselves as enablers. They want their teams to succeed and would do pretty much everything to ensure this happens. I question though whether traditional managers would always take a holistic approach to enabling, seeing their team’s role in success of the whole organisation, rather than just success of the individual team.

Lisa Frazier, in her talk on Agile leadership at Agile Australia 2016, described how an Agile leader enables, by adopting a “follower-centred leadership style”. She cites three behaviours associated with this:

  1. Working for success of your team members above yourself
  2. Actively listening to your team
  3. Being a good follower

My favourite quote ever is from Nigel Dalton, at the same conference: “Leadership is not boss-ship, it’s servant leadership. Don’t ever mistake not being at the front with not being the leader”.

Jeff Smith, CIO of IBM, in the keynote address at Agile Australia 2016, said that “people come to work because they are ambitious and share the mission. The leaders’ job is to remove the obstacles”. Throughout this series of blogs, I’ll explore how great Agile leaders fulfil on their role as enabler.

Throughout this series of posts, I’ll contrast the role of Traditional Managers with Agile Leaders. What happens, when we ask great Agile leaders to reflect on these four roles in relation to the following leadership activities?

  • Decision making & problem solving
  • Communication
  • Delivery
  • Learning
  • Acknowledging success & rewarding right behaviour
  • Continuous improvement
  • Innovation

Read on to discover the questions great Agile leaders ask themselves in realtion to these activities.

 

Why Agile leaders need to ask themselves new questions

Leave a reply

steampunk

We know that organisational culture can be shaped by the worst behaviours leaders are willing to tolerate, but can culture be shaped by the best behaviours that leaders are willing to amplify? This was a question I asked myself after hearing Dipesh Pala, IBM Agile Capability Leader for Asia Pacific, speak at Agile Australia 2016.

Last year’s VersionOne State of Agile Survey identified that four of the five top impediments for Agile adoption relate to management. Over a third of respondents cited:

  • Lack of management support
  • Company philosophy or culture at odds with core Agile values
  • External pressure to follow traditional Waterfall processes
  • Lack of support for cultural transition

The first impediment, lack of management support, needs no further comment, but when you think about it, managers also have accountability for company philosophy, pressure to follow Waterfall processes and lack of support for cultural transition.

Let’s start at the beginning, and the beginning is the most dominant style of management today, commonly described as command and control, or traditional.

Command and control was considered effective because our understanding of organisations was that they work something like the picture in this blog post.

Jurgen Appelo, author of Management 3.0 would describe this as complicated. There are many moving parts in this machine. There is also cause and effect. If one part isn’t working, it affects another part of the machine.  It almost certainly takes some time to learn all there is to learn about this machine, but, ultimately it is knowable.

Command and control was considered a way for managers to keep the machine in working order. So complicated means not simple, but ultimately knowable.

Appelo, on the other hand, describes what we know to be true of organisations today – that rather than them being complicated, they are in fact complex.

What is the difference between complicated and complex? Well, picture a rainforest and you can imagine complex.

A good friend of mine’s parents had a holiday house smack bang in the middle of a forest east of Melbourne. I found it a restful place – the river, the bird life and the amazing towering trees. This couple found it less so. So relentless was their weekend activity of cleaning bird poop off the veranda and sweeping the forest floor free of leaves, that they eventually sold the property.

A forest is a complex system. Complex systems exhibit:

  • Feedback loops – part of an output is used for new input
  • Spontaneous order
  • Hierarchical organisation
  • Emergent organisation
  • Numerosity – or an indefinite quantity of individuals

Other examples of complex systems are ecosystems, the universe, Earth’s global climate, the human brain, the stock market, a living cell and even organisations. Appelo describes complex as not simple and never fully knowable, given that too many variables interact.

The current thinking on organisations is that they are in fact complex adaptive systems. A complex adaptive system is a dynamic network of interactions. It is a system in which individual and collective behaviour mutates and self-organises, corresponding to a change-initiating event or collection of events.

Steve Denning also regards organisations as complex systems, but he remarks that it is the shift from semi-skilled to knowledge work, that means we need to re-examine the “unspoken assumptions…of the inevitability of … the practices of traditional management” such as command and control.

The management expert Peter Drucker notes that “Workers throughout history could be ‘supervised’. They could be told what to do, how to do it, how fast to do it and so on. Knowledge workers cannot, in effect, be supervised”

Perhaps the relentless bird poop cleaners and forest floor sweepers were a bit like command and control managers trying in vain to control an ever changing complex adaptive system.

How then can leaders of today enable self-organising teams to contribute and thrive within such an ecosystem? This introduction is the first of an eight part blog that tackles leadership for an Agile organisation.

Read on to understand the new four-fold role of Agile Leaders.

Agile Maturity Checks – Use with Caution!

1 Reply

Agile maturity check

Just saying it like it is. My favourite Agile maturity measure is the one in the picture above! I like to invite a team starting out in Agile to create a histogram of how they as individuals feel about their comfort level with Agile. I know that Agile maturity checks are loved by management, but I think they’re less useful to teams.

At work I put some time and thought into developing a maturity model that spans Lean system thinking, Lean Startup, Agile and DevOps practices. I modelled it on Spotify’s team health check, which I do feel is really useful. This maturity check was only moderately useful. I suspect that if you do use it, you’ll make an early maturity team feel a bit depressed and inadequate.

My thinking behind this model was to set the bar of early maturity where a non-Agile team taking their first steps might find themselves. My scale ranges all the way up to mature, which is good practice and I hope, not too aspirational.

It might be most useful to use components of it, if a team discloses a particular area they want to address. The next step might be to use a retro to generate ideas about how they could get from “not yet” to “on the way”.

Take a look at it and use with caution!

  Not yet On the way Mature
Standups We don’t run standups. We run standups sometimes. Standups tend to run over the 15 minute mark. We can’t always see the point of standups. We run standups every day and stick to the questions: what we did yesterday, what we did today, and what obstacles we need to resolve. Standups never exceed 15 mins.
Team rhythm As a team member I’m either too busy or not invited to attend all the Agile ceremonies – standup, estimation, sprint planning, showcase and retro. I mostly attend those ceremonies that I’m invited to – standup, estimation, sprint planning, showcase and retro. As a team member, I attend and contribute to all Agile ceremonies – standup, estimation, sprint planning, showcase and retro.
Process Our way of working is painful. Process gets in the way of us getting stuff done. We have a way of work that is sometimes easy and sometimes hard. It would be great if our process fit us better. Our way of working fits us perfectly. We have just enough process to get stuff done easily.
Speed We never seem to get done with anything. We keep getting stuck or interrupted. Stories keep getting stuck on dependencies. We get through stories, but there are frequently blockers, or process glitches. We get stuff done really quickly. No waiting, no delays.
Requirements Our Agile stories are place-keepers for the work we do. We use BluePrint to articulate our requirements. We are using Agile user stories, but our stories are sometime technical tasks derived from specifications. Our stories are not consistently small, estimable, and independent Our user stories are not derived from a formal documentation process but are captured as business value. They are always small, estimable and independent. We always include acceptance and test criteria.
Analysis Time pressure usually prevents us from having our stories articulated before bringing them into a sprint. We do this during the sprint. Our aim is to get stories ready for a sprint, but accept that sometimes the work just needs to be done, so articulation of stories takes place during a sprint. We have a clear “Definition of Ready”, so we never bring stories into a sprint unless they are fully articulated, including a story statement, acceptance criteria and test criteria
Sizing We aren’t yet sizing our work before bringing it into a sprint. Several team members get together for sizing. We mostly have stories estimated before we bring them into a sprint. We have a regular rhythm of story sizing and involve the entire team in this process.
Velocity We use the stories in a sprint as a guideline or focus for our work. We never complete the stories we plan to complete in the sprint. We sometimes finish stories (including testing) in the sprint. As a team we always finish all the stories (including testing) we commit to in a sprint.
Sprint planning We aren’t yet conducting regular sprint planning. Several team members get together for sprint planning. Sprint planning usually happens, but we usually carry over stories not completed from the previous sprint. We have a regular rhythm of sprint planning that involves the entire team. We all commit to the work in the upcoming sprint and are confident we can complete it.
Agile wall We don’t yet have an Agile story wall. We have an Agile story wall, but it doesn’t necessarily reflect what we are working on, or what is in JIRA. Our Agile story wall is not hugely relevant for us in standups or our daily work. Our Agile story wall is our key source of truth about the progress in a sprint. Anyone looking at it can see exactly what we are working on and where we are up to. It matches what is in JIRA. We use it both in standups and the daily work we do.
Showcasing We aren’t yet showcasing. We showcase when we have something tangible to show stakeholders. This can be between every second and fourth sprint. We have working software to showcase after every sprint. We invite key stakeholders to this showcase and our developers run through what has been built.
Retrospectives & Learning We aren’t yet running retrospectives. We never have time to learn anything. We are too busy for retros and cross team showcases. Time permitting, we run retrospectives. This doesn’t necessarily happen after every sprint. We’re learning lots of interesting stuff all the time. We run retros every sprint. We initiate and participate in cross team showcases.
User experience support
 We are struggling to understand what role User Experience designers play in defining our product and where they fit into the lifecycle. We sometimes tap into the skills of User Experience Designers, but often time pressure prevents us from working closely with them. We have complete clarity on the role of user experience designers in our product development. We integrate their work into stories across all product builds.
User experience integration
 We often find we don’t have time or resources to integrate qualitative (through UX testing) or quantitative (through integration of analytics) customer learnings. We integrate some qualitative and quantitative customer learnings into what we build, but we rarely have an opportunity to run another iteration to further improve our product. We integrate qualitative customer learnings (through UX testing) and quantitative (through integration of analytics) into every feature/initiative we build and deploy.
Testing Testing is owned by the QA/Tester. Functional, non-functional and integration testing is performed at the end of the lifecycle, not necessarily within a sprint. Testing is shared by the QA and Dev. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Testing is owned by the QA, Dev and BA. Non-functional and integration testing undergo complete inspection tests. Functional testing is integrated with the build. Developers practice Test Driven development (TDD).
Build Build is manually performed custom or repeatable, but still manual. Build is performed infrequently. One member of the team owns build. Build is repeatable and automated, but doesn’t happen with maximum frequency. Build is the responsibility of the team. Functional Testing tools (Watir, Selenium, etc) are integrated as gatekeeper events to the build. Integration tests with external tools and products.
Releasing Releases are extremely difficult. Our preference is to release at the end of the project. Releasing is tricky, so we aggregate as much work as possible before releasing. We have a regular rhythm for releasing. It is fast and painless
Collaboration & Communication We consistently find it difficult to get answers to our questions, or resolve issues in a timely way. It is sometimes difficult to get someone in our team to help us out, or resolve a problem when we need it. If we need somebody in the team’s opinion or assistance, we can freely ask that person either at standup or throughout the day and expect a prompt response.
Empowerment – ways of working It’s the job of leadership to suggest how we can work better. It’s sometimes difficult to get traction on improved ways of working, but we give it a go. We feel empowered to suggest how we can work better. Our suggestions translate to real improvements in the way we work.
Empowerment – product We don’t have any understanding of how the customers are responding to the product so we can’t calibrate it. We sometimes hear feedback about our customers’ responses to our product, but incrementing the product in response to this only sometimes happens. Our regular cycle it to respond to learnings from customers. It shapes our backlog.
Contribution We complete our work, but it’s not always clear how the tasks we are performing are critical to the success of the team. We know that the tasks we are performing are critical to the success of the team, but sometimes it doesn’t feel so – . Every day we are at work, we know how our work contributes to delivering a great product. We own creating a great product.
Fun &
Celebrating
Success		 Boooooooring. We do not celebrate successes. There are some smiles about, but celebrating success isn’t something we really do as a team. We have great fun working together. We find ways to celebrate our success.