Agile Coaching Blog

When I talk with customers about their Agile adoptions, one challenge that comes up repeatedly is “middle management”. What is their role? How does management change in a self-organizing and team-based environment? Will they participate in the Agile transformation? Or will they subvert it?

I believe that the Agile community is struggling to provide clear guidance on the role and value of “the manager” in an Agile organization. There are some great ideas out there, for example, Esther Derby has recently covered the topic in-depth in her blog posts (good examples here and here). Lyssa Adkins and Michael Spayd attempted to address this issue several years ago (see here). Jurgen Appelo wrote a great book on the topic as well.

And still, I find that the vast majority of people going through large scale Agile transformations struggle to understand the role and value of managers.

teamwork

The Power of Agile – What Customers Say

I care about this because I am one of those managers. I believe that Agile practices and ideals are the bee’s knees, the cat’s pajamas, the crown jewels. They promote giving people the respect and responsibility they deserve. We shift our thinking from aligning resources to work to instead aligning work to teams and empowering those teams to determine how to deliver. We respect the team and each member of the team for their experience, expertise and know-how. And we trust them to make and meet commitments. In these ways, and many others, Agile practices help us create environments where empowered people can collaboratively solve the world’s toughest problems.

One of our largest customers recently sent out an internal newsletter with the following update from its teams who had adopted Agile practices:

How has Agile helped?

• It has helped us embrace a “one team” mentality.
• Cooperation and mutual support have been key to success:
  • Developers help with QA
  • Cross-training allows the team to ‘swap’ stories and accomplish them quickly
• Open communication and teamwork drive efficiency.

We hear this story over and over again from our customers. We work smarter, better, more effectively, and as a result – we are happier. It’s a lot of work to be Agile — it takes rigor and discipline – it doesn’t just “happen”. It’s something we practice, we experiment with, we hone. And something that is never quite finished – Agile is an ongoing learning process.

That kind of attention, focus, discipline, and dedication requires a lot of effort. We put our hearts and minds out there. We are vulnerable. We are open to learning — good or bad. We strive to succeed and we are willing to fail.

Healthy and Unhealthy Teams
We create support systems to help with all of this and we call them teams. Teams have received both good and bad press recently (and deservedly so). Healthy teams are amazing places where people experience personal growth, camaraderie, success, and happiness. Healthy teams perform outstanding work.

And then, unfortunately, there are unhealthy teams. Teams created without rationale or purpose beyond merely a financial yet empty commitment to the concepts of collaborative work. These teams lack shared goals and measures and the team is nothing more than a box on an org chart.

In all teams, healthy or unhealthy, there are highs and lows. There are personal connections that ebb and flow in terms of strength and positivity; there are turf wars and politics. There are big wins and group hugs. There is change. There is the strange gravity of the status quo. Even when we know that change will bring us to a better place, it’s always hard to overcome the pull of the past and the inertia of “that’s just how we do it here”. We are, after all, only human.

For all of the struggles of being a team, Scrum has given us a great gift, the role of the ScrumMaster. This role, with responsibility not to dollars or dates or deliverables, but instead to the success of the team, is a stroke of genius. It is a true sign of the power of a healthy, performing team.

Bad managers

The Manager as Champion

But where is the person dedicated to each individual’s success and happiness? Where is that partner in personal growth, that leader in professional direction, that sounding board, that champion, that servant leader dedicated not only to the success of the team, but to the success of the individual?

Yes, there are bad managers. And we know who they are. We know why they aren’t succeeding. We shouldn’t let their mistakes spoil our perception of the role. The great managers deserve a tip of the hat, a nod of appreciation, a “thank you” for being there through all of this change.

In this world of shared responsibility, collaborative work, and teams, we desperately need the advocate for the individual, the champion for the person — we need managers.

Rachel Weston

Rachel Weston is currently Director of Services at Rally. She is a certified Scrum Trainer and Agile Coach and has been with Rally since 2007. Rachel holds a BA degree in Mass Communications from UC Berkeley and a Master’s degree in Linguistics, Human Language Technology, from the University of Colorado at Boulder.

I live in Brighton, on the south coast of the UK, about 50 miles from London. This means that I regularly catch the train for meetings or engagements “in town”. When making the journey, I always look at the timetable. Trains only run every 30-60 minutes, so if I get the timing wrong, then I’m most likely left hanging around at the station. Not a great use of time, especially with the typical British weather. When I get into London and need to catch the tube somewhere, however, it’s a different story. I just head to the right platform and wait for a train, knowing that one should turn up in a few minutes. There’s no need to check the timetable.

Using the tube is more efficient than waiting for the next train.

What does this have to do with Agile? I was recently on a Q&A panel and fielded a question about how to deal with fixed date and scope projects. The story above hints at the answer…

Managing Variables

Before we come to that, let’s first look at the common ‘Iron Triangle’ variables of time, cost and scope. If the date (and hence time) and scope are fixed, then logic suggests that the only thing we can vary is cost. This typically means adding people, although it could mean throwing money at the problem in some other way. Brooks’s Law, “Adding manpower to a late software project makes it later”, says that this will not work. An Agile approach can mean that any problems meeting the date and scope will be discovered earlier, and hence the effect of Brooks’s Law can be minimized. Colleague Alex Pukinskis recently blogged about how the Rally development team cheated Brooks’s Law with such an approach.

If varying cost isn’t an option, then there are a couple of other options. The first is cutting corners and reducing quality. Note that I am not recommending this option! Having said that, if the date is critical for learning and feedback regarding a value hypothesis, then quality may be less critical, assuming quality will be built in once the value is well understood.

The other variable is fidelity — this is the finesse of the solution. Delivering a low fidelity solution first ensures that scope can be met early. The functionality can then be iterated on to increase fidelity, knowing that when the date arrives — scope is in the bag.

The Alternative

There’s a less obvious solution to the problem, however. Date and scope are often fixed as a reaction to the risk of “missing the train”. We want to be sure of what we get, and when we get it, because if functionality doesn’t make it into a release, we don’t want it left on the platform waiting for the next one. We can address that risk in another way.

Going to the local market three times a week reduces the overhead of planning for a big shop.

Here’s another example. We (ok, well, my wife) generally do a weekly shop at a nearby out-of-town supermarket. Because it’s weekly, we spend time planning by putting together a shopping list, thinking of everything we might need during the week. After all, if we don’t get everything we need, it will be another week until the next shop. This often results in over-stocking and the waste of throwing out unused perishable food.

However, when we go and visit a friend who lives in the small village in the Lake District, we just pop into the local shops every day to get whatever we fancy for that day. There is no need to plan ahead or make decisions on what we are going to eat days in advance. The local produce might be slightly more expensive than the big supermarkets, but it’s higher quality and there’s less wasted food. We trade-off a slight increase in cost for higher quality, deferred decisions and less waste.

So instead of worrying about how to deliver to fixed time, scope and cost constraints (not to mention quality), I would recommend figuring out how to release more frequently.

If your releases are like a tube train, arriving every day or so, then the need to plan time and scope lessens. Planning and implementing in smaller batches significantly reduces the cost, allowing more time to build the desired scope by the desired date. If a feature misses a release, it can just go into the next one straight after.

Try this approach and let me know how it goes!

Karl Scotland is an Agile Coach for Rally and founding member of the Lean Software and Systems Consortium. In his 15 years of experience, he most recently has been a pioneer and advocate of using Kanban Systems for software development. Karl also blogs at AvailAgility.

The UPS delivery guy came by our house the other day. Not so unusual, since he comes by our house on a regular basis. The box he dropped off, however, was oddly more exciting than a new batch of power bars, cat treats and other miscellaneous household items we usually get. This time he brought something really good, a copy of Mike Griffith’s new book, “PMI-ACP Prep, Premier Edition: A Course in a Book for Passing the PMI Agile Certified Practitioner (PMI-ACP) Exam, a gift from his publisher in preparation for our upcoming webinar together, PMI-ACP℠: Adopting Agile into the PMP World. I love getting new books! And this one was even more special in that it made me reflect on my personal journey with Agile and the PMI.

In 2003, while working as a Project & Program manager for a global software company, I was tapped on the shoulder to be part of an Agile pilot team. It certainly was an interesting challenge; our mission was to replace a legacy system with a new system. Without much information, and only limited training, we got started.

Since I had to co-exist with traditional project managers for an extended period of time, in 2004 I decided to obtain my PMP certification. My goal was to have a shared understanding of project management with my “traditional” project managers. I discovered a few things during this journey:

1. The PMBOK (Project Management Book of Knowledge) doesn’t dictate that projects have to be delivered using plan-driven or waterfall (this was, however, the norm at my company at the time).
2. You don’t have to choose to be either a traditional project manager or an Agile project manager – I’m living proof!

So back to the PMI-ACP. I attended my first Agile conference in 2005 and know that the Agile community has been debating certifications for years. When I first heard about PMI’s Agile Certified Practitioner offering, I was curious about a) how the PMP audience would react, and b) how the PMI would even create this exam and certification since Agile is an umbrella term for many different frameworks. It is contextual in nature, and the Agile community even still often debates what is and isn’t “agile”.

I was part of the first group to take the exam and early this year became a PMI-ACP! The time is right for this certification – Agile has crossed the chasm. And the PMI-ACP will provide value to PMPs and to organizations looking for people with real Agile experience, as well as the backing of the PMI.

I appreciate the committee (of which Mike Griffiths was a member) that worked with the PMI to create the exam. It wasn’t a trivial project, and I believe they did a great job in encompassing all the different Agile frameworks. I am enjoying Mike’s book and highly recommend it. It will provide you with what you need to pass the exam and beyond.

Our webinar is tomorrow and I’m definitely looking forward to picking Mike’s brain about the exam, certification and process to develop it. I’ve started lining up all my questions, but there’s room for more. If you have a burning question you want me to ask Mike, send it my way. I’ll be sure to add it to my list.

Julie Chickering is an Agile Coach at Rally Software. She is a board member of the Agile Project Management Network (APLN) and a co-founder of the Dallas chapter of the APLN.

The last part of 2011 saw a wealth of Lean and Kanban conferences in Europe, which Rally Coaches Karl Scotland and Katherine Kirk took an active part in. Was this surge of events a sign of what’s to come in terms for Agile processes in 2012? Here, we summarise our understanding on where this community currently is,

Illustrations of my "Science of Kanban" talk at LKCE

and where it could potentially head after learnings gathered from Agile Lean Europe (ALE), Lean & Kanban Benelux (LKBE), Lean & Kanban Central Europe (LKCE) and Lean Enterprise Software and Systems (LESS).

A Community of Chefs

Dave Snowden, who spoke at both ALE and LKBE, uses the analogy of chefs and recipe followers to make the point that we need to learn the underlying theories behind practices if we are to evolve and scale them in new ways. Chefs are able to improvise with the ingredients and materials available, whereas recipe followers can only repeat previous instructions.

To follow this analogy, a common theme across the conferences was the pulling of knowledge and new ideas from a number of sources more than ever before. Notable speakers from other fields were John Seddon, Don Reinertsen, Stephen Bungay, Bjarte Bogsnes and Steve Denning. Thus rather than try and improve their “Steak and Chips”, the community is looking to create “Chop Suey”, mixing together a range of ideas, or even creating brand new dishes.

Expanding Horizons

As new ideas are tried to solve challenges in a wider set up of scenarios, the number of organizations who are able to benefit from a more Agile approach is increasing. Demand or service based companies who do not have long-term projects, or more product focused companies where software is part of a bigger initiative including mechanical or electrical engineering, are able to create new situational approaches where existing popular approaches are not appropriate.

The result of this is that the community is focusing more on how to improve organizational outcomes by taking a context-driven approach that places more emphasis on evolving from the current state, than moving to an anticipated future state. While this may seem to be a slower path to success, it is proving to be valid and palatable method of helping organizations meet their market needs and respond to customer demand and competition.

Not Forgetting Humans

Since the first UK Lean Software and Systems Consortium conference in 2010, the community has been conscious that any Lean and Kanban approach still has human beings at its core. To continue the food analogy, any dish that is created must still be tasty and nutritious.

The community is aware that whatever visualizations are used in a Kanban system, they should be geared towards interactions, communication and collaboration between people, and that logical responses to the visualisation are not guaranteed. A Kanban board will bring human issues to the surface, and practitioners are beginning to look for ways and means to handle this. The Agile community has a wealth of knowledge from the human perspective that we can draw on. In particular, Alistair Cockburn’s Crystal family of methodologies blend well with a Lean and Kanban approach.

Looking Forward

The Lean and Kanban community is in a state of healthy experimentation, adopting a philosophy of continuous improvement. However, there are indications that the need for sustainable consulting businesses may lead to a solidification of approach in order to make the consulting dollar. The challenge is how to avoid Lean and Kanban becoming another fad, preserving a healthy state of discovery in the community while maintaining the ability to help newcomers to these approaches.

It will be interesting to see whether Lean and Kanban continues this journey or begins to solidify its practices for financial gain. It will also be interesting to see where the next month’s Cynefin Agile & Lean Mashups (CALM) Alpha event in the UK will take this community and school of thought. We shall see…

Karl Scotland is an Agile Coach and founding member of the Lean Software and Systems Consortium. In his 15 years of experience, he most recently has been a pioneer and advocate of using Kanban Systems for software development.

Katherine Kirk is an Agile Coach also studying an MSc in Software Engineering at University of Oxford, and an active participant of a community of Lean and Agile practitioners.

I’m not a smoker but I know a little about smoking. My mother smoked her whole life. It eventually killed her. I never did understand the grip it had on my mother and those like her until I read Malcolm Gladwell’s The Tipping Point.

“Teenage smoking is one of the great, baffling phenomena of modern life. No one really knows how to fight it, or even, for that matter, what it is,” Gladwell says.

Gladwell goes on to point out that education has not been effective. In fact, it is not that teenagers don’t understand the dangers. In fact, they believe smoking to be more dangerous than it is.

Now what has this got to do with product development, you might ask?

Well, it seems as product development teams, we have a similar addiction that affects our ability to deliver value and create a sustainable pace.

Despite the best efforts of Covey and others to educate us, we continue to multi-task, constantly change priorities and work our most valued contributors to the point of exhaustion. We know the hidden costs. It is not that we lack intelligence. In fact some of our most ambitious and driven companies seem to be where this culture is most pervasive.

Why do we do it? Why do we continue to reinforce the superhero culture?

Gladwell provides clues to the answer, saying: “The significance of the smoking personality cannot be overstated, If you bundle all these extrovert’s traits together you come up with an almost perfect definition of the kind of person many adolescents are drawn to. Maggie, Pam and Billy were all deeply cool people but they weren’t cool because they smoked. They smoked because they were cool. Smoking was never cool. Smokers are cool.”

We know the superhero culture is bad for us, but it persists.

It persists because we want to feel needed. We want to feel indispensable. We find it easier to be reactive than proactive. We love the sense of urgency and get a buzz from putting in the extra hours and saving the day. But most of all the culture persists because the cool people, the leaders – the people that many look up to and strive to emulate – got where they are through their own superhero efforts.

About the Author: Ken Clyne is a 26.2 finisher, Certified ScrumMaster and Agile Coach at Rally Software.

Over the past several months I’ve had a recurring conversation with various large, enterprise organizations transitioning from traditional approaches to more Agile methods.

The topic of this conversation has been a discomfort with User Stories, and a desire to maintain their investment in Use Cases.

These organizations come to this conversation hesitantly, but steeled for battle – convinced that I am going to try and dissuade them from their ‘un-Agile’ ways and insist that they adhere to Agile ‘best practices’.

They’ve been generally surprised by my response, so I thought I’d share it here:

‘I actually really like Use Cases; though I tend to use them a little bit differently than it sounds like you are.  I actually combine them with User Stories. But before I tell you how I do that, let me ask you a question –

Why do you want to keep Use Cases?’

‘Why’ is always a tough question, so we ramble around a bit, but we ultimately get to the point where we say that the Use Cases have 2 primary purposes:

1. 1. They provide a reference for all the details of what we’re doing while building and testing
   2. They provide a history of what was done, and how the system behaves

At which point I tell them, “that’s perfect, because that’s pretty much what I’ve used them for too.  What I find all too often is that organizations have a 3rd, hidden purpose for Use Cases – they provide an alternative to talking to each other…”

They look at me kind of funny and I continue –

“See, in those organizations they view ‘good’ requirements documentation – whether in Use Case format or otherwise – as a stack of paper that they can drop on a developer’s desk, so that the developer doesn’t need to talk to anyone.  If the developer does need to have a conversation with the analyst (or, God forbid, the customer) then that’s a sign of bad or less than ideal requirements documentation – that we didn’t really specify them in enough detail…”

Usually there are a few knowing smiles and nodding heads at this point, so I continue -

“So let me tell you how I’ve used Use Cases.

I start with a list of Use Case titles – basically a Use Case Catalog.  They generally look something like:

‘As a <User Type> I need to <Activity> so that <Business Value>.’

We called that our Initial Backlog.

Now, those probably look a lot like User Story right?”

They nod.

“Well, yes and no actually.”

They then squint at me.

“See that’s just a Story CARD, which isn’t really a story – it’s a ‘reminder to have a conversation’ – which is where the STORY comes from.

We have those conversations on a just-in-time basis of progressive elaboration that we called Backlog Grooming.

Now obviously we don’t want to keep having the same conversations over and over again, so we need to capture the results somehow, so we can refer back to them to know what we’ve discussed; and so we can update them if subsequent discussions lead to changes.

For some teams, the best way to capture those details is with activity diagrams, state diagrams and wireframes.  For others its a bulleted set of Acceptance Criteria and notes.  And for others it might be Use Cases Scenarios with a data dictionary, business rules and other attributes…
In fact, it might be any combination of those things based on the story and the preferences of the team.

I’ve worked with lots of teams that used the Use Case format as their means of capturing the results of conversations.

And many of those teams were obligated to provide requirements documentation as part of their product – for regulatory or governance purposes, or as an artifact for support and maintenance.

So, for those teams, we made having an up-to-date set of Use Cases part of our Definition of Done. Having up-to-date Use Cases allowed us to keep our product Potentially Deployable – which included meeting regulatory and governance documentation needs.”

Being Agile doesn’t necessarily mean discarding everything you know.  And it certainly doesn’t mean blind adherence to a set of tools and techniques approved by the agile police.

Being Agile means holding to a set of values and principles that ultimately come down to customer, value, feedback, quality, transparency and sustainability.

Being Agile means questioning, experimenting, inspecting and adapting, and using what works.
Isaac Montgomery is the harried father of twin sons, a frustrated hack on the golf course, and an Agile Coach at Rally Software. He blogs at Leading Results, you can follow him on twitter at @iwmontgomery

(Note: This post originally appeared at Bobcanhelp.com)

This week I went to Connecticut to deliver an Agile Intro to the IT management team at a new client. During the prep call I asked, as usual, what their desired outcomes for the day are, and was told, “we want a clear picture of Agile Perfect”.

This is a lovely goal on the surface, but contains assumptions that may not be so useful. Let me explain.

Agile is iterative – not only for software releases but also in terms of process and organizational capability. When we transition an existing businesses from waterfall or chaos to a disciplined Agile system we work evolutionarily not with big bang changes. At least not at first.

That is we start with where they are now and look for the highest value next steps – what design thinking and evolutionary biology call the Adjacent Possible. The goal is to create a learning organization that continuously improves not a perfect static system.

Think of the deep past of this planet when single celled organisms were the most complex forms of life. At this time there was potential for all we have now – sunflowers, cats, honey badgers and humans – but they were not yet possible. Biology had to take it’s time and iterate towards increasing complexity until the sunflower was the next potential item on the evolutionary backlog.

And so it is with organizations. Sustainable change happens iteratively and incrementally. While it’s important to have a strong view and discipline around what it means to be Agile it’s not useful in the beginning to spend too much time envisioning an ideal system (though models like Dean Leffingwell’s Scaled Agile Delivery Model are inspiring and challenging to review). It’s far more useful to focus on the next step that is possible for the organization as it is.

The client in Connecticut for instance realized after our session that their next most important step was getting buy-in on Agile principles from the business side. IT is already on board but without support from the product people the transition will likely falter and fail.

While a vision of an Agile Perfect world is desirable there is far more value in focusing energy on the Adjacent Possible. And once achieved, the next horizon of possibility will come into view.

What’s the next step your organization can take? What’s the adjacent possible? What feels out of reach?

Bob Gower is an Agile Coach at Rally Software. You can find Bob on Twitter at @bobgower and at Bobcanhelp.com

(Note: This post originally appeared at Bobcanhelp.com)

Whenever I work with new teams I always ask, “who here has been on a project where adding people actually slowed progress?” Inevitably at least half the people in the room raise their hands.

The reason this is so common has its roots in one of the most damaging, insidious and pervasive mindsets I see in the businesses I work with. It can be summed up in a single word: resources.

This word saps the energy and enthusiasm of those whose creativity and engagement we need most — the people who design, build and innovate our products. It also causes us to structure businesses in highly inefficient ways resulting in poor quality, unhappy workers and waste-filled production cycles.

First off being called a “resource” can siphon off pride and engagement making you feel like a wear part on an assembly line, and can also promote this kind of thinking among managers. But the real problem goes far deeper than the dehumanization the term invokes.

At the heart of the word “resource” is the idea of a fungible unit that can be moved from project to project or even partially allocated to more than one project. This misses a fundamental point about what it means to be human and therefore what it means to build a great business.

Humans are hard (and soft) wired to work with other people. Biochemistry, brain science, sociology, psychology, anthropology and economics all tell us the same thing: people work better when we work together. We’re happier, more productive and healthier. We live longer, report fewer health problems and greater life satisfaction when part of a community. We’re also more creative and engaged.*

But to reap these benefits we have to be in sustained contact with a core group.  When a person moves (or is moved) from project to project they switch context continually, never get up to speed, fail to form deep trusted connections with coworkers and are easily overwhelmed by competing demands.

In order to move beyond this kind of thinking we need to look at our language and attitudes but more importantly we need to rethink how we structure our organizations.

Here’s a cheat sheet:

1. Resources are people.
2. People work best with others.
3. Teams work best when stable.

Good managers and executives therefore build stable teams and move the work to the teams. They don’t “allocate resources” to projects.

This kind of team-based thinking and organization promotes innovation, quality and speed. And I predict the most competitive and profitable companies of the next 10 years will be the ones who are most able to create management systems based on empowered, self-organizing and self-managing teams.

And in order to get there they’ll need to rethink reporting structures, performance reviews and compensation schemes along with the org chart and management culture.

I’ll have more on this in subsequent posts. In the meantime tell me what interests you so I know what to write about.

What would change in your business if your adopted these guidelines? What’s stopping you from starting now?

– — –

* For more on this see The Happiness Hypothesis (one of the most important books I’ve read this year)

Bob Gower is an Agile Coach at Rally Software. You can find Bob on Twitter at @bobgower and at Bobcanhelp.com

(Note: This post originally appeared at Bobcanhelp.com)

Speaking with Geoffrey Bourne (SVP at a large financial institution and Agile aficionado) over dinner recently, my thinking arrived at a sticky yet significant point about the role of management in creating organizational Agility.

Management layers in large corporations are numerous and are built on a top-down reporting and power structure. In such environments command-and-control mindsets are crucial for career survival and reinforced by almost every aspect of an organization from the org chart to the placement of desks.

Yet Agility depends on bottom-up empowered lines of communication and collaboration. And this requires individual and team motivation and commitment. But commitment – the ability to say a powerful “yes” – can only happen in an environment where you can also say “no” meaningfully.

So when an organization attempts to reap the benefits of Agile they must also be willing to give up control. The jujitsu of this move however is that by giving up control you gain power and speed – like a cyclist who takes her hand off the brake and can suddenly travel faster and steer more effectively.

Line management seems to be the key. While executive support is important, their jobs don’t change significantly in an Agile transition – at least not early on. And delivery teams usually get the benefits (and therefore motivation) quickly. It is the managers and business people who work directly with delivery teams who’s lives change the most and unless they are enthusiastic and good managers already Agile will fail.

It now appears to me that when selecting a team to begin an Agile transition, one of the most important filters we can use is to select a project that has a talented, enthusiastic manager (who is not risk averse) already in place. That is they need to be confident and self-aware enough to be able to relax the reigns of command-and-control below while still operating in one above. All they while knowing that the success or failure of the project will reflect on them. A conundrum if there ever was one.

What have you noticed about the role various layers of management play in successful organizational transformations (Agile or otherwise)? What do you look for in a manager (Agile or otherwise)?

Bob Gower is an Agile Coach at Rally Software. You can find Bob on Twitter at @bobgower and at Bobcanhelp.com

In a 1990s version of the Chicken and Egg scenario we witnessed the spectacular rise in popularity of the video projector and Powerpoint.

Dilbert and others have done a lot to help us come to our senses and remind us that (as Garr Reynolds says):

Powerpoint slides are not the “star of the show” and that we shouldn’t let our message and our ability to tell a story get derailed by slides that are unnecessarily complicated, busy, or full of what Edward Tufte calls “chart junk”

So, we need to keep our slides simple. How simple? Garr suggests:

The best slides may have no text at all. This may sound insane given the dependency of text slides today, but the best PowerPoint slides will be virtually meaningless without the narration. Slides are meant to support the narration of the speaker, not make the speaker superfluous.

If you’ve been to a Rally presentation or class you might have noticed we subscribe to the same philosophy. My colleague Ben Carey has taken this to the next level. Influenced by Dan Roam and Sunni Brown he has been experimenting with deckless training using butcher paper and a marker pen. You may not have the confidence in your drawing skills to do what Ben does but, it does illustrate (excuse the pun) that we can succeed without Powerpoint.

Of course, the star of the show is not the presenter, as Garr points out, the real star of the show is the audience and in direct contrast to some of our established paradigms the less the presenter speaks the more the audience learns. As Sharon Bowman discusses in her excellent book Training from the Back of the Room: 65 Ways to Step Aside and Let Them Learn:

If learning is your goal, that is, enabling learners to remember and use the information you give them, then listening to you won’t get them there. What will get them there is involvement and engagement during the entire training – high interest, content-related, physically active involvement – where they are teaching and learning from each other.

Sharon encourages trainers to get to the back of the room and not to talk for more than 10 minutes without some kind of learner activity. This approach dovetails perfectly with the games and exercises we in the agile community have always included in our training but are only perhaps now coming to value for the intangible benefits they bring.

Two excellent books on games are Gamestorming by Dave Gray, Sunni Brown and James Macanufo and Luke Hohmann’s Innovation Games.

Games enable us to get up on our feet, exercise our minds, relax and of course have fun. But games also help us learn to self-organize and work together and can spark innovation as they help us approach business challenges from different directions.

Are games childish? I hope so. I am always amazed at the openness of a childs mind, how easily they soak up new information and how eager they are to learn.

I look forward to seeing you soon at a Rally event or training class where I will I do my level best to:

• not read slides
• train from the back of the room
• encourage you all to be childish

Ken Clyne is an Agile Coach with Rally Software. You can find Ken on Twitter at @kclyne. Ken will be at the Atlanta stop of Rally’s Agile Success Tour on June 9th.