This week, I had the pleasure of attending the seminar “The Way of Artful Making” presented by Rob Austin and Lee Devin , co-authors of the book “Artful Making”.
While I have met both gentlemen separately in the past and heard them both speak, this was one of those golden moments when I was able to hear them co-present. And for me, I loved the odd mixture in the audience: MBA students, MFA student actors, and software engineers. (Okay, guess which group I was in?)
Lee and Rob have a great “pairing” style in presenting. For those of you who don’t know them, Lee is a professor emeritus in Theatre from Swarthmore College. And Rob is a former associate professor at the Harvard Business School and is now full professor at the Copenhagen Business School.
In co-presenting, Lee and Rob take turns applying their perspectives about the look and feel of artful making. For Lee, this is about life in the theatre. For Rob, this is about great product development and, in particular, software development. So two great tastes that, as it turns out, taste great together (sorry, a reference to an old candy advertisement :)
So, what do actors and programmers have in common?Well, some amazingly fundamental things as it turns out:
Iterative work
Collaboration
Innovation
Theatre work and product development both thrive on iteration and collaboration. Lee described this in terms of rehearsal and the emergent look of a play leading up to and even after opening night. Rob affirmed the value of a collaborative and iterative approach in product development and provided videos from Boeing and Bang and Olufsen showing how both companies take advantage of this approach.
What do these practices have to do with innovation? Well in both theatre and product development, Lee and Rob encourage us to embrace what should be the glaringly obvious; that is, iteration and collaboration invariably produce innovation .
What happens when you put iterations and collaboration together? Rob introduced us to a term he had learned during his study of Boeing’s use of iterations: “try-storming”. That is, instead of just brainstorming ideas (whether in theatre or in product development), take your brainstorm and try it. Find something out about it as soon as possible. Then “try-storm” the next idea. (I think I am going to have to steal that term from him!)
I was also very fortunate to be able to sit next to Pete Behrens of Trail Ridge Consulting during the evening. Talking with him afterward, he reminded me of a few more similarities between theatre and product development:
You need to be able to surprise people in order to create value
If you don’t know in exact detail where you are going, it’s okay
The ideal play/product you hold in your head is very limiting; let go of it
In iterations, like rehearsals, each iteration may be or even will be significantly different from each other
We’ve been able to move to being more iterative these days, more Agile, because of technology making it cheap enough to iterate
Nothing is lost and wonders never cease as we build up each iteration from all the iterations before
Artful Making through iterations, collaboration and try-storming—all are important if you intend to be a theatre or product development organization that is truly innovative in the 21st century. And THAT is what actors and programmers have in common.
Your company is insane and you might be insane, too.
I bet you’re suspicious right now, aren’t you? You think this sensational opener is there just to suck you in and get you to read something that’s totally unrelated. Well, I mean what I said. Let me explain.
There’s this old joke. I think it’s a joke. Maybe it’s a saying. Or it could be an adage. I’m pretty sure it’s not an axiom and I know it’s not a koan. Hmmm. Might be a riddle. Anyway, where was I?
Oh yeah. The joke. It goes like this:
Q. What’s the definition of insanity? A. Doing the same thing over and over again and expecting different results.
OK, so maybe “joke” was stretching it a little, but it is kind of pithy, don’t you think?
Why do companies want to adopt Agile methods?After all, it’s expensive and painful what with all the training and change management and readjustments and FUD (Fear, Uncertainty, and Doubt) and so forth. And why do people come to CSM courses hoping to find new ways to build software? Because they’re bored and they want to get into arguments with their management? Probably not.
I think the reason is the same for both. It’s because pretty much everybody wants better (different) results from their software development efforts. Management wants more software to sell, and they want it to be higher quality, and to arrive faster, and to be more liked by their customers.
Employees would like at least an even chance of succeeding in what they do, and they’d like to feel like they are contributing the best that they have to offer as a valued part of their company. They want to feel like an accomplished, highly skilled professional and not some interchangeable cog in a soulless production machine.
OK, fine. So far so good. Everybody is aligned. It’s win-win all around. What could possibly go wrong? Well, here comes the funny part. Nearly all companies, nearly all management teams, and many employees don’t seem to understand that getting different results is going to require doing different things, or doing things differently (I’m not sure if those two are the same or not).
When I’m teaching the CSM course or introducing Agile at a company, the minute I bring something up that is actually, obviously different from what they are doing today, somebody gets upset.
When one of my students gets upset, they start raising objections such as:
“Oh, well, we can’t do it that way at our company.” (Betcha you can.)
“That’s not how it is at our company.” (Isn’t that what I’ve been trying to tell you?)
“But what about having the complete architecture before I start? I have to have that!” (Should I do this the nice way or the mean way?)
“We can’t do all of that testing. We don’t have testers.”(Gosh, I hadn’t thought of that. I guess you’re right. Just do the Agile without the testing and you’ll be fine. I’m sure no one will notice.)
“We don’t actually have anybody who could be the Product Owner.”(Do you hear what you’re saying?)
“We have a very mature phase-gate development process that we have to keep in place as we move to Agile.”(Say what????)
“I’m a manager and I’m paid to leverage my maturity and experience by telling people what to do so they don’t make mistakes. I’ll be doing that with the Agile teams, too.”(Don’t roll your eyes…don’t roll your eyes…)
“Our QA is in a separate group and they won’t talk to us until we have a complete set of specs to give them.”(And how’s that working for you, and them, and your company?)
And on and on and on. I talk about this when I teach Agile to new teams or new CSMs and CSPOs. Then later on during the class, when they start in with this stuff, I can get away with saying:
“Oh! So you mean your company is insane. They sent you here to learn a new way to build software, but they won’t let you build software in a new way!”
This is fun because I get to call companies and my students insane in a way that’s fun and also makes a point.
What to do about this is a serious question for those of us who coach, train, consult, or champion Agile within our organizations. Teams tend to get it, but I fear that companies of a certain size tend not to get it. And they keep not getting it while their Agile adoption loses steam, fails to deliver as well as it could, and finally fades away entirely. This is where many of those “scrum failed” stories come from. What happened was that in reality, they didn’t really try scrum because they were afraid to change anything.
Your company is insane because what they wish is that you could somehow get all the benefits of Agile without making any difficult or scary changes. You might be insane because you think some things can’t be changed and we can still get the benefits of Agile without changing them. As long as either you or your company is insane, neither of you will get the benefits of Agile adoption.
I guess that’s all I wanted to say.
About the Author: Alan Atlasis a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
We’ve been blogging on many Agile topics over the last few months - initial Agile adoption, culture shifts, organizational change, product ownership and project management, among others. These topics, for us, often conjure up images of the people who read our blog. Some readers might be in a more traditional camp of software development and a bit skeptical of Agile. Others may be “biting at the bit,” as it were, to adopt Agile or to keep their Agile practices ever-maturing.
Enter our new Agile Blog buddies, Walter Fall and Sarah Scrum. We bet you know someone like these two readers.
Who is Walter Fall?
Walter is well-meaning but may be just a bit stuck in an old school way of doing things (The guy still carries a comb just for his mustache for goodness sake!). He holds fast to the practices he has accumulated over the years and is happy with where his career has taken him. Walter has been with his company for 20 proud years and now runs a division of ~120 people, all organized in functional teams. Walter’s VP, a golf buddy, recently brought in a full-time consultant named Sarah Scrum to coach him and his group on adopting Agile practices. Walter is unamused, but he’s willing to listen, if only to prove her wrong.
Who is Sarah Scrum?
Sarah is passionate about Agile. She seeks continuous improvement, almost annoyingly so. She loves a challenge and has found Agile to be a valuable resource for tackling technical and organizational challenges. Sarah has worked with Agile teams for the last 7 years leading them through maturing and scaling their Agile adoptions. Her goal with any team is to teach them to fish as fast as possible. And at times, she may be just a bit impatient and come across as not based in the real world. She has just been hired to be an embedded coach for Walter Fall. Given what she has heard about Walter, this should be an interesting time!
Now that you’ve met Walter and Sarah – Who do they remind you of?
Your Boss? Someone at your last job? You at your current job? Certainly, this is not about good versus evil. Both Walter and Sarah can learn from one another in terms of best practices and adoption paths; the realities of large scale adoption; the pain of moving from one’s comfort zone; and, the thrill of enabling teams to continually find pride in their work. And you can bet they will challenge one another.
Look for Walter and Sarah to pop up from time to time on our blog with their perspectives. We hope their interactions prove to be both fun and informative as you follow the progression of their Agile story.
About the Author: Jean Tabakais a wine enthusiast, an Author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
In the last month, I have gotten the question “Where does Agile *not* work?” numerous times, mainly from large firms planning their first Agile rollout efforts. That question is quickly followed by, “And I don’t want to hear that it works everywhere!”
Admittedly, that’s a tough one for me. My answer is that Agile approaches can be applied anywhere – from your home moving project to the creation of space crafts. So I usually flip the question. If Agile conceivably could work anywhere, the question is really, “On which projects do you choose to start your Agile adoption?”
Where To Start
Jean and I and our fellow Rally coach Ronica Roth tend to apply two criteria: the strategic importance and risk of the effort. The iterative nature of Agile development is going to provide you with the tools to steer a risky and highly strategic project much better than phased development approach.
Our rendition from "Stand Back and Deliver"
In their new book Stand Back and Deliver, Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald provide a more elaborate portfolio model to assess your efforts. They map uncertainty versus complexity in a 2×2 matrix with nice labels of colts, bulls, sheepdogs and cows. I find the model is very effectively elaborated in the book and some very useful implications for staffing, selecting and managing the value flow are discussed. The variables used in the book include:
Complexity Attributes: Team size, mission critical, team locations, team maturity, domain gaps, dependencies
Three Perspectives
We agree with the authors, the best place to start using Agile practices are projects that are High Uncertainty (because you leverage Agile to learn as you go) and Low Complexity (to avoid the headaches of technical risk).
If the risk to the business is significant, such as eroding market share or the possibility the project will be canceled, then accept the technical risk and use Agile for a High Uncertainty-High Complexity project. The use of Agile will help with the uncertainty. It will be important on those projects to increase the discipline level around process and communication.
Projects of Low Uncertainty and Low Complexity rank third. They could easily transition to Agile and benefit from the improvements to productivity, quality, and collaboration. Yet they don’t need Agile to be successful. For these projects, the tie-breaker may be the next set of criteria – the environment.
Environmental Factors
Once the project is right for Agile by its nature, the next question is whether you can quickly create an environment for success. Many people talk about this as the organizational readiness for Agile or assess these concepts via Agile team assessments. Here is a snippet of that kind of team assessment:
Does the Product Owner have the right level of authority and influence? Are they…
Embedded with team?
Dedicated to the project?
Able to gain consensus from stakeholders on goals and features?
Able to evolve the product backlog (with training)?
Able to support the team through constant feedback and decision-making?
The team is dedicated to the work being planned using Agile (note: The team could actually work on multiple projects, as long as they are working a single backlog and work from all projects is scheduled via Agile planning cycles).
ScrumMaster, Product Owner, Product Development and Quality Assurance must be full-time dedicated resources.
Other resources might be part-time for any one Scrum team, but they should be spread across as few Scrum teams as possible. These include: Database, User Education, Apps Architect and Ops Architect.
Architects might be contributing members, or might be advisory.
Is the team co-located?
It’s not required, but can be a risk factor.
For distributed teams, it is important to have good communication constructs, and to have a leader in remote locations to partner with the ScrumMaster and Product Owner of the core team.
Do you have an Uber Product Owner and Uber ScrumMaster?
For multi-Scrum-team projects, it is important to have an overall Product Owner and ScrumMaster to own releases and communication across teams.
Is there a controlled build environment?
To ensure quality and a smooth flow of work, the team should be able to provide QA with builds multiple times during a two-week sprint.
As a Scrum team matures, and to increase velocity, the team will want to integrate code to a shared dev environment continuously (at least daily).
You can get a copy of Rally’s Team Agility Assessment and we welcome your feedback. I hope you will buy their book and try team assessments to help you map your own approach. To me, Agile works everywhere, it is just a question of how good do you want to be and by when.
“The greatest obstacle to discovery is not ignorance – it is the illusion of knowledge.” – Daniel J. Boorstin
Here’s something your team should look to avoid – Cargo Cult Scrum.
Members of the John Frum cargo cult
Cargo Cult Scrum is what happens when you adopt the practices, vocabulary, and artifacts of scrum but you don’t understand why or how they work. Cargo Cult scrum is bad. It is accidental and is based on ignorance.
Here’s a tiny piece of what Wikipedia has to say about cargo cults:
“A cargo cult is a type of religious practice that may appear in tribal societies in the wake of interaction with technologically advanced, non-native cultures. The cults are focused on obtaining the material wealth of the advanced culture through magical thinking, religious rituals and practices…”
When we talk about cargo cult implementations of scrum we are talking about people who seize on the advanced ideas of scrum and expect magical, unexplainable benefit to come from them, not realizing that informed usage is required in the bargain.
Craig Larman and Bas Vodde talk briefly about Cargo Cult Scrum adoption in their excellent book “Scaling Lean & Agile Development” in a section titled Avoid…Fake ScrumMasters. Fake ScrumMasters are created by “…Changing the title of someone to ‘ScrumMaster’ while he acts like – and is encouraged by the organization to act like – a project manager.”
They go on to describe the ultimate cargo cult scrum implementation:
“We adopted Scrum. Our Sprint length is the length of our project. The Product Owner decides the items in the Sprint and the project manager acts as ScrumMaster. He makes the Sprint Backlog and assigns the tasks to people in the team.”
So what does Cargo Cult Scrum look like?
Here are some examples that I’ve seen in the field:
I recently attended a meeting at a company that considers itself to be agile. It was a regular meeting that occurred every two weeks. It was not attended by a scrum team, but instead by a bunch of people from two different groups. The three questions were not used. The meeting was scheduled for, and took, 30 minutes. Yet the meeting was called a scrum. Other meetings at this company are called scrums, so much so that ’scrum’ has become a synonym for ‘meeting’. This is a cargo cult. The true meaning of ‘daily scrum’ has been lost, if it was ever apprehended in the first place.
I’ve also seen organizations in which people call every item on the Product Backlog a User Story (which is not the same thing as every item on the Product Backlog actually being a user story).
Another example is this actual [paraphrased] conversation I had with a potential customer:
Customer: Oh yes, we’ve been doing agile for a while. Coach: That’s great! So you haven’t had any trouble getting the Product Owner to work closely with the team? Customer: Well, we…uh…don’t really have a Product Owner. Coach: Oh. Well, who keeps the Product Backlog in shape? Customer: Well, we…uh…don’t really have a Product Backlog, per se. Coach: Oh. So how do you plan your sprints? Customer: Well, we really don’t do that in a very formal way. But we do meet every morning. That’s what it’s all about, right?
And my all time favorite. I was once told by a manager of a supposedly Agile group: “We like things the way they are. We know it’s not perfect. We don’t want to change.” Yikes. So much for Continuous Improvement.
Though you shouldn’t do Cargo Cult Scrum for any reason, the reality is that any step down the road to scrum is usually better than whatever preceded it.
Don’t feel bad if your scrum implementation isn’t the same as what’s in the books. Feel bad if you are have stopped trying to make it better.
About the Author: Alan Atlasis a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
RallyDev.com
This week, I had the pleasure of attending the seminar “The Way of Artful Making” presented by Rob Austin and Lee Devin , co-authors of the book “Artful Making”.
Well, some amazingly fundamental things as it turns out:
Your company is insane and you might be insane, too.
