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

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

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

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?

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


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.

The key indicator of successful Agile transformation

Beware of cows

Photo: enjosmith, Flikr

Is sustainably faster delivery of customer focused solutions the key measure of a successful Agile transformation?

It’s a great measure, but it is of course a lagging indicator and not a leading indicator. By this I mean that you can’t know if you have achieved faster time to market until you have achieved it.

What leading indicators (or factors that change before a system starts to follow a pattern) can you measure and influence to see success in Agile transformation?

Brad Swanson’s approach to measuring leading indicators that influence sustainably faster delivery of customer focused solutions is terrific. I’ve adapted it here and added more:

Alignment of organisational priorities with customer value

  • How frequently do stakeholders collaborate on prioritisation?
  • How effectively are they collaborating?
  • Is there a standard way to compare the business value of initiatives?
  • Are portfolio priorities highly visible?

Growth of Agile practices

  • How many people are trained in Agile?
  • How many people in teams are coached?
  • How many leaders are coached?
  • How many Agile practices are leaders using?

Alignment and support across the organisation

  • Is there senior leadership consensus on strategy?
  • How frequent are communications on vision and strategy?
  • Across what different forums is vision and strategy communicated?
  • Are short-term wins visibly celebrated?
  • How many hours is the Guiding Coalition working on activities?

Engaged happy people

  • When polled, do people feel things are getting better or worse?
  • Are there defined career paths for all roles?

Culture of continuous learning & improvement

  • What is the average frequency of team retrospectives?
  • When polled, do people feel safe to experiment and fail?
  • What is the number of experimental learnings celebrated?

Transparent empirical view of organisational improvement

  • Are metrics on organisational improvement visible to all?
  • Are results communicated?

Incremental delivery

  • How many projects are running concurrently?
  • What is the average number of concurrent projects per person?
  • How healthy are the program burn up charts?

So if you’re looking to tell the story of Agile transformation on a single slide, by all means map deployment frequency. The rest of the story is of course in measuring and influencing the above leading indicators of success.

The 3 key questions to get a user story to “Ready”

Sample KanbanCoaching Agile Scrum and Kanban teams, I frequently see bottlenecks when user stories that aren’t quite “Ready” find their way into development.

These three questions confirm if a story is “Ready” to be brought into a sprint, or pulled into the in-progress column in a Kanban flow.

1.  Are the boundaries of the story clear?

A good story statement should confirm where the user story starts and ends. For example: As a user who has logged in and wishes to update my password, I want to see an update password screen, so that I can enter a new password and hit submit. The acceptance criteria for this user story will confirm what the update password screen needs to look like, validation rules for the new password and encryption of the password.

A team reviewing this user story would understand that a response screen is not within the boundaries of this user story and will need to be covered in another user story.

 2. Do we know how to build and test this story?

Ask this question to disclose if the people building and testing the story have complete clarity on how they are going to do it. If the answer to this question is “No”, then the story isn’t “Ready” and the team needs to run a tech spike or research spike.

 3. Is the story small enough?

My (frequently articulated) preference is for small stories. I like small stories for all the reasons above – the boundaries are clear and it’s easier to validate we know how to build them. I also like small stories because you can easily bring them into a sprint or Kanban flow without sizing them.

If you are running Scrum and sizing stories, what’s critical is to ask if the story is small enough to complete within a sprint.

Kanban teams will be acutely aware that any story that is too big will create a flow problem, preventing other stories from being pulled into in-progress. To improve your average lead time from, for example, two weeks to one week, ask the question “Is this story small enough to be completed in a week?” If the answer is “No”, then use your toolbox of story splitting techniques to break it down further.

What Agile Teams Learn from Toyota about Definition of Ready

What Agile Teams Learn from Toyota

Photo: Toyota Manufacturing UK – Assembly, Flikr

Getting stories to “ready” is crazily important for Agile teams. My recent field trip to Toyota made me think more broadly about what ready means.

By “ready” I’m referring to having stories articulated ahead of a sprint commencing. I usually advise software teams to include the following in their “Definition of Ready” (their checklist of what needs to be done before a story can be commenced):

  • Clear story statement
  • Articulated acceptance criteria
  • Reference to a process map (if required)
  • Wireframe (if required)
  • The team understands the story
  • It has the Product Owner thumbs up

The Toyota equivalent of ready is a self-driving trolley that arrives at the operator’s station just in time to supply, for example, the wheels for the next vehicle on the assembly line. The passage of self-driving trolleys around the factory floor, playing individual music to alert the operator of approach, is in and of itself ridiculously impressive.

It is Toyota’s lean approach to managing the whole supply chain though, with offsite manufacturers producing, packaging and dispatching the various wheels in the correct order, that takes ready to a whole other level.

What can Agile teams learn from this?

Remember that you are part of a system – seek to include your stakeholders in getting to ready

Ask yourself, who in Legal, Product, Marketing, Learning or Architecture needs to understand, or be involved in defining the story before it is considered ready?

Value your suppliers – they are critical to your system

Toyota understands that their success depend on their suppliers. They provide clarity of expectations.

Influence your ecosystem – educate as required

Do all your stakeholders or suppliers understand their role in Agile product development? If not, find a way to explain it to them and support them as they come up to speed.

Listen to your Developers – they understand ready better than anyone.

At Toyota, if wheels don’t arrive at the right moment, fitting them cannot be completed within the takt time. Our takt time is a sprint. We should have no lesser sense of urgency than Toyota’s 90 second takt time. Ask Developers ahead of a sprint, “Do you have everything you need to complete this story?”, and listen to their response.

Make your team’s model “ready set flow”

Emphasise the connection between ready and overall sprint flow. Encourage Product Owners and Business Analysts to make the workflow of getting stories to ready visible on an Agile wall. Get them talking about these efforts at standup, so everyone in the team feels empowered to flag obstacles to ready.

How small Agile teams succeed – & win wine of the year!

How small Agile teams succeed

Photo: Tim Williams, Flikr

Late last year, Australian wine critic James Halliday, selected a micro winery’s 2014 Shiraz Viognier, as Australian wine of the year. Asked on radio, how the tiny Serrat winery’s $40 bottle of wine, could compete with big wineries, he responded, “it’s attention to detail”. That of course got me thinking about how small Agile teams create quality.

James Halliday expressed better than I, why small creates greatness.

“You have to get the vines absolutely performing at maximum, in terms of quality, not in terms of yield. Because they are by their very nature, small, you can move very quickly. There’s just a very small number of people in the decision making process. There’s no chain of command, or stuff like that. So they decide… let’s pick tomorrow, and no one’s going to say otherwise. Whereas in a big company, you get log jams of grapes coming in from all over the place.”

Small Agile teams succeed because with small there is big communication:

  • Decision making about how to build is by the team
  • The Scrum Master knows where each team member is at, and supports individuals achieve excellence
  • Handoffs are conversations that focus on what’s happened before, and what happens next
  • Each person cares about quality
  • Small can move fast and flex as required

Is small better than big? Well, in terms of wine, it’s certainly cheaper than the $875 a bottle Penfolds Grange that was runner up!

Easy Peasy Agile Leadership

Easy Peasy Agile Leadership

Photo: D Sharon Pruitt, Flikr

I work in Agile transformation, and the truth is, it’s not so easy peasy teaching leaders to change their style. The thing is, the effort to change leaders’ mindsets is worthwhile – it enables Agile teams to thrive.

Traditional managers think like this…

  • I am the manager of my people
  • My team looks to me to solve their problems
  • I shape how individuals and teams work
  • I reward individuals and teams who do whatever it takes to get over the line
  • I expect individuals to develop a learning plan, and if time and budget permit, I support them achieving it
  • I endeavour to reward team achievement at the end of a project, and individual achievement at performance reviews
  • I encourage individuals and teams to innovate, but there’s rarely time to do so

 Agile leaders think like this…

  • I lead through vision, but support as a servant
  • I set the mission, but decentralise problem solving
  • I trust individuals and teams to shape how they work
  • I reward individuals and teams who work at a constant sustainable development pace
  • I am a driver for development of learning opportunities, and make time for my people to achieve their goals
  • I acknowledge the achievements of individuals and teams spontaneously, and encourage celebration of success
  • I foster an innovation culture of cooperation, risk sharing and acceptance of failure in order to learn

What case do you put to leaders to make their mindset Agile?

Agile Leadership:

  • Supports teams working Agile, so we build better products and release more frequently
  • Emphasises continuous improvement, so teams become more productive
  • Increases sharing of best practice, so we keep upskilling our teams
  • Gets teams working at a sustainable pace, so there are fewer absences
  • Enables happier, more autonomous humans, so we retain our people
  • Builds an engaging workplace, so potential employees choose to work for us

If leaders in your organisation still aren’t convinced, then think about quantifying the benefit of better products more frequently, more productive skilled teams and retaining great people!