I read Sayonara Sony: How Industrial, MBA-Style Leadership Killed a Once Great Company, and was struck by how the company appeared to make decisions—what will make us the most money now?
If you make your project portfolio decisions based on money, estimated cost, you too will have Sony’s problems. This is why cost is the wrong question to ask. You want to ask the value question, “How much value will this project provide?”
This is not a return on investment question. That’s a prediction question. You can’t answer that question either.
When you use cost as the “which project should we fund?” you can guess right. But you guess based on what you think the market will buy, not what you decide is the right strategy for your company. Big difference.
This is why you want a mix of projects in your project portfolio: Projects that keep the lights on; projects that keep cash coming in; and projects that are innovative, that have the power to transform your organization. And the problem is this: in software, you often can’t tell which one is which. This is why agile or lean is so wonderful. You don’t have to be able to tell.
If you use incremental budgeting and an agile approach to your project portfolio, and an agile/lean approach to your projects, you can pivot when you need to.
Now, you might need to do a quick SWAG (Scientific Wild Tush Guess) for an order of magnitude estimate for your project. Is this project bigger than a breadbox? Is it smaller than a space station? That’s not a project estimate. That’s a SWAG, an order of magnitude estimate. You do a SWAG with a few people in under an hour. Two hours max.
For the project portfolio, you make the evaluation decision based on your best guess of the project’s comparative value to the organization. This is why it’s so helpful to be able to deliver something in a short period of time, such as 2-6 weeks, when the project portfolio people will want to reevaluate the portfolio again.
Oh, and those Sony engineers? The ones who were laid off when Sony couldn’t keep their commitment to lifetime employment? Some of them went to LG. You know, the company that you probably bought your flat screen TV from? All I know, is that every hotel I stay in has an LG TV. In our house, we have (smaller) LG TVs.
When you use value to make project portfolio decisions, you decide on the most valuable project. If you change your mind, you don’t can the people. You change what the people do—you flow work through the team. Is this more difficult with hardware? Of course. Is it impossible? No.
People want autonomy, mastery, purpose. (Yes, this is from Dan Pink.) Give it to them. Tell them what is the number one project. The number two project, etc. Tell them what is not funded, and why. They will work for you, to make it happen.
Der Sprint ist zu Ende. Das Team legt die Arbeit nieder und geht in das Review. Und schon ist sie wieder da: Die steife Meeting-Atmosphäre, in der die erlegten Stories nacheinander vorgeführt werden, ScrumMaster und Product Owner im Mittelpunkt stehen, und Anwesende ungeduldig auf den Stühlen rutschen. Wenn es ganz schlecht läuft, muss das Team sich auch noch gegenüber Product Owner und Management rechtfertigen, warum etwas so und nicht anders umgesetzt wurde.
Ein gutes Review ist wie eine gute Retrospektive: In dem einen geht es um die Auseinandersetzung mit dem Prozess, in dem anderen um die Auseinandersetzung mit dem Produkt. Alles andere sollte im Review im Hintergrund verschwinden. So ist es für das Review zum Beispiel irrelevant, wie viele Stories das Team geschafft hat. Ebensowenig sollte das Team im Review irgend etwas vorführen müssen, das keinen Nutzer interessiert. Deshalb macht der Product Owner die Abnahme der fertigen Stories bereits im Sprint und nicht erst im Review.
Für ein erfolgreiches, spannendes und wirklich kommunikatives Review kommt es auf die richtige Perspektive an:
- Demos, keine Präsentationen! Im Review wollen wir vorführen, wie unsere Produkte funktionieren. Und dafür brauchen wir weder Powerpoint noch sonstige Realitäts-Substitute.
- Teilnehmer, keine Anwesenden. Das, was das Team im Sprint fertiggestellt hat, lädt fast immer irgendwie zum Mitmachen ein. Vor allem User sind hier gefragt, das entstehende Produkt zu begutachten und – soweit möglich – selber in die Hand zu nehmen. So ensteht direktes Feedback, das deutlich realitätsnaher als jede Fokus-Gruppe ist.
- Gespräche, keine Abfragerunden! Damit echte Gespräche zustande kommen, sind kleine, interaktive Gruppen unabdingbar. Dazu bietet sich etwa das World Café-Format an: Für jedes der neuen Features einen Tisch einrichten – das Team teilt sich entsprechend auf und stellt vor. Die Teilnehmer verteilen sich von Tisch zu Tisch und rotieren alle zehn Minuten. Am Ende kommen alle kurz zusammen und stellen die wichtigsten Erkenntnisse vor.
- Stift und Papier statt Open Issue-Listen. Im Review entstehen zunächst einmal Ideen, wie es mit dem Produkt weitergehen soll. Der formale Prozess, nämlich die Festlegung der nächsten Entwicklungsschritte, geschieht anschließend durch den Product Owner mit seinem Team.
Wie gestaltet ihr Eure Reviews? Was hat funktioniert, was nicht?
I've just joined Peter Green as a cotrainer in an upcoming Certified ScrumMaster course in San Diego later this month. I'm very excited about this course. Peter is Adobe's in house Agile Transformation Leader, where he leads a team of trainers and coaches that have helped Adobe's teams and organization adopt an agile mindset. I've been following Adobe's published practices over the years. They've innovated some great practices for mixed discipline teams there and are undergoing a exceptional transformation to agile.
Additionally, Peter has been a very innovative trainer in bringing new approaches to training that make ideas stick and leave attendees with a new mindset. I'm honored to cotrain with him and share some things I've discovered as well.
Please join us if you can. It will be an amazing course.
About the course:
- Recognition by the Scrum Alliance as a Certified ScrumMaster after passing a short certification exam.
- Continental Breakfast, Plated Lunch, and snacks.
- Printed Workbook and an electronic copy of all materials used in class
- A one year membership to the Scrum Alliance (a $50 value)
- Students who are PMP® certified will earn 15 PDUs for completing the Certified ScrumMaster course.
- Students interested in the PMI-ACP program will receive 15 of the 21 training hours required for the PMI-ACP certification
For more details and registration, visit http://www.organizationalagility.com/index.html
Use the discount code CK995 for an immediate $200 discount on the course. Seats are limited.
Technical Debt is usually referred to as something Bad. One of my other articles The Solution to Technical Debt certainly implies that, and most other articles and books on the topic are all about how to get rid of technical debt.
But is debt always bad? When can debt be good? How can we use technical debt as tool, and distinguish between Good and Bad debt?Exercise: Draw your technical debt curve
Think of technical debt as anything about your code that slows you down over the long term. Hard-to-read code, lack of test automation, duplication, tangled dependencies, etc.
Now think of any system you’re working on. Grab a piece of paper and draw a technical debt graph over time. It’s hard to numerically measure technical debt, but you can think of it in relative terms – how is the relative amount of technical debt changing over time? Going up? Down? Stable?
Sadly, in most systems tech debt seems to continuously increase.
How do you WANT your debt curve to look?
Next question: if you could choose, in a perfect world, how would you like that curve to look like instead? Might sound like an obvious question, your spontaneous thought may be something “Zero tech debt! Yaay!”
Because, heck, didn’t I just say that technical debt is anything that slows you down? And who wants to be slowed down? If we could have zero technical debt throughout the whole product lifecycle, wouldn’t that be the best?
Actually, no. Having zero technical debt at all times will probably slow you down too. Remember, I said “Think of technical debt as anything about your code that slows you down over the long term”. The short term, however, is a different story.
Let’s talk about Good technical debt.When is a mess Good?
Think of your computer and desk when you are in the middle of creating something. You probably have stuff all over the place, old coffee cups, pens and notes, and your computer has dozens of windows open. It’s a mess isn’t it?
Same thing with any creative situation – while cooking, you have ingredients and spices and utensils lying around. While recording music, you have instruments and cables and notes lying around. While painting, you have pens and paints and tools lying around.
Imagine if you had to keep your workspace clean all the time – every time you slice a vegetable, you have to clean and replace the knife. After each painting stroke, you have to clean and replace the brush. After each music take, you have to unplug the instrument and put it back in it’s case. This would slow you down and totally kill your creativity, flow, and productivity.
In fact, the “mess” is what allows you to maintain your state of flow – you have all your work materials right at your fingertips.When is a mess Bad?
A fresh mess is not a problem. It’s the old mess that bites you.
If you open your computer to start on something new, and find that you still have dozens of windows and documents open from the thing you were working on yesterday, that will slow you down. Just like if you go to the kitchen to make dinner and find that the kitchen is clogged up with old dishes and leftovers from yesterday.
Same with technical debt. Generally speaking, old debt is bad and new debt is good.
If you are coding up a new feature, there are lots of different ways to do it. Somewhere there is probably a very simple elegant solution, but it’s really hard to figure it out upfront. It’s easier to experiment, play around, try some different approaches to the problem and see how they work.
Any technical debt accumulated during that process is “good debt”, since cleaning it up would restrict your creativity. In fact, somewhere inside the messy commented-out code from this morning you may discover the embryo to a really elegant solution to your problem, and if you had cleaned it up you would have lost it.
Another thing. Sometimes early user feedback is higher priority than technical quality. You’re worried that people might not want this feature at all, so you want to knock out a quick prototype to see if people get excited about it. If the feature turns out to be a keeper, you go back and clean up the code before moving on to the next feature.
The problem is, just like in the kitchen, we often forget to clean up before moving on. And that’s how technical debt goes bad. All that “temporary” experimental code, duplicated code, lack of test coverage – all that stuff will really slow you down later when you build the next feature.
So regardless of your reason for accumulating short-term debt, make sure you actually do pay it off quickly!
But wait. How short is “short term”?When does Good Debt turn into Bad Debt
My experience is that, in software, the “good mess” is only good up to a few days, definitely less than a week. Then it starts going stale, dirty dishes clog up the kitchen, the leftovers start to stink, and both inspiration and productivity go downhill.
So it’s really important to break big features into smaller sub-features that can be completed in a few days. If you need practice doing that I can highly recommend the elephant carpaccio exercise.The ideal technical debt curve
If new debt is good, and old debt is bad, then the ideal curve should look something like this, a sawtooth pattern where each cycle is just a day or two.
That is, I allow myself to make a temporary mess while implementing a new feature, but then make sure to clean it up before starting the next feature. Sounds sensible enough right?
Just like the kitchen; It’s OK to cause a creative mess while cooking, but clean it up right after the meal. That way you make space for the next creative mess.The more realistic ideal technical debt curve
In theory, it would be great to get down to zero technical debt after each feature. In practice, there’s an 80/20 rule involved. It takes a reasonable amount of effort to keep the technical debt at a low level, but it takes an unreasonably high amount of effort to remove every last last crumb of technical debt.
So a more realistic ideal curve looks like this, with a baseline somewhere above zero (but not too far!).
That means our code is never perfect, but it’s always in good shape.
The “debt” metaphor works nicely because, just like in real life, most people do have some kind of financial debt (like a house mortgage) on a more or less permanent basis. It’s not all bad. As long as we can afford to pay the interest, and as long as the debt doesn’t grow out of control.Have a debt ceiling. Just for in case.
Now, even if we do clean up after every feature, we are humans and are likely to accidentally leave small pieces of garbage here and there, and it will gradually accumulate over time. Like this:
So it best to introduce a “debt ceiling”. Just like certain governments….
When debt hits the ceiling, we declare “debt alert!”, the doors are closed, all new development stops, and everybody focuses on cleaning up the code until they’re all the way back down to the baseline.
The debt ceiling should be set high enough that we don’t hit it all the time, and low enough that we aren’t irrecoverably screwed by the time we hit it. Maybe something like this over a half-year period:
How to set the baseline and ceiling
All this begs the questions “yes, but How?”. It may seem hard to quantify technical debt. But actually, it’s not. Anything can be measured, as long as it doesn’t have to be exact.
Just ask people on the team “How do we feel about the quality of our code?”. Pick any scale. I often use 1-5, where 5 is “beautiful, awesome code with zero technical debt”, and 1 is “a debt-riddled pile of crap”. With that scale, I would set the debt baseline to 4, and the debt ceiling to 3 (think of debt as the inverse of quality). That means quality will usually be 4, but if it hits 3 we will stop and yank it back up to 5.
Of all the possible metrics that can be used, I find that teams often like this subjective quality metric. It’s simple, and it visualizes something that most developers care deeply about – the quality of their code.
Other more objective metrics (such as test coverage, duplication, etc) can be used as input to the discussion. But at the end of the day, the developer’s subjective opinion is what counts.Use debt ceiling to avoid a vicious cycle
The debt ceiling is very important! Because once your debt reaches a certain tipping point, the problem tends to spiral out of control, and most teams never manage to get it back down again. That applies to monetary debt as well. And governments…
One reason for this “tipping point” effect is the “broken window syndrome”. Developers tend to unconsciously adapt the quality of new code to the quality of the existing code. If the existing code is bad enough (many “broken windows”), new code tends to be just as bad or even worse – “oh that code is such a mess, I don’t know how to integrate with it so I’ll just add my new stuff here on top”.
Think of a kitchen, at home or at the office. If it’s clean, people are less likely to leave a dirty cup on the counter. If there are dirty cups everywhere, people are very much more likely to just add their own dirty cup on top. We are herd animals after all.Make quality a conscious decision
My experience is that a quality level of 4 (out of 5) is a good-enough level of quality; clean enough to let the team move fast without stumbling over garbage, but not so overly clean that the team spends most of it’s time keeping it clean and arguing over code perfection details.
The key is to take a stand on quality. Regardless of how you measure quality, or where you place your debt baseline and ceiling, it’s very valuable to discuss this on a regular basis and make an explicit decision about where you want to be.How Definition of Done helps
“Definition of Done” is a useful concept for keeping tabs on technical debt. For example, your Definition of Done for a feature could be:
- Code clean
- In production
- User accepted
These are in no particular sequence, as that will vary from feature to feature. Every sequence has it’s advantages and disadvantages. Sometimes we’ll want to put something in production first, then get user feedback, then clean up. Sometimes we’ll want to clean up first, then get user feedback, then put in production. But the feature isn’t Done until all three things have been done.
Here’s a sample board to visualize features flowing through this process.
- Feature A: All done. It’s in production, the code is clean, and the user has given thumbs up.
- Feature B & C: Current focus is getting user feedback. B has already been cleaned, C has not.
- Feature D: Current focus is cleaning up the code. User has tried it and given thumbs up.
- Feature E & F: Currently being developed, trying to quickly get to a point where we can get user feedback.
- The rest of the features are in the idea pool (most teams call that a “backlog” but I prefer the term “idea pool”).
Acceptance Test-driven development is a really effective way to keep the code clean while still enabling experimentation and creativity.
All features are developed in three distinct steps:
First step is to write a failing (“red”) acceptance test. When doing that, we focus exclusively on the question “what does this feature aim to achieve, and how will I know when it works?”. We’re setting a very clear goal and embedding it in code, so at this point we don’t care about quality, or how the feature will be implemented.
Second step is to implement the actual feature. We know when we’re done because the executable acceptance test will go from red to green. We’re looking for the fastest path to the goal, not necessarily the best path. So it’s perfectly fine to write ugly hacks and make a creative mess at this point – ignore quality and just get to green as quickly as possible.
Third step is to clean up. Now we have a working feature and a green test to prove it. We can now clean up the code, and even drastically redesign it, because the running tests (not just the newest test) act as a safety harness to alert us if we’ve broken or changed anything.
This process ensures that we don’t forget the purpose of the feature (since it forces us to write an executable acceptance test from the beginning), and that we don’t forget to clean up before moving on to the next feature.
To emphasize this process, we can update the board with “acceptance test written” column, just to make sure that we don’t start implementing a feature before we have a failing acceptance test.
The acceptance test doesn’t necessarily have to be expressed at a feature level (“if we do X, then Y should happen”). Some alternatives:
- Lean Startup style acceptance test: “we have validated or invalidated that users are willing to pay for premium accounts”. Maybe rename the “User feedback” column to “Validating assumption”.
- Impact Mapping style acceptance test “the feature is done when it increases user activation rate by 10%”. Maybe rename the “User feedback” column to “Validating impact”.
Either way, we just need to make sure cleanup is part of the process somewhere.
TDD can be done at multiple levels – at a feature level (acceptance tests) as well as at a class or module level (unit tests). Think of the unit tests as a bunch of triangles inside the acceptance test triangle. One loop around the big triangle involves a bunch of smaller loops inside.
After each unit test goes green, do minor cleanup around that. When the acceptance test goes green, do a bigger cleanup. Then move on to the next feature.
The key point is that each corner of the TDD triangle comes with a different mindset, and each one is important.Good quality = happier people
At the end of the day, technical debt is not about technology. It’s about people.
A clean code base is not only faster to work with, it is more fun (or less annoying, if you prefer seeing things that way…). And motivated developers tend to create better products faster, which in turn makes both customers and developers happier. A nice positive cycle
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 4: THE GENDER ZEITGEIST, PART I
“There’s a lot in the zeitgeist right now that’s looking at the differences between how men and women lead, how those differences in leadership style, whether done by a man or a woman, impact people’s ability to get things done in the workplaces and move around in their organizations.”
Running time 22:04
What type of culture does your organization promote? Does it encourage collaboration? Conflict avoidance? Constructive confrontation?
Leave a comment on this blog or email us at email@example.com
[Intro] Women in the workplace.
[01:05] Are men and women promoted differently? Confidence vs. competence?
[02:25] Technology touches all industries, but are some technologies more “women-focused”?
[08:13] Channeling women into staff jobs rather than operations.
[09:45] “Emotional, bossy, too nice” – The appearance of labels can mislead.
[11:00] The culture of “nice” and its implication in the workplace, for both men and women.
[15:32] Hiring for nice – focus on collaboration, competing together to get the work done.
[18:51] Constructive confrontation can focus on the clash of ideas rather than clash of people.
[20:02] Ripple effect of women “leaning In” in organizations.
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 3: AITCH ARR
HR typically has been set up in the past and has been staffed by people who saw it as their role to protect the organization… but there is another whole set of function that support the strategic role of HR… That’s where organizational development work comes in, that’s where leadership development comes in. Those are the kinds of things that need to support the business unit of an organization to do what the business units need to get done.
Running time 33:42
Do you have stories about corporate structures and functions working well together?
Leave a comment on this blog or email us at firstname.lastname@example.org
[Intro] Agile 2013 highlights.
[01:20] The organizational impact of changing direction and strategy mid-way.
[04:43] Flexibility or lack of in adjusting annual assessment goals and who should take part in that conversation.
[07:27] The changing role of Human Resources from compliance function role to an engaged and strategic partner in organizational development.
[10:53] Creating collaborative workspaces to enhance return on performance.
[17:44] “Sitting is the new smoking.”
[22:05] How can HR and organizational development work together? Example from one corporation.
[30:01] The discomfort in changing structures.
Caroline Sauve is an agile coach from Canada. I have had the pleasure of interacting with, teaching, and learning from Caroline in the Coaching Agile Teams class and at Agile Coach Camp Canada. Caroline blogs at agile meditation. She starts this blog post with a thank you to me. I gratefully accept your appreciation, Caroline, and am happy to be colleagues. Here’s Caroline:Standup Is About Commitment, Not About “Giving Status”
One of the many moments of clarity that I’ve had thanks to Lyssa Adkins (Twitter: @lyssaadkins) is the goal behind the Standup meeting.
Standup is about commitment, not about “giving status”.
Armed with this new understanding, I facilitated a Standup meeting “reboot experiment” with my team. We started by talking about what wasn’t working with this meeting and then worked together to develop some new guidelines centered around the idea of commitment.
Now, during Standup…
We each take a turn to express what we will commit to completing between this meeting and the next.
When we aren’t speaking, we commit to listening fully to the person speaking.
We will speak up if we have information that would help the person speaking meet their commitment. Creating this connection is important… but having the full conversation may not… so we commit to identifying side conversations when they happen.
We are committed to keeping the information shared relevant for all. We ask questions if a team member’s commitment is unclear.
We regularly check-in on the value and relevance of the meeting and re-commit as needed.
It’s worth noting that we don’t generally discuss “blockers” here, mostly because the team is empowered to seek help if they encounter an impediment rather than wait for a meeting. We also don’t generally talk about what we did in the past unless we feel it to be relevant information for the team.
Could your Standup meeting do with a little more commitment?
This post originally appeared on agile meditation in July 2013. Thanks, Caroline, for contributing it!
Bobtuse can be wildly informative
Scaling Agile across the Enterprise attracts a lot of attention these days. There are a number of models suggesting ways to organize Agile development inside a sizable organization with a lot of teams. I suspect that all of these models share the same basic flaw—that you can do something the same way across a large enterprise. Even if your policy manual says exactly how to do something, people are people and there will be variations in understanding and execution. And how does a team self-organize in a prescribed manner?
Beyond that, there’s the problem of getting from current state to a future state that resembles the model. It does not work to “install” a new way of working across a large system composed of people and their interactions. Some people suggest starting the transformation with management, as that’s the “highest leverage point” and the “system’s major influencers.” Others suggest starting with the teams, because without competence at building reliable software (or other systems) in short cycles of small steps, you’re not going to get the benefits of Agile Software Development. I don’t think that either of these starting points work.
“When we try to pick out anything by itself, we find it hitched to everything else in the Universe” — John Muir
In an organization, everything has influence throughout the organization. That influence is muddled in with a million other influences. While it’s true that upper management is charged with making the “big decisions,” when they’re candid they’ll admit that they have less control over how things happen than they’d like. They’re not even aware of all the things going on. It’s far too complicated for one, or even a small group of brains.
Organizations are self-regulating toward maintaining the status quo. When you try to change one part, to the extent it’s connected to other parts, it resists the change because of the influences of the other parts. To the extent it’s insulated from the other parts, it changes more easily but has less influence on the other parts. It’s a dynamic balance, ever-changing but quite robust.
Given this, how do you institute change in an organization?
I think you have to start with multiple levels, simultaneously. Every relationship in the organization is an equation that has to be solved. All of these equations are inter-related, and they have to be solved simultaneously. Each influences the others.
When trying to help an organization change, I start with every point where I might have influence. With each person who will engage in conversation, I try to understand what are their personal goals within the organization. I help them develop their own vision of the transformed organization. I offer alternative actions that they might not have considered. I urge them to have influence with those whom they have a relationship. I try to light a little fire of hope and change for the better.
And I try to light these fires in every place I can—among the development teams, the first line managers, the directors, and as far up the chain as I can reach. When there are important constituencies outside my direct reach, I encourage others to reach out to those constituencies. Or I ask them to bring us together, so I can have direct conversation. When working with other coaches, I depend on them to reach people that I have failed to reach.
These many small fires can result in major changes. Simultaneous changes in multiple parts of the organization can breed powerful synergies. The change goes in a direction influenced by the energies of the people engaged in the change. It’s not under any one person’s control, but shaped by the collective vision, action, and engagement of all.
Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 2: BLAME THE CONSULTANTS
“It’s how we respond to the changes, it’s how we think about them, it’s how we interact, how we deal, how we cope, how we make meaning of the change that makes the difference.”
Running time 28:56
What are you doing to influence change and recognize patterns in your organization?
Leave a comment on this blog or email us at email@example.com.
[Intro] Can change be “managed” or “controlled”?
[01:58] Making one change may demand other changes that are unknown until that first step is taken.
[05:08] Having a flexible framework vs a concrete plan can help to “steer” the change forward.
[9:01] Adapting to change by asking “what”, “so what” and “now what”.
[13:51] Planning 10 years down the road is ineffective. Put yourself back to 10 years ago, would you have predicted where you are today?
[16:30] We can know that unexpected events will occur, what we can’t know is the exact nature of those events, so in some ways we have to plan for the unexpected.
[18:48] One way to be ready for the unknowable is to develop a set of tools that enable us to intervene on patterns that aren’t serving us well and tweak them, shape them, and move them.
[23:23] Resilient people and organizations adapt to change and move forward because of how they choose to respond to change; they do not let the change define or defeat them, they adapt and move forward.
[26:18] Start moving forward by asking yourself: “Where was I 10 years ago?” “Did my goals predict where I are now?”
I have had the pleasure to work with Jennifer in the agile coaching classroom. She is a wonderfully creative and thoughtful coach who blog as at Kanna Consulting LLC. Here she is…Become an Agile Whisperer
If you are involved in the Agile movement as a Scrum Master or Agile Coach, you are involved in introducing change into an organization. Change is always disruptive. But there are ways to minimize the impact. Becoming mindful of how you introduce change is a very useful skill to develop.
When I look back at my 13 years of introducing change to larger organizations, I have gone through my own metamorphosis of how I encourage change. All three may have their place, but the more effective are the last two.
- The Bulldozer
- Fine Tuning
- Leaning In
Introducing a framework such as Scrum, is an example of the bulldozer approach. When you jump into Scrum with a team of people who are new to the framework, it’s very disruptive and chaotic. You are basically shoveling a massive change onto the team. It’s not necessarily bad to use the bulldozer tactic to introduce change, but it should be the exception rather than the rule. If you embrace the idea that this is massive change, you can help manage expectations of the team and people external to the team.
Personally, I love change. I get very bored of routine and introducing change just to do something different keeps things interesting for me. The majority of people don’t love change. Especially change introduced by someone else that has little relevance to your world or even a detrimental effect. I learned through the experience that bulldozing change onto others usually doesn’t work, unless there is a selective deliberate application, such as jumping into an Agile framework.
Once you are into a rhythm with your Agile framework the massive changes slow down and the team slides into a pattern of incremental changes. I have noticed that my teams have transitioned into a rhythm at about the three-month mark after starting Scrum. You don’t see the impact right away, but if you are maintaining your metrics properly, you can gauge whether the tuning has an impact over time. Even when retrospectives seem rote and stale, don’t give up on these valuable opportunities to keep tuning the team. If your retrospectives do become stale, change it up with games that teach a lesson, or use different retro formats to keep it fresh or even entertaining.
For a year I worked with a team that used the fine tuning approach. The team would review processes every two weeks and talk about things that could improve their performance. From month to month, it didn’t look like much change, but year over year, this team experienced 320% increase in productivity. Through selective tuning such as adding key personnel, becoming more cross-functional, reducing bottlenecks, stabilizing the team, solid backlog grooming, and a number of other small efforts this team was able to fine tune themselves into a highly productive team.
This has been a hard learned lesson for me. I think the lesson of “leaning in” is something I first learned in Lyssa Adkins and Michael Spayd’s Coaching Stance workshop, but it has taken me some time to fully let the lesson sink in and apply it. Learning to be a coach through using coaching techniques applied in the specific Agile context was a powerful learning experience. I volunteered for one of the first demonstrations in the class introducing us to the idea of what traditional coaching was about. It was amazing to be listened to deeply and uncover ideas that I held within myself.
I used the term Agile Whisperer in the title of this post because of how I perceive whisperers (The Horse Whisperer, Dog Whisperer) engage with their subjects. They are acutely in tune with their subject whether it’s a horse, a dog, or a baby. They pay attention to it’s natural instincts and use those to achieve a desired state: accepting a saddle for a horse or eliminating negative behaviors in a dog.
In the Agile environment, the subject is our team. By “whispering,” it means adopting the characteristics of these other whisperers and getting deeply in tune with what is happening already on the team and leaning into aspects that are currently exist to achieve desired change. In essence, leaning in is learning to be quiet, bide your time, observe the team, listen carefully and look for the things they are already doing that contain elements of the change you want to introduce. If you must speak, ask questions. Pay attention to where there is lots of energy and conversation on the team.
When you join the team, go ahead and make the list of things you want to see changed. Depending on the environment, sometimes you can start discussing with team members or even the team at large (see Fine Tuning). In the Leaning In scenario, though, back up. Don’t talk. Be quiet for a while. Sometimes it’s hard to look like you’re doing nothing when, in fact, you are carefully observing and listening to the team. This is when you take ego out of your intention. If you do it well, the team won’t even realize your influence in the change. They’ll think they did it themselves. And that kind of change tends to stick much better.
I had an example that drove this lesson home to me. I had an environment that made introducing change a bit of a challenge. I had been noticing something in the way our stories were developed. A light bulb went on when I got into a discussion with a team member and realized there was an opportunity for a fairly substantial change to the team which would also have downline impacts such as dividing the larger team into smaller subteams.
Circumstances made it difficult for me to introduce this change immediately. Instead, I started paying close attention to where the really good, cross-functional conversations were happening on the team. In that week, I noticed those conversations had the elements of cross-functionality that that would be a core part of the change that I had been wanting to recommend. The key then, was pointing out what the team was naturally doing, asking some questions to bring attention to the good elements of this behavior, and posing the thought about organizing around this natural communication behaviors and making it more intentional. As I approached the change from this angle, team members jumped on the idea and ran with it. Introducing this significant change has been the least challenged thought I’ve ever presented because it was really based around what the team was already doing and simply embracing it and making it intentional from the start instead of a byproduct of final activities.
To sum up, if you are encountering resistance with introducing change, try leaning in and becoming an Agile whisperer by using noticing good behaviors that naturally emerge, calling attention to it, and making that intentional.
This post originally appeared as Become an Agile Whisperer in June 2013. Thanks, Jennifer, for contributing it!
I met Laszlo Szalvay (and his brother Victor Szalvay) several years ago, when Laszlo hired me at Danube Technologies. Both Laszlo and Victor are quite remarkable entrepreneurs who started Danube Technologies straight out of college. This is a story how they build a successful product and services business around Agile and Scrum, and how they eventually sold that business to Collab.net.
Laszlo is incredibly honest in this interview, and I found it especially interesting to hear why they decided to sell the business, and also Laszlo’s thoughts on where the Scrum community is headed. Lazlo Szalvay is a VP at Solutions IQ; an Agile consultancy based in Pacific NW that offers Agile training, coaching and mentoring.
Here’s the interview:Transcript Kane: Laszlo let’s get started. Let me ask you, what brought you to the
What originally did you see within Scrum or how did you come about
coming into the Scrum community?Laszlo: Yes, okay. Thanks Kane. Great question. I got into the Scrum
community, I guess
pretty early, on maybe like 2003, 2004 time-frame. At that time, my
brother Victor and I had a company, a little consulting company based
in Seattle, Washington called Danu Technologies.
One of our employees at that time was a guy named Michael James and we
were looking at how do we contemplate project management? Because it
wasn’t something when we were doing these, kind of, smaller scale
projects that we really contemplated, really thought through.
We had some pain and so Michael and Victor did some research and they
found Ken Schwaber’s book and we were looking for kind of how to lay
out physical spaces and things like that for more collaborative
working environment. So that’s how we first heard about Scrum.
We decided to try it whole hog on a government project and it was with
the state of Alaska. The customer loved it. In fact, one of those
customers moved into our office as project donor. The rest is history.
That’s kind of how we got started. I can elaborate if you’d like.
Kane: I’d love to. Yes, tell us.
Laszlo: Yes, so I can tell you the whole story. From there we started
getting into more and
more projects and trying it on more and more projects and we found it
really helped us. It helped us with customer satisfaction, it helped
us with predictability, it helped us a lot with employee morale.
As a small company you’re kind of looking for every little edge that
can retain customers and employees because without that you’re kind of
dead in the water. [inaudible 02:31] your company is kind of dead.
From my standpoint I was pretty pragmatic about it because I was on
the business side and really Michael and Victor and some of the others
like Kelly, they were kind of doing the heavy lifting, Eric and them.
Then as is the case with many kinds of services based companies, we
had a business that was ebbing and flowing. Sometimes we had a lot of
business and we were really busy and other times we were kind of
bored, for lack of a better word. We didn’t have any projects.
What we decided to do is we decided to go out and build a project
management tool that modeled Scrum. What we did is we tried to model
it exactly to Scrum. The idea of that initially just came as a way to
kind of proof of concept how we work. We could show, okay we can do a
project and here’s what a project looks like.
We started kind of showing this project management tool to different
people in the community, for example Dan Rawsthorne and Mike Cohen and
Dan kind of said are you guys planning to charge for this? We said no,
we’re just. He kind of looked at me and said well, you might want to
think about that.
Then that’s kind of how things got started. Then we launched the
ScrumWorks product in August of 2004 at the XP universe show which is
now Agile 2000X Series. Interestingly enough, Rally Software was also
They launched at the same trade show actually, interestingly enough
their product. That’s kind of how we got started. We found that that
ScrumWorks product created a huge lead generation engine for us and
got us interested and noticed by a lot of the early adopters like, who
was the company? I think TransCanada was I think one of the first
companies to use Scrum.
Kane: Yes, TransCanada Pipelines, TCPL.
Laszlo: Did I remember it correctly? Yes, TransCanada pipelines. I
think you were working on
that project maybe?
Kane: Yes, absolutely. Yes.
Laszlo: Then there were some others as well. I think Capital One. I
think you were working on
Capital One at that time as well?
Kane: Yes. I was working with ThoughtWorks at the time. But yes for both
PCPL and Capital One I was with ThoughtWorks. So you were selling the
ScrumWorks Pro tool to both PCPL as well as Capital One?
Laszlo: Yes, let me correct myself here. At that time it was just free.
Kane: Oh, interesting. Yes.
Laszlo: Just totally free. The idea was just lead generation and the
idea of it being free was
primarily because we were so small a company, we couldn’t afford the
infrastructure to build a support team, to build an SLA, a service
level agreement around the product. We got around those difficult
questions by just kind of rationalizing it as free or freeware. But
what we did get out of it were interesting conversations.
Then we landed some pretty large contracts, for example with the state
of Washington. I think we were involved in the first ever government
Scrum projects. It was the first time they used the word Scrum in a
That was in 2004, late 2004. I think October of ’04. Interestingly
enough we were competing against Solutions IQ which is where I am
Kane: Was the state of Washington, were they asking for a Scrum project?
Kane: They were explicitly asking to do scrum?
Laszlo: They were explicitly putting it into the RFP. There was a very
progressive guy there. I
think his last name was Kane. Kane. I think his name was John Kane. I
think. Don’t quote me on that but that’s the name that comes to mind.
There were some very progressive project managers there like Ann
Dylan. They just kind of brought us in and they said look. We have to
use Scrum. That was a prerequisite.
Laszlo: Then we said, “Hey, we know Scrum.” The way it all came about
actually was at that XP
Universe show where we launched ScrumWorks. Victor, my brother, did an
introduction to Scrum talk.
These days when you go to the Agile show you’re not going to get too
many what is scrum basics talks but in 2004 that was a big topic
because it was essentially an engineering XP conference.
Two guys from the Washington State government were in the audience.
They approached me afterwards and said “Hey, we’ve got this project.
We’ve got this RFP”. There are not too many people who know about
Agile and Scrum and interestingly enough, they were based in Olympia,
Washington and we were headquartered at that time in Seattle,
Washington. We were just laughing because we could have been in
Detroit and they could have been in Nashville. You just never know at
these trade shows. We ended up winning a piece of that business and
that kind of parlayed us into kind of a full-fledged training
Training and coaching business. At that time we brought you on,
actually, as an employee from ThoughtWorks. We brought on folks like
Dan Rawsthorne. We brought on folks like, you know Michael James
became a CST. My brother became a CST. Then we just kind of began
One of the first classes I think we did, my brother did, was in
probably late ’05. His first class I think was with Boris Glogger. So
yes, it was just like early days. Very early.
Kane: Pretty exciting too.
Laszlo: That’s how we got into it.
Kane: You were using the ScrumWorks tool that you guys built. You were
using it as a lead
Laszlo: Yes. [inaudible 08:23]
Kane: Originally it was free. Primarily lead generation and at what
Laszlo: An brand awareness, right. Brand awareness because now you are
brand to these mega companies, right? Here’s a little company in
Seattle. We’re not going to get the attention of Capital One. Why
would we? [inaudible 8:43] for example.
It provided a great kind of talking point. Then we just kind of built
a business around that. We had a freeware product. We had a training
business. We did some coaching work, some transformation work. But
that was kind of early days on the transformation side as well.
I mean if I remember correctly you were at Qpass which then got
acquired by Amdocs and the Seattle market. We had folks at City of
Seattle. You know, just trying to build a business, right?
Kane: At what point did ScrumWorks become a commercial product? Because
it’s now a
Laszlo: Yes, so great question. So it became commercial, we did a
double down in late 2006
and all the money we made off of that contract in Washington State,
instead of putting it into our pockets we invested that in a
We ended up funding that development team and launching a for pay
product January 15 of 2007. So, that’s when it hit the market as for
pay. We had two versions. We had kind of this what they call freemium
model. We had the free version and the paid version.
Kane: How did that work out? How did that commercial product work out?
Laszlo: I think it worked out okay. I mean, we were able to, again if
you’re looking at the
history, right, between 2007 and 2010, we were able to hold our own in
the market. We eventually ended up selling DanU as part of that
That acquisition, we sold the company in 2010, February of 2010 to
CollabNet. When we sold the company we had, I think, in the
neighborhood of 20,000 paid users and 125,000 free users. So,
substantial user base.
Kane: Yes, I was about to say. That’s fairly sizable. That’s nothing to
sniff at, at all. Quite
Laszlo: I think if you were early days, like if you were really in the
Scrum community in ’08,
’09, ’07, or, before you either tried ScrumWorks on a project or you
used ScrumWorks. Even if you didn’t like it, you at least took a look
at it. That was kind of my feeling.
Kane: It was certainly very common. I don’t see it quite so much anymore
because there are a
whole bunch of other free tools that people use. So, for example,
Trello is a very common one to see at the moment.
Before that, oh gosh what was it called, Pivotal. Pivotal Labs, their
free tool used to be, maybe two or three years ago, used to be really
common but certainly before that ScrumWorks was an equivalent piece of
software that people would often try and use.
Laszlo: Yes, yes.
Kane: Cool. You sold the company to CollabNet in 2010. What happened after
Actually, let me ask. How did that all work out? Did that work out
alright for both you and Victor?
Laszlo: Yes, I think so. I think when we started the company we never
knew where it was
going to end. We started the company early days. We started in 2000. I
had just graduated from college in May. We started the company in
August. I essentially took the summer off and started a company which
was an interesting journey in and of itself. Just learning about
business and people without any kind of world business experience.
We learned a lot of lessons the hard way about people and about money
and all those things, financing and all that stuff. I think when we
sold the company we had wonderful team. I mean you were part of that
team for many years.
We had other people like Angela Druckmen, Jimmy Fostic who kind of
came in later and just a great sales team. It really did feel like
family. I am really proud of those accomplishments.
You know, Victor and I did well as part of that sale. I feel really
good about that. I feel like CollabNet got a good deal as well. So I
wouldn’t, I think both sides benefited greatly.
Kane: What drove you to sell the company at the end? What was the
Laszlo: Yes. We had no venture capital money. We had essentially no
banking support, and in
terms of a big debt or round or something like that we had very little
friends and family money in the business.
When you’re carrying all of those things on your own shoulders, you
know it can kind of ground you down and wear you out. It was getting
to a point where it was affecting my personal relationships and I knew
enough to know that that was bad.
The other thing, right, was the September of 2008 crash, financial
crash. That definitely scared us because we kind of had meetings in
October, November, December, looking at each other and going we’re
doing everything right and the world around us is collapsing and you
can’t really talk to any honest CEO who would tell you that their
business was growing in 2009 in a space.
Most of us were flat back or growing a little bit. So those things all
played into it. We just didn’t know. The other interesting thing at
that time right, if you go back to the history and the politics of the
Scrum Alliance at that time, there was a lot of uncertainty within the
Laszlo: There was a lot of uncertainty around Ken’s role, around what
Jeff was doing, around
what Mike Cohen was kind of hovering around wanting to take a
leadership role or a bigger leadership role.
You had guys like Tom Meller in there and we just couldn’t make heads
or tails out of the community and we were very concerned that it would
become fractured. You know, similar to kind of the Linux just
In fact, that’s kind of how it played out because you have scrum.org
and you have Scrum Alliance and you have a number of different
certifying bodies and if you listen to them they’re not really aligned
We thought they were going to be more divided. I guess there are some
common threads but we thought it was going to be kind of divided. So
those things all played into it. All played into it.
Kane: You were at CollabNet. When you saw the company, you joined the
company as well.
You joined CollabNet?
Laszlo: Yes. I was at CollabNet about three and half years and you know
they provided an
extremely positive experience for me as it relates to some of the
things that I was able to do. I mean, my boss Mike was great in the
sense that he enabled me to go out and become, I’ll say, a real
What I mean by that is, I’ve done over the past and I know you’ll
recognize this. Over the past three years I did a half million miles
of air travel and global travel. I was vice president of Asia Pac for
a year which meant extended trips to Korea, China, Japan, as well as
Malaysia and Singapore.
All those things kind of helped me understand how different people
communicate and gave me a broader concept of just people in general.
It gave me broader perspective and helped me mature.
At the same time it was all still within Scrum and Agile domain. It
kept me kind of focused and interested in the community in general.
But you know, you go into Korea, I was in Korea in 2012 having similar
conversations that you and I were having in 2005 around how do you
scale from one team to three teams or what do you do with HR? So the
kind of, in that sense, organizational issues are a little bit behind.
They are kind of the cutting edge stuff today in Agile and Scrum is
cutting edge maybe in North America and maybe in Europe but in other
parts of the world it’s still lagging maybe.
Kane: That’s very true. That’s also true here in the Australian market.
Australia is a couple of
years behind probably North America.
Laszlo: But it was fun. I went to India. I went to Brazil. According to
TripIt which is the
program I am using to track it, I’ve been into 100 different big
Kane: That’s a lot of cities.
Laszlo: Yes, it’s kind of fun if you look at it that way. A lot of time
away from home and
all that. I sat down with my bosses at CollabNet earlier this year and
I said” I kind of want to travel a little bit less” and we couldn’t
come to terms on that. So I said, “Okay well, maybe it’s time for me
to make a switch.”
Kane: That’s why you’re at Solutions IQ.
Laszlo: Yes, that’s right. I’ve known Charlie the owner of Solutions IQ
since kind of 2004
time-frame because we were competing against each other at the state
contract and I came in and talked to them and they really, my feeling
is here at Solutions IQ we have agility and agility in our bones and
in our DNA.
It’s been a transformation. It wasn’t the case say in 2004 or 2005.
It’s just wonderful. You feel like you have a seat at the table. For
example, tomorrow we’re bringing all of our consultants to our home
office and we have about 125 consults today out doing different
projects around the US.
They’ll come in, they all fly in tomorrow, and we’ll do what we call
retro-space which is a retrospective and an open space around
Kane: At the same time? Cool.
Laszlo: That’s cool. For me that’s interesting.
Kane: Yes. Solutions IQ, is it still predominantly a Pacific Northwest
company? Or has
Solutions IQ expanded nationally within the US?
Laszlo: Yes, so great question. So great brand awareness here in the
especially here in the Seattle area. One of the reasons I was brought
in is to expand that presence and build it to what’s called a leading
domestic brand, which means having more and more projects out of state
in places like New York or Michigan or Texas or California.
Laszlo: Or Ohio, right. that’s part of my mission here and my role here
is, I guess, Vice
President and I’m doing things related to sales and marketing and
training operations. It’s a pretty weighty goal but I think it’s a
pure services company, so I think we’re going have some success with
Kane: Cool. When you say pure services, does Solutions IQ not produce any
products at all?
Laszlo: That’s correct.
Kane: That’s interesting. I always thought that they might have something
but not the case.
Laszlo: Nope. Not the case. Again, that’s part of the make-up of the
organization. No products.
In that sense, I think we’re positioning against some of the folks
like ThoughtWorks we have kind of a difference of the DNA there.
ThoughtWorks to me is different in the sense that kind of come watch
us work. You know, versus with us it’s kind of like come work with us.
It’s kind of a little bit different. Again, also right they have the
Mingle product and Go and some other products.
If you don’t want to use those products then they may not want to do
business with you.
We have some neutrality there.
Kane: Yes, absolutely. Cool. Cool. So that covers my first couple of
questions which are,
how did you come to the Scrum community and also what are you
currently doing now? Where do you see the future of Scrum going? Where
do you see the future of Agile going?
Laszlo: Okay, I have the same question for you. You should answer
Kane: Do you want me to go first? Or do you want to go first?
Kane: I’m not sure. I’ve got no idea. I really don’t.
Laszlo: Really? This one time. Right. I mean you’ve been in industry
since before it was an
Kane: Yes, it’s really hard to say and the reason why I say that is because
my feeling is that
there will be something very similar to Scrum around but whether it
will be called Scrum in ten year’s time, I don’t know.
I think the elements, the basic structure of Scrum, is so fundamental.
I think it’s just really, really a very fundamental and a very natural
framework that going forward there will always be some element of that
framework in whatever we do.
Whether it will be called Scrum or whether it will be called Agile,
whether it will be called something else, I really have a hard time
trying to see that far into the future. At the moment, the feeling
that I’m getting is that in large part the words scrum is heavily
overused and the word agile is heavily overused.
People will use the word agile for whatever they are doing. They are
doing waterfall in three monthly cycles, they will call it agile.
They’ll call it agile waterfall or something like that. And people put
the brand Agile on just about everything.
I was speaking to James Copeland. I was speaking to him three or four
weeks ago and he said that the Japanese have the notion that you can
overuse a word. You can over tax the spirit of a word and when you do
that, then the word loses its meaning. I think that’s a very valid
point with the word agile.
I can see or I can speculate that maybe in five or ten year’s time,
the whole word or the whole agile movement could be something people
frown upon and people will want to distance themselves from. So where
will Scrum be in ten year’s time? It’s very difficult to say.
I think there will many people who will be doing Scrum like approaches
to delivering software but whether it will be called Scrum or not is a
Laszlo: Yes, it’s interesting you mention Cope because I actually had a
with him in Tokyo about Japanese people. But anyway, that was kind of
an interesting dinner actually. Yes, my take on it is actually a
little bit different. I think we still have a huge runway here.
I think there is a huge market. I think we’re just now getting into
interesting questions. For example, the questions around compliance.
To me, doing Scrum in a heavily regulated industry which there are
many or trying to contemplate. Like one of the research projects that
Pat Reid and [inaudible 25:42] involved in.
I don’t want to say helping her with but it’s an area of interest for
me as well is around how to navigate the generally accepted accounting
practice rulings in the US with Scrum teams because those rulings were
written with waterfall teams in mind. When we start hitting those
kinds of boundaries, that tells me we’re having success.
When we have known organizational patterns or enterprise patterns for
those types of things that’s when I kind of know it has run its
course. I don’t think it has run its course yet and I remember how you
used to feel about this years ago, but there is distributed and large
If I remember correctly you didn’t even think you wanted to build
software with 10,000 people or something like that. Philosophically
that was kind of your take if I remember. Is that still kind of where
Kane: Yes absolutely. Yes.
Laszlo: My point on that is that to me it depends on what you’re trying
to accomplish. But at the
end of the day, right, it still comes back to kind of those notes. The
teams doing the work or the people doing the work or the work products
in and of itself. That work will continue forever and then the other
thing, right, is you have this kind of I’m going to try to draw a
graph here with my hands.
You have kind of a timeline, right, on the “X” axis and you then you
have your number of software developers in work world as an axis and
then you have your lines of code. Your lines of code are growing
exponentially and your number of developers is not.
Even companies that are not, you wouldn’t necessarily consider to be
software companies. For example, American Express, Chase, or Capital
One. We were talking about Capital One. Or American Express or take
for example Fed-Ex.
Fed-Ex I think has like 7,000 software developers. American Express
has 12,000. The amount of software that needs to be done to support
these non-software organizations is incredible which tells me that
we’re going to hit a tipping point, right?
people are going to get frustrated. I don’t think we’re even close. I
think you’re looking at you know a 30 or 50 year run here.
Kane: That’s fantastic.
Laszlo: It’s not close. I mean you can’t tell me that, you know people
talk at these big
companies. I don’t want to name a company but say a random big company
that is talking about business agility. They are talking about
maneuverability, being able to maneuver your business. That’s very
different than the rigor and discipline it takes to run a Scrum team.
Kane: I totally agree.
Laszlo: It means something very different. To me, that’s kind of where
we are going. So that’s
my take on it. Another 50 years. That means we’ll have grey hair by
Kane: Yes. Absolutely. Actually, from a business point of view, I really
like what you say
there because from a business point of view, it does give me a lot
more hope because I do tend to be incredibly cynical and perhaps
overly so. But that’s just me as a person. So I do tend to be terribly
cynical about the whole thing. So to get a second point of view is
really, really good to hear. Really interesting. Cool.
Laszlo: Yes, I appreciate. I appreciate the opportunity to do the
interview with you. I hope that
someone will watch it and we can get some hate mail going or
Kane: Fan-mail as the case may be.
Laszlo: That would be great. So thank you for the opportunity Kane.
Kane: Thank you very much for your time Laz.
Laszlo: Yes. Cheers.
Kane: Bye, now.
The post How did an entrepreneur grow a successful product and services business around Scrum appeared first on Scrumology.com.
Often the introduction of new methodologies and change programs are overwhelming for important professionals whom have no capacity for “another fandangle change movement” as a wonderful engineer once told me. He is quite right! All too often agile change programs are directed upon people without; compartmentalising time to complete current expectations, time to learn, and time to practice the new introduced methods.
The example below is based on an engagement with a very small and extremely important Environment & Configuration Team supporting multiple project teams through releases every 8 weeks across an 8 digit valued delivery program of work. Often these operation teams are the engines that can’t stop; they service multiple managers, teams and departments; and the last thing they (think they) want right now is to give precious time working with (another) Lean Agile coach. Add to that boiling mix of gurgling soup was a built up agile coaching resistance. I was the fourth Coach brought into to assist because previous adoptions hadn’t achieved fluidity; the combination of high demand, complex conditions, and conflicting relations had burnt through the well intentioned previous coaches.
As coaches we know that time invested in Lean and Agile methods is time exponentially returned; however, even after reviewing the evidence, many people are literally too stressed to consider new ways of working.
“I can’t make the old way work after all this time, and they said that was a new better way of working back then too!”
So I decide to go with the flow. If that was there world, then I became in rhythm with it, and rather than interrupt it with new ways of working I decided to add a new beat that was in compliment to the flow of work they had to maintain.
First I sat with them – there home was my home. I observed their world carefully – the patterns and streams of work in flow. I listened, and listened to assure that I truly understood what was happening. I listened to what was truly important to these guys and then in a briefing to the Solution Manager on the approach and why he will get value for endorsing my coaching, it came out almost like a whilted hope that had long ago become impossible. One of the guys said “I’d just love to get home to dinner with my son at least once a week”. There it was, the underlying “why this is valuable to me”. Without that why as a coach you won’t get people buying tickets to your agile journey. That become our commitment we would all work for.
Secondly, with managerial nod and a very human aspiration I negotiated just 15 minutes a day to start adding in all that good healthy agile stuff!
15 minutes a day is initially not a daunting amount of time to give up, to start focus on learning, and it also became the most important time of the day as it set the focus and created opportunity to continuously improve. (As a coach it was excellent as it also trained me to be very succinct and relevant in the teachings during that short time.) First it was 15 minutes of listening daily (in person, fact was at that time I was 80% listening, watching, learning about them and 20% coaching).
As the days progressed the team were able to expand their ‘learning listening’ to take on doing personal kanban – a wonderfully simple Lean framework to initiate agile principles and a good coaching engagement. Stage by stage, day by day I guided the team through visualising ALL their work, and to build understanding of the demand tunnels that previously drove their work. Identifying where they create value, and how much they do to fix failures. They practiced flow through concepts, experimenting with their WIPs. They achieved an extraneous amount of work in their first month. Not necessarily a massive chunk greater overall, that wasn’t important. They did it without having to do the normal amount of overtime. Not only did they surprise themselves, the key reward was being able to sit back and actually see their achievements on the wall, share those achievements, understand their capacity and start to go home proud. Previous to seeing their accomplishments visualised on the wall they stated “I’d just go home and pass out on the coach wandering if I was ever going to get on top of it all”.
Over the second month the team tested out concepts of focus, noise deflection, prioritisation models, retrospection and request methods to really hone their self organising skills. The 15 minutes would occasionally expand as the team needed. The beautiful thing was that the time extension was their choice based on their needs. They were experiencing a return on their 15min time investment for themselves and as a coach I was accessible, available and pulled the knowledge they needed when they needed it. If I didn’t know the answers on the spot I would research, investigate and find the resources or people that they needed.
In the third month the team felt confident enough to initiate their own program group stand-ups. The team pulled together the key doers from the multiple areas they serviced. The content focus of the stand-up was their shared work area. In essence the team – who three months earlier was too under the pump to learn Lean & Agile methods – was now hosting their own stand-ups, running an improvements backlog and teaching others what they had learnt 15 minutes a day.
This post first appeared as “Using Kanban to simplify and save time on complex enterprise projects” in December 2012. Thanks, Stephanie, for contributing it!
Last week I publish the first part of my interview with Alan Cyment, and this post cover the second part of the interview. In this second part Alan introduces me to an exercise called a Pro-Action Cafe, talks about his current work translating Tobias Meyer’s book, re-writing his CSPO course, and self-organizing conference.
And, you’ll want to stay to the end to hear how much time he spent at business school!Transcript Alan: I recently took a three day workshop here, in Buenos Aires,
very interesting, it’s called the “Art of Hosting”. It’s a term that puts
together different ways of doing the conferences, they call it the “Art of
Conversation.”Interviewer: Right.Alan: Open space world cafe, which I don’t like that much. And I try,
I recently tried… here, listen because this is going to help us both.
Alan: They showed us something called “Pro Action Cafe.” Have you
Interviewer: Pro Action Cafe?
Alan: It’s a mixture between open space and world cafe, and this is
where our worlds meet.
Interviewer: No no, this is interesting, how do you run a pro action
cafe? What’s the difference between?
Alan: Its, I think it was created for entrepreneurs but I’ve been
using it to wrap up all my CSM courses now, and I’ve been using it inside
companies. It goes like this, it opens up in a circle just like open space,
but what you’re asking is not for sessions. You’re asking for
entrepreneurs, you’re asking for projects. So at the end of my CSM courses,
especially if it’s in company, I ran one a couple of days ago. Very
intertesting. Three companies in Uruguay got together to organize a CSM
course, so it was like six, six, and eight people.
What I asked them, you count the number of people you’ve got, you
divide them by four, and that’s the amount of, and this is the big
difference with open space, this is the maximum amount of sessions you can
have. I had 20 people there? We only had space for five sessions, so you
put only five sheets of paper in the center of the circle, and the people
who go there, what they have to tell is, they have to describe, a project,
in the case of the CSM is, a project that would… I actually changed the
name instead of “Pro Action Cafe” I put “Pro [inaudible 0:51:42] Cafe.”
So, you had to tell us about what sizable change you wanted to make
in your organization. Sizable shift, inspired by what we have talked about
in these few days, actual scrum or something around it. People briefly
explained just like in open space, then the entrepreneurs become the hosts
of a world cafe, in the middle of the pro action cafe you’ve got a world
cafe, but it’s different. It’s oriented to the entrepreneurs, they’re going
to be the hosts, you have the table cloth with the paper, just like you
have with the world cafe. You have people sign up for tables before the
three rounds, and they cannot go to the same table twice, and you can only
have, this the one I learned, you can only have three extra people at a
table, so you have a total of four. So, the three questions in the pro
action cafe are always more or less the same. The first one is “What’s the
profound meaning of your venture, what’s behind your willing to promote
Your guests at the table what they have to do is, they have to help
you understand it, and as usual doodle on the paper. Then you have the
second round, the second round is, “What have you got, and what are you
lacking? Where are you standing right now in terms of possibilities?” Then
the third round is, “Whats the best next step you can take?”
Interviewer: That’s important that last one.
Alan: Yeah, and so, then the world cafe finishes, and you finish the
whole pro action cafe, its similar to open space, you gather all of the
people in a circle, but the only ones who are going to talk are the
entrepreneurs. They have to say two things. They have to thank the guests.
It’s better if they thank more particularly, “Kane, what you told me in the
second round make me change the focus of my project, it was really
important what you told me, now I’m going somewhere else,” or whatever.
So you thank people, then you commit to the group, to the next
action, and you tell them how you’re going to inform them what you results
were; that you actually managed to do it, to try it, and you succeeded or
you failed, or whatever. That’s where you finish it. It has a lot of power,
a lot of power.
Interviewer: I like it.
Alan: Very powerful.
Interviewer: I like the commitment at the end as well, the commitment
about what you’re going to do.
Interviewer: That’s one of the difficulties that I have with open
space, is that, not always but often, they end on a very weak note, so you
don’t know if there’s going to be any purpose or not, you don’t know if
things are going to change or not.
Interviewer: So, I find that very frustrating. This might be a nice
solution to that.
Alan: Yeah, I think, open space, sometimes, there’s always a dial
with limits when you want to tune self organization.I think that depending
on the commitment and discipline of the group, you need to add a couple of
rules to open space in order to make it have an impact.
When I’m facilitating open spaces these days, I usually tell groups,
it’s not enough, but at least during the five finishing minutes of their
sessions, they need to create a tweetable outcome of what they discussed,
so it’s either 140 words, or pictures, or a video or something. That’s one
step, but I think it’s better because if it’s a conference then it’s too
wide, but if it’s inside a company, then maybe you can put the theme
subject can be like “How can we work better?” So you have to leave every
session with a proposal. I like adding the small limits, it’s similar to
pro action cafe. I mean pro action cafe is brilliant, it’s mostly for
initiatives. It’s not for discussing subjects or whatever.
Interviewer: Yeah, vague topics.
Alan: Yeah, yeah. I’m going to get some tea.
Interviewer: Interesting, I wasn’t expecting to learn about pro action
cafes, but, it’s been a nice outcome, I’m going to have to look that up.
Alan: Oh yeah.
Interviewer: Take advantage of that.
Alan: Not that much material online sadly, but we have to promote it.
It’s very, very good.
Interviewer: Yeah, I certainly like that a lot better than an open
space, because as I said I think it looks a lot more… you know, the
outcome’s more tangible, than for a…
Alan: Oh yeah, way more. Absolutely.
Interviewer: Do you mind if I sort of try and go from there? Is that
okay? So you’ve talked about pretty much all of your journey throughout, up
to being a scrum trainer. What are you working on now? What are some of the
things that you’re doing now? What do you find interesting at the moment?
Alan: Couple of things, main thing I’m doing right now, is I’m doing
a translation of Tobias’ book.
Interviewer: Oh nice.
Alan: “The People’s Scrum” but it’s very interesting because Toby
told me that he didn’t want me to do a translation, he wanted it to be
Interviewer: That is so Tobias.
Alan: Yeah. I came up with the term “linguistic variation” like a
musical variation. So far I’ve been translating, somehow freely, so I try
to convey the meaning, but I do some changes. Especially, I add adjectives,
stuff like that, I like putting way more adjectives. I’m also planning, but
I haven’t done it yet, to add like a commentary to each essay, like; I
agree with this, I disagree with this, I think this is great, I think this
is not that amazing. Also, Toby told me that he would like me to add some
essays of myself so that we are coauthors of the Spanish version.
Alan: That’s my main focus today. I’m also running courses, I’m
running mostly CSM and PO courses. I started very late in my CST career to
run PO courses, I think the failure I told you about before hit me so
strong, that I always thought that I was not ready for it. I need to learn
more, I need to learn more.
I had a weird interruption in my scrum career, when I decided to
quit, last year. I had planned that for a long time, to go for a full time
MBA in Spain. We moved to Spain with my wife, and I said I’m not coming
back to the scrum world. This first idea that change every year, I wanted
to make a sudden or big change in my work life, I needed to change
industry, I need to change everything.
Alan: But it was too artificial, it wasn’t organic at all, and I felt
so out of place at business school, which every single family member,
friend, and colleague had told me for the past decade. Because for some
reason, for 2002, I visited my sister, she was doing a master’s degree in
Columbia, and she told me about what an MBA was, and I said I need that.
I got obsessed with it, and I quit it but when I when I was there, I
said OK I might come back to the scrum world. I said I want to learn way
more about PO stuff, so I started; Europe is small so I started traveling
to visit other CSPO courses, email the trainer and ask them, I think I want
to Gabby Benefield’s course. The main one that I went to was Jeff Patton’s.
Interviewer: Yeah, yeah. Great course.
Alan: I went to CSPO course in Moonage. It really shook me; I said
“This is something that I really need to focus on.”
I had been reading a lot about the Cerna stuff and customer
development and I said I want to focus here. I didn’t want to do a PO
course that didn’t have a statement to make. Because my CSM course has a
big statement, a big push for the, what did I call it? Actually I got the
term from Toby I think, “The Spirit of Scrum.” The spirit behind the law.
My PO course was going to be discovery not delivery, well, discovery over
Interviewer: Right, Okay. So, discovery of what the business is.
Alan: Yeah, well, actually I took the terms from Jeff Patton; he says
that if PO’s task has two main tasks, delivery and discovery. We do a tiny
little bit of discovery at the beginning and then we go all for delivery.
Interviewer: Yeah. Absolutely.
Alan: We turn on the engine of this train and no one’s going to
change the goal. This focus on learning about the market all the time, and
being. I love the idea of intellectual humility that is needed to
understand and do scrum. I think in order to be a PO, you need to be
amazingly humble, intellectually, so that you can acknowledge that you will
never understand the market, so you can only do experiments with it.
I’ve been focusing on that, I’ve been preparing and running CSPO
courses, and trying with the Inception Deck from Thoughtworks. Doing PO
stuff, and product development stuff, I’m really interested in that, and I
have this weird idea, you told me, is my face getting too dark? The sun is
Interviewer: It is getting very dark, you getting difficult to see.
Alan: I’m moving; let’s see if it gets better this way.
Interviewer: That’s already a lot better.
Interviewer: Ah, very nice. Perfect. You’ve got some CD’s and books
behind you, I think.
Alan: Actually, these are board games.
Interviewer: Very nice, Scrabble.
Alan: Yeah, Scrabble on top, [inaudible 1:05:10, and a puzzle. Oh, I
want to show you something that I sometimes take to some... it's very
delicate, so that's why I don't take it to every single course and coaching
engagement, but when I get a client that's always criticizing everything, I
give them this glass that my wife gave to me. It's, I'm sure it's when I
read, but it says "Half empty" and "Half full" and when you pour water or a
liquid in it, it starts filling from here up. It's very instant, the
message gets delivered, like this. So I've got this crazy idea, that I
really want to try, when I was in Costa Rica, one of the main things that I
enjoyed was all these conversations with the PO, defining features, I
really enjoy the product thing.
Alan: Especially, Latin America, Argentina, maybe for lack of
investment or whatever, there's a lot of focus on the software world in
this being services.
Alan: Used to be off shoring, but now the currency exchange rate has
changed and we are way more expensive, but it's still services. So no
products here and I find that boring. I always think, the world of software
can be seen from two perspectives, the project perspective, and the product
perspective. And the other perspective is going to be a slave of the other
So you either see the world of projects that may have a product
behind, or the other way around. I think that the project view, which is
way more prevalent in our region, is short termed, is way less prone to
collaboration, and the main thing, the main difference, is I think its way
harder if you're in the project mindset to be passionate about what you do.
Alan: Actually, Jeff Patton's CSPO course is called "Passionate PO
Ownership," he doesn't actually mention this explicitly, but I always think
a project manager could be passionate about his Gantt chart, maybe. But, I
don't think there's any possibility, anyone in the team might ever be
passionate about the Gantt chart, but, people on the team will get
passionate about product features, about the product, about users.
Interviewer: Yeah. Especially if they can see it, if they can see it at
the end of the sprint, I mean, that's a very powerful motivating factor.
Alan: Yeah, but, if what they see are features that are actually in
the end of the day, what they are, are just tasks that are going to be
ticked in a Gantt chart, the feature is slave, it's something that's a
consequence, but I mean the main goal here is to tick...
Interviewer: The box.
Alan: Yeah, tick the box. So, it's very hard to become passionate
about it, and I became really obsessed with this notion. I remember in
Costa Rica, I had great weekends. I always took busses to different
beaches, and trails and stuff, but I remember that for the first time in my
life, when I was in Costa Rica, it was Sunday evening, and I would have
liked to have stayed at the beach, but I really wanted... I was eager for
Monday morning to arrive. I said, whoa, this is the first time that this
has ever happened to me.
Alan: That's when I thought, scrum is the art of loving Mondays.
Interviewer: That's a great phrase, "Scrum is the Art of loving
Alan: Yeah, actually, it used to be the tagline of my blog. Then I
stopped writing it, but, actually the blog was called "Luna De" which is
"Mondays" in Italian. "The Art of loving Mondays," it's playing with
things, and experimenting, and the end goal is for everyone to love
Mondays, your clients, and the team. OK, where was I going? So, I was
obsessed with all of the building products, our lack of capacity, financial
or risk taking ability, or whatever, and we're not developing that many
products. What I thought was, to try this model, actually, I thought it for
the first time, for unemployed developers, but the thing is, there are no
unemployed developers, it's a sparse population.
Interviewer: Yeah, good point.
Alan: I have met all these service companies, that have a lot of gaps
in their assignments, they have people that are idle, because they don't
have a project, so until a new project arrives, they aren't sure what to
give them. They develop internal systems, they do refactoring or automate,
many things, but they might need to stop at one time, because a new project
can arrive. Only big companies, I think have enough idle time so that, you
got critical mass of idle time so that you build a good product. It's hard
to actually build something, so what I thought was, why don't we join
forces? Between a lot of companies that have little spare time, and maybe
freelancers that have a little spare time, and unemployed people.
Basically, my idea is to come up with development that similar to
open source, but its commercial, so you develop a product, and you sell it,
and you have like collaborative capitalism iterations, a cadence of
collaborative capitalism. I need to try this, each part, each service
company, and each individual, each one that's putting effort into this,
lines of code, tests, or tweets, or whatever, needs to vote anonymously,
how they would divide up 100 points between the other people, the other
individuals. Then you sum up, get the average and do the splitting.
Basically the thing is embracing subjectivity, embracing the fact that it's
absolutely impossible to measure each one's contribution and productivity.
So, because it's impossible, what we're going to do is subjectively and
collaboratively, so, this way a lot of service companies could start
developing a lot of product in their spare time and they could develop cool
products and also start collaborating with other companies. That's an idea
that I've been working on, but I still haven't had the time to actually put
Interviewer: It's an interesting idea. So, basically you would work
with a number of different parties to build a collaborative product. Who
would be the product owner in this particular role?
Alan: That's a good question. I think the product owner should be a
constant permanent role, someone who would need to invest, not full time,
but I think the product owner is the first one to appear in the scene. I've
got one example or one project that I would like to start with. There's one
more thing that I'm working on, well a couple of things, you tell me when
Interviewer: No, no. This is interesting. I'm intrigued. I like this.
This is a really interesting idea, there are a lot of issues that I can
see, I mean, different parties will want to deliver a different product, so
how do you manage that? How do you manage that dynamic?
Alan: Well, its stakeholders that want to do different things, it's
the PO as facilitator, and the PO is predetermined. I love that definition,
the book is, well, I don't have it over here; the facilitator is a person
from a neutral point of view helps a group of people make a non trivial
decision. So it's tough.
Interviewer: Yeah. Absolutely.
Alan: I've been experimenting with this open space, it's basically
open space, but I realize that at least here, in order to do an open space,
we needed the approval of a University so that it can give us space, No, we
have exams, we can't do it, we don't have the money to rent a space, and I
said, "Okay that's pointless, why don't we just do it outdoors, or in
parks." I came up with the phrase "Agile is in the air." I started doing
open spaces in parks.
Interviewer: Up in the air.
Alan: Yeah, if it rains that day, it hasn't yet, but, we can rent a
football field, you know you rent them by the hour, and we do the open
space there. It's been great so far, we haven't been able to gather too
many people yet, and we've done many. We've done it on Saturday, week days,
near downtown, actually some guys in Spain and Columbia, and Uruguay,
they're trying the idea. What I'd like to do is, I'd like to have a
website, like Agileisintheair.org, and the main thing is you see all the
agile's in the airs.
The thing is, if you want to sign up for it, you want to go, the
price for the entrance, for me organizing it is nothing, it's just putting
a date and a place, also its sort of, it's like a backlog of needs. Things
that need to be done, or, it's your actions, may times its things that we
need for the actual open space. For instance, it would be great, we will
need to do once, if we would collaboratively prepare the food, so that we
don't have to hire. Because the open spaces that I have been to have always
had this traditional conference mentality behind it. With organizers and an
assistance, and paying an entrance, and there's food available, and there
are breaks. That's not self organization we've got to get rid of all of
that. I picture this, you've got this list and it says "tomato, lettuce,
bread, knives" so when you sign up for "Agiles in the Air" you commit to
bringing one of those, so no one else is going to bring bread, so if the
day of Agiles in the air, Al doesn't show up, we don't have bread.
Interviewer: That's great.
Alan: That will have a price to pay.
Interviewer: Yeah, absolutely.
Alan: During one of these Agiles in the Airs, one that was around
games, I think I presented a session or a discussion topic was
gameification of scrum, over agility. I came up with this game that I
really want to develop, when I first started in Costa Rica, this is very
basic, I wanted everyone to do TDD for instance, and they hated the notion,
and they started saying "No, it's not for us, it's not for this domain, and
it's not for this language." So, I got very angry, and I became very
insistent and things got worse. I remember a guy, Martin Sadiez, which I
respect a lot, told me, in the user form, that something so basic but they
will never adopt it if they don't see the need for it.
Interviewer: Very true.
Alan: I decided I coined the phrase "stealth zealot"; I was the
stealth zealot. Actually, trying to translate it, if we have a second, I
want to look up this word in the dictionary. It was actually a Taliban...
like zealot, it was a scrum...
Alan: Yeah, the crouching zealot. The crouching fanatic, so that's
it, the initial point, I just love this thing, but I'm going to be
crouching, because if I come running to you telling you this is the best,
you're going to reject me.
Alan: So, I'm going to be crouching, and then what I realized is,
this is just exactly the same as with the product, the process should be
organic, just like what I had seen in Ken Beck's book, this is a tree. I
started, especially with CSM courses, telling people that I like the
approach of what I call "organic scrum" which is that scrum is only
retrospective, and a change agent and everything is going to grow from
there. I call it PDF, Pain during Facilitation, so maybe a little bit
product owners, and a little bit of daily meetings, until it grows to a
full blown scrum. So I wanted to gameify that, so I came up with this idea
of talking with people there, an agile orchard, so you get like a website,
like a social network, where every team has their orchard, and you get
different plants, different trees. You've got the self organizing tree, and
the software quality tree, and blah blah blah, and the strategic planning
tree, continuous improvement tree. Maybe, you have like an assessment, I'm
not sure how to do it, maybe you can see you plants, or maybe you start
like that, and in every retrospective you answer some questions, and you
see how your plants start growing.
Interviewer: So you try and grow the trees.
Alan: Yeah, you have different trees, you have a big healthy tree in
software quality but your plant in, I don't know, self organization, or
commitment, or whatever is tiny, and what the most interesting thing is, if
you don't water your tree, if you don't access the system, every one or two
weeks, you trees begin to dry up, begin to die. It's like a Tamagotchi,
like a scrum Tamagotchi, and thus teams will start visualizing that it's a
fallacy to pretend that their process is going to stay the same if they
don't touch it. I want to try out this product with the model that I told
you before; I would like to be the product owner of that development.
Interviewer: What do you envision will be the outcome? A software tool?
Alan: Yeah, it's a website where every team has like a Facebook wall,
you have your orchard, and you can visualize rankings, teams with the
healthier gardens, orchards, are teams with left, and I came up with this
business model where the website is free, but it's public. If you don't
want to see how awful your teams are, you pay for the enter price.
Interviewer: That's cunning. That's a very clever approach to pricing.
Alan: So there's some business model as well. After finishing
Tobias', well our, book let's say. I think I'm going to focus on that. Try
to focus on actually delivering that. Presenting this idea in as many
places as possible and seeing who would join this open source for money
idea but I need to come up with word for, give it a try.
Interviewer: Rather than saying open source for money, perhaps you can
say collaboration, commercial collaboration, or something like that.
Alan: Yeah, I thought about collaborative capitalism.
Interviewer: Yeah, collaborative capitalism.
Alan: When I say open source for money, so that people understand the
dynamics, of the actual collaboration of it, but the spirit is way
Interviewer: The problem with the words, open source, is that there are
so many different connotations to it.
Interviewer: It comes with a lot of baggage, and that's a good thing
and a bad thing at the same time.
Alan: Or collaborative product development or something like that.
So, those are the things today.
Interviewer: Cool, interesting, and so, what does the future hold for
you? I mean, it sounds like you're really moving towards producing
products, and you're trying to, correct me if I'm mistaken, but it sounds
like you're pulling away from the scrum community? Would that be a fair
thing to say? Or the training community perhaps.
Alan: No, no no no. I didn't mention that much, but I love tweaking
the course and I've been doing way more coaching, during these past years,
I almost didn't do much coaching at all, I traveled a lot. I decided to
quit traveling, mostly for health reasons, and so I focus way more on
coaching. Right now, I'm working with two clients, and I'm looking forward
to working with more.
Alan: Actually, maybe I didn't mention it because coaching is like
doing sports; you have to do it to at least stay healthy.
Interviewer: Yeah, absolutely.
Alan: That's ongoing, then maybe, in here in Argentina, expanding and
forming a team of coaches and trainers maybe, that might be interesting.
I'm still planning my life after the cancellation of the MBA. Actually, I
found a master degree here that I find tempting now, because I thought I
was never going to do a master after quitting over there, but its part
time, it's in Buenos Aeries, it way more abstract and theoretical than an
MBA, it's called "Organizational Studies" so I might want to give it a try
Interviewer: What is the attraction with doing an MBA, and the reason I
ask that is that it seems so very different from the type of person that
Alan: That's what everybody said, and they were right! You mean the
Interviewer: No, I mean even still... because to me...
Alan: No, no I don't want to do it any longer.
Interviewer: Oh, all right, yep yep. To me you seem like you're very
focused on self organization, on cultivating people, on doing things in a
very natural organic way, for lack of a better term, and MBA strikes me as
being the opposite of all of that.
Alan: Yeah, for reasons I'm still trying to understand, I became
obsessed with doing one. Buenos Aeries has the highest Psycho-
Alan: Psychoanalyst to [inaudible 1:29:31] in the world, so I’ve been
to a psychoanalyst for over 14, 15 years and I’m still struggling with
this, so I don’t know why the hell I did it. But I don’t think I will do
it. This is more of starting organizations. I’m really interested, I ran a
CSM course two weeks ago for a fabulous, I think it’s a company, I think
you can call it a company. They are a cooperative, you have many
cooperatives in Argentina, but they usually form after the original company
goes bankrupt. The employees rescue it, so that they don’t go bankrupt. But
these guys formed the software development cooperative from scratch, ten
years ago, they are 140, and one person is one vote, they democratically
elect their managers.
Alan: That is very cool, and I think that is the future. I mean,
after working with them, every time I go to another company, I see them
with different person, I think, why are these employees staying here? Why
don’t they just form a cooperative, because the first capitalism, while you
needed the means of production, the guy with the capital had the machines,
so I cannot go and make my own company, but in here the capital is the
employees mind’s, their brains. So, why don’t you just take their
Interviewer: Do their own thing, yeah.
Alan: Yeah! Computers are almost free, so you can develop anywhere,
so every software company should be in one way or another, a cooperative.
It’s something that I would like to, if I get into this master for
instance, I would like to…
Alan: Understand better, I want to start working with these guys, see
what the deeper connections between cooperative companies and scrum are. I
think if you pull the pedal, the accelerator, if you start going faster and
faster with your scrum car, at one point or the other, you should reach the
moment where you ask yourself why aren’t we a cooperative, and I think that
might be something (inaudible). I saw this very clear here, with this
company, it was frightening.
Interviewer: Doesn’t the fact that there’s a product owner role, who
has arguably the most influence in a scrum team, doesn’t that go in
contradiction to a cooperative?
Alan: If you see the product owner as colleague who has a different
responsibility, then I don’t see a contradiction, he’s just one colleague
who has a strategic view, we are the team and have a tactical view, and
that’s all, but if you’re not the best at doing that, then we can switch
rolls. I’m not saying, I don’t think cooperatives that split equally the
earnings are always the best, actually I don’t like that. These guys for
instance, the challenge is getting to the fair distribution.
Interviewer: Not only fair, but seem to be fair as well.
Alan: Yeah, fair and perceived as fair.
Alan: These guys have a table, so depending on the row, the salary
that they’ve got, its open its transparent, they came up with another rule
that’s interesting, that no one can earn 4 times that other person, that’s
very interesting, and then every year they democratically vote, all the
income earnings, whether they’re going to distribute it, or reinvest it. So
they vote on that, and if they vote to redistribute it, they redistribute
it using this table with an algorithm that takes into account the years in
the company. They have voted for instance, their director, which is like a
manager earns maybe 4 times more than a junior developer. I really want to
experiment with this algorithm that I told you about, everybody decides how
to split earnings from money or income among the rest.
Alan: And then you do the average. I’ve thought about scaling this
algorithm the recursive way, and teams decide how to split all the income
of the company between other teams.
Interviewer: But how will they know? I mean, unless you understand what
they do and in many large companies, you won’t do, you won’t understand the
context, how will you know whether they should get more or less?
Alan: I think this is a great incentive, so that there is better
Interviewer: Yeah, good point.
Alan: This enforce, to actually force, I’m thinking this for these
guys were 140. Maybe you need more recursiveness in a bigger company, but
it’s like scrum scrums, I would need to get the sweet spot, but individuals
can understand what the others do and the others contributions, so that
they do a fair distribution. Then inside the team they divide it among
themselves doing this algorithm that should be fairer. I want to start
trying this with a tiny percentage of income, maybe you can do this with,
and how do we split 1% of the income? Let’s give it a try, and how would
the vote result? If there is too much friction, but yeah that’s one thing I
would like to work on, actually I would like to have a structure like that
if I actually form my company of consultants which I’m not sure, some
mixture around that.
Interviewer: Why aren’t’ you sure? Because it seems like that’s
naturally where you go anyway, I mean, you said right at the start that you
wanted to form a company.
Alan: Yeah, I know. I’m very adverse to risk.
Interviewer: So, it’s a personal, I don’t know…
Alan: Decision. Yeah. I’m moving forward towards that, but I do it
Interviewer: That’s understandable.
Alan: Actually I remember when I tried to understand, or convince
myself, of why I was going for that MBA, what I said to myself and I said
to others is, I want to be taught how to embrace risk personally.
Interviewer: There are other ways to do that though, and it seems like
you have done them a lot already, a lot of the experimentation that you’re
doing, can be viewed as taking on risk.
Alan: It was definitely the wrong place to go for me; actually I
spent four days at business school.
Interviewer: Well congratulations on just understanding that it wasn’t
for you and then bailing after 4 days.
Alan: I’m really happy, yeah, it had a lot of consequences but we are
just about to move back to our original apartment more than a year after I
quit it, because we had rented somewhere else, so all of the rebuilding
part is tough.
Interviewer: But it sounds like it was the right decision.
Alan: It was absolutely the right decision, absolutely. It cleared my
mind and heart as well.
The post You won’t believe how much time Alan Cyment spent at business school! appeared first on Scrumology.com.
I wanted to call this interview “Agile hustle” because it’s a great story of how an employee in Argentina hustled to help host a Certified Scrum Master course, and then hustled himself into a conference and a new job. It’s an inspiring story of how commitment and dedication took Alan Cyment from Buenos Aires to Costa Rica, Europe and eventually becoming a Scrum Trainer.
This is really long interview so I’ve broken it into two parts. In this first part Alan talks about his journey to becoming a CST.
Join me next week for part two, when Alan introduces me to an exercise called Pro-Action Cafe, talks about translating Tobias Mayer’s book, self-organizing conferences and more.Transcript Interviewer: I think we’re live …
Alan Cyment: Okay, cool. This is exciting.
Interviewer: I always find it very strange, my behavior changes every
time that I hit the record button.
Interviewer: And I don’t know why. I mean, it’s purely psychological,
because there’s really no difference. But I always find my behavior
Alan: I guess the cost of error seems to be higher then.
Interviewer: Yeah, that could be it. I never really thought about that.
Let me give you a brief outline of what I’m trying to do. Basically, I’m
just trying to meet people within Scrum community roughly about, I don’t
know maybe, for the last couple of years. I noticed that there were more
and more people coming into the community that I simply didn’t know or
hadn’t met. Being out here in Australia its often very hard to meet people,
because, you know, the conferences are a lot smaller and the distances to
North America and Europe are far greater. I’m sure you experience the same
thing in Argentina.
Alan: Yeah, same thing.
Interviewer: And so, I wanted an excuse to go out and start meeting
people, and so I decided that the way I would do it is by doing interviews.
Asking people just basically, what brought them into the Scrum community,
how did they come to this Scrum community? Really, that’s how I’ve been
structuring these interviews. By and large everything is very free form; I
don’t have a terrible great structure for it. I let the conversation go
wherever it needs to go.
I typically talk about, or I try to talk about three things; What
brought you into the community? What are you doing now? And where do you
see things going from here? And so, those are really the three questions
that I try to structure the whole thing around.
Alan: Mm-hmm, all right, so, what brought me? I started as a
developer, a software developer at 19, and ever since I started coding, I
always felt like this kind of trade union view of a knowledge worker world.
Interviewer: Can you explain that?
Alan: Yeah, I read about Augusto Boal’s definition of oppression
later in life but I think I constantly felt oppressed, and I felt my
colleagues were being oppressed. Augusto Boal defines oppression as;
paraphrasing because I can’t remember the original, but it’s something like
“A monologue where there should be a dialogue.” I felt I was not being
heard, or listened to, or I was not even being asked about so many things.
I know when I started I knew the basics, what time to go to work, what time
to leave, and where to work, but then more and more stuff, like what was it
that we developed, or quality, or who I worked with, when we got to or not
to meet the clients, stuff like that. I naturally had a tendency to see
things from a made up perspective. So I was always saying, “This is not
working, this is not working, this is not working. Something needs to
change.” Then I remember in Argentina, it’s very common, I’m not sure if
it’s the same in Australia, while you study you work full time, or almost
full time. I remember I worked for six hours a day, so all my jobs there, I
took them as learning jobs, but then I learned that all of my jobs were
going to be learning jobs. So then my plan, or my strategy was to change
jobs, I mean I didn’t thought it from before, was to change a job a year.
Don’t stay in a job for more than a year.
Interviewer: Wow, that’s an ambitious target.
Alan: Yeah, and whenever I changed jobs, I didn’t just want to change
the company, I wanted to change something, transcendent is too much of a
word, some at least a minor focus in the work. I knew I wanted to have a
software company some day, so I said I want to learn the different aspects
of software development. So, I switched from size of projects, and
different things, and then I remember I had always developed object
oriented, but I took a class, it was actually focused on object
orientation, but it was with Smalltalk. I really got into it, and after 15
days or a month, I decided that I wanted to land a job where I was going to
use Smalltalk, because I wanted to learn it, and said, “I’m not going to
learn it if I wasn’t going to get paid for it or if there’s not any
commitment bigger than assignment for the university.”
So it was either an open source project, or a paid job, or something
like that. I got one, it was not that easy, and then I think I got without
knowing it, I entered the Agile world.
Interviewer: And what time frame was this?
Alan: This was in 2004.
Interviewer: What point were you into Smalltalk?
Interviewer: 2002, 2003?
Alan: Yeah. Then my first assignment when I entered the Smalltalk job
was to write an automated test.
Interviewer: Ah, very nice.
Alan: Because it was a very, or a partly low risk assignment. I
couldn’t break anything, at least I could build some false positives, but I
couldn’t actually break anything. I loved it, and at that time, I’m not
sure if it was, I think because there were some agile books on the tables
on the desks that I picked up one, or I already knew about it. I can’t
remember, but I read the Extreme Programming original book, the first one.
Interviewer: XP distilled? Or was that the second one?
Alan: No I think it was XP explained was the first one. I started
reading it and it made sense, but it didn’t make a shift until, I can’t
remember which part I read, something about maybe continuous integration
after I had read TDD and I pictured trees? Like a cell growing? And I said
“Pkay, I get this guy. This is brilliant, this is organic. ”
Alan: This is going to grow slowly and at the same time, he’s making
sure the thing doesn’t die on the inside.
Alan: This is brilliant, the thing is alive, and if you don’t take
care of it, it will just rot and die.
Alan: I love the organic or more, you know, not human, but animal
view, natural view of the thing. And I just fell in love with it. I said,
“Okay, well this is the way it should be.” Then I remember I got tired of
that job for different reasons, you tell me if I’m making this too long.
Interviewer: No, this is really interesting actually. I quite honestly
see a lot of similarities between the path that you took, and the path that
I took, because I used to do a lot of Smalltalk as well.
Interviewer: And my very first book was also, XP Explained, Extreme
Programming Explained, and so yeah, I can see a lot of similarities between
my own personal path and what you’re saying as well.
Alan: Cool. That always feels good. Then I remember I got tired of
the company, and the development assignments I was getting were boring, I
was doing too much Legacy code, or on the spot correction and environment
fixing and they were developing a brand new system and I wasn’t going to
take part of it. And I received a job offer for something that, apparently
felt like the perfect job. It was RUP processing engineer.
I didn’t know what RUP was. I quickly read about it and I said,
“Well, this is what I want, because I had been thinking for so long, how
developers work and now I will have the chance to help them not actually
developing, but helping them change the way they work.” I said, “Brilliant.
This is what I want to be; I want to be a process engineer in a big company
in the methodology group of a big company.” We were so smart, we knew
perfectly well what they needed. We built majestic methodology.
Interviewer: Yep, yep.
Alan: We said, “Okay, this is the way to work; now we’re going to
evaluate you on this.” I was so convinced for like two or three months.
Then I could see their faces of horror, their despair when I started
pushing them to start using all of the templates. It was not that much
about meetings, it was about templates.
Then I picked up again the extreme programming book, and I said,
“Okay I’m going to start tweaking this, because this is not going to work.”
It was interesting, after I had all of the talks with all of the teams, I
said, “I realize the thing that we’re not getting,” I was starting to get
it at the time, is RUP was incremental and iterative. They were water
falling, like hail.
Interviewer: Yeah, that’s a very common complaint with RUP actually,
that you end up doing waterfall.
Alan: Yeah, it was plain waterfall.
Alan: I was starting to understand iterative and incremental
development. So I read Craig Larman’s book, Iterative and Incremental
Development for Managers, something like that, and I said, “Okay so we need
to transmit to these guys the notion of iterative and incremental
development, that’s the thing, that is what they’re not getting.”
I promoted a series of two hour trainings for the whole IT
department; I had never given training on anything. I liked it, it was all
PowerPoint, and people sitting, you know. I realized I enjoyed trying to
convey this notion, and I enjoyed in which I, I still remember that. Things
started to heat up, when I said after like 20 minutes, that you needed to
have running software after, I think I said, four weeks. Then someone got
up, always in every training, 20 people per training, someone said “That’s
impossible. That doesn’t make sense and that’s going to make our jobs pure
I got a little nervous at that moment but I enjoyed his passion. Then
after a while I got really disappointed with what we were doing, we were
actually in the end, implementing some rational tools. It was boring, and
after a year more or less, I got really tired of it. Then I got back into
school for doing some research work, aspect oriented programming. I had
finished my thesis on that. I had some free time, so I said “Okay I want to
start learning about this, I am pretty passionate about this agile thing,”
so I said, “Let’s start looking for training. I want to really understand
this,” and the training I found, the most clearly defined training that
seemed to have recognition in the industry was the CSM.
I started reading more about scrum, I hadn’t read much about scrum,
it was all XP until that time. I found it interesting, but I didn’t find
much training on XP and it didn’t seem like I could find many references to
it. For like half a year, I said, “Okay I might save some money,” I didn’t
have much money at the time, and I had to fly to US or Europe and pay like
$1200 or Euros. I just couldn’t make it. I remember one day out of
frustration, I wrote an email to the scrum developer list saying that I
wanted to take the course but I didn’t have the money for the trip and the
course, if any trainer could fly over to any place in South America and
charge less than $500 then I could go. I thought there were many like me.
So I encouraged other people as well from Latin America/South America to
join me so that we can gather enough interested people. I got a couple of
emails from I think like three or four trainers, one of them was from
Alan: The first reason why I got really caught by his email was when
he said he wasn’t going to charge anything.
Interviewer: That’s always a good price point.
Alan: Yeah. I mean the others didn’t mention pricing, he said “If you
don’t manage to get any money from this, to get people, I don’t care if I
don’t get paid, please try and pay my air ticket and my hotel and I’m going
to be okay.”
Alan: I remember he told me, I’m not sure if I talked with him about
this again, he might have gotten confused like everybody in the world
between Argentina and Brazil, because he said I owe a lot to South America
because two South American’s have changed the way I see work, Augusto Boal
and Paulo Freire. Paulo Freire wrote about the philosophy of the oppressed,
Augusto Boal wrote the Theater of the Oppressed. I had read about them at
another time. I remember, I entered his website, and at that top it said
“Theater based Agile Training” or something like that, and I was really
into theater, I had taken acting lessons for four or five years. Actually,
I had considered dropping the software world, leaving the software world,
and just focusing on acting.
Interviewer: Oh, interesting, I didn’t realize that.
Alan: I said, “Okay this has to be the guy, I mean it’s great that
he’s not going to charge, but this has to be the guy.”
I started setting up, it was my first business venture, I had always
been an employee, and I had to start selling tickets. It was very low
priced, I think it was like $300, or $250. I managed to get a place for
free, I was sending emails and spamming everybody. Actually we filled the
course, and I took it finally. I started to understand things, and as soon
as we finished the course, I started telling Tobias, “You should change
this, you should change that, you should change this, I would change this
part of the course, that part of the course.”
Interviewer: Why were you saying that, what was driving you to make
Alan: I remember a lot about PowerPoint, believe it or not he was
using PowerPoints at the time. And I said, “Tobias, I think have too many
bullets here, I think the concept is not clear here. I think people were
bored at this part. I think when you give us the mission statement for this
game, it’s not very clear and I saw people getting confused by it. It was
great at this part blah blah blah,” stuff like that.
I got really engaged into the dynamics of how the course was
delivered. That was a surprise for me, because I had never been in that
area before. He stayed here for like a week, we quickly became friends, and
it was a lot of chemistry. He actually invited, he put a poster on the
scrum exchange on the wall of the CSM. The scrum exchange was going to be I
think two months after the CSM course. I told him, “Tobias, no one is going
to fly to the US for a conference on Scrum from here; it’s too expensive,
there’s no way.” He said, “Well you should come.”
I said, “I’m not going to fly to the US. It’s in two months, it’s
He said, “Well you can stay at home you’re, not going to pay the
entrance, it’s just the ticket.” So I did some math, and more or less, the
same money I actually managed to make from the course, I thought I was
going to lose money but, the exact money, I made I used to buy the ticket.
That was a month or two afterwards. I remember the trip to the Scrum
exchange, I was amazed by all these people with all these ideas, all of the
games, and I was so much into games. It was games, but connected to
I remember from the Scrum exchange; names I remember a lot, I
remember being quite touched by Matt Smith, David [inaudible 0:23:10],
Michael Spade, I think Luke Hoffman did some stuff I wasn’t that shocked by
it, Kurt Pierson.
Interviewer: Yep. Boy, that’s a lot of names.
Alan: Yeah, well actually Kurt was the one that was going to come in
the first place, before Tobias. He was the first one that wrote me. I know
so many things, stuff that I had never heard about. Like learning from
errors, and I remember I started proposing changes in games. It was
natural, the whole thing was natural, when I came back from Argentina, I
said, “I’ve got to do this for a living. I just have to.”
It was a big coincidence, because of this aspect oriented thing, and
the thesis thing that I told you about before. With my thesis partner, we
had won a prize from Microsoft. It was for Microsoft research. I had flown
in the beginning of that year Redmond, presented the thesis. I had met a
guy from Costa Rica who was the owner of the company that was a partner of
Microsoft. The presentation that we did was for Microsoft research team,
and some partners that were interested. It was all compiler stuff. We
stayed in contact and then, just right after the Scrum exchange, the guy
writes to me, and asks me if I was interested in a job in Costa Rica.
I said “Okay, I think I had broken up with my girlfriend at the time,
so I was ready for an extreme change.”
It just appeared just in front of me and I talked with him, and it
was very interesting, because he wasn’t sure what my role was going to be.
It was a services company, it’s a company that does automated migration.
They have a very sophisticated engine for pattern detection and mapping. So
they had been very successfully performing services to companies migrating,
so they did semi automated migration.
Interviewer: So what are you talking about? Data migration? Or are you
Alan: No, no, no. It was source code.
Interviewer: Oh, okay.
Alan: Source code. They did a lot of work from visual basic, to
Visual BASIC .net, from Cobalt to Java; they got all sort of different
paths of migration. They had a very sophisticated engine that takes
patterns and transforms them, but the guy had always wanted to do some
consumer products with that technology. They put up an internal startup
inside this company, they wanted me to take part in that effort, and they
thought of me as a technical guy, so more the architectural aspect rated
part. I flew, I think it was a month later, to Costa Rica, and they didn’t
know what work to give me, and they didn’t know what the project was going
to be about. I said I’m going to use Scrum here.
Interviewer: Good on you.
Alan: These guys don’t know what scrum is yet. We’re going to use it
like hell. I’m going to be the scrum buster; I’m going to have a lot of fun
here. I did, I was a very… I shaped the way we did product development,
and actually coding, and all the team dynamics. There were so many things
that I was trying, using experimental lists. I had a great time as the
scrum buster, I formed the PO. I think we did a great job, but we did a
lousy job, I found later, at, today you would say customer development.
Wheel to product I think they spent $2 million, and we sold seven copies.
Interviewer: So you built a product that no one really wanted?
Alan: Yes. We did focus groups, we did paper prototyping, but we
failed. But, I think we did a lot of things really great. I learned a lot
Interviewer: So, looking back at it…?
Interviewer: What would you do different?
Alan: Yeah, I had thought about that. I would have been more
insistent, I was, but I should have been way more insistent with the
product owner to hit the market after three months, instead of two years.
His main fear, actually it was my fear with my own ideas, then I later
realized was nonsense, was that they might steal the idea, or we might
create a bad impression on the market with lousy software.
So, the main lesson is the market is way more unpredictable than we
want to think. I think that’s the main difference. Internally it was the
lesson of focusing on delivery instead of discovery, focusing on building
the thing right instead of the… We underestimated the difficulty of
finding product market fit.
Alan: Luckily it was not my money, because it was a lot of money.
Interviewer: Yeah, absolutely, yeah that is a lot of money. That is a
very expensive mistake to make.
Alan: Yeah. That’s the way I entered the scrum world. Then the Scrum
Alliance Training World was when I got back to Argentina, because I was
really missing my country after a year and a half. We had had a very hard
time inside that team, inside that company in finding good testing people;
apparently in Costa Rica they were very sparse. They were slower than what
I thought was healthy in incorporating XP practices.
I told them that if they wanted, we could experiment. If they wanted
me inside a team, I volunteered to become part of the team as a
testing/continuous integration oriented person, team member. I remember I
told them that we could experiment with rotating scrum buster. I’m not sure
it was the best idea, but it was interesting for me to be inside the team.
Maybe I took it as an experiment as well. I wanted to feel what it was like
to be inside the scrum team. I thought “I can’t change these guys, I can’t
change the way that they develop if I’m not one of them.”
Interviewer: Yeah. Absolutely.
Alan: I think I did a good job at that, but the PO needed better
coaching, maybe it was not overall the best decision.
Interviewer: It’s hard to know that at the time though, especially as
you’re starting out. It’s very difficult to know, especially from the
business point of view, because a lot of scrum busters are very technical.
They tend to focus on the technical aspects rather than focusing on the big
Alan: That’s the kind of PO’s we’ve grown so far the more delivery
project manager like PO’s who are obsessed about the plan and not the
Interviewer: That’s a hard one there. That’s a very difficult problem
Alan: You tell me when to stop with the entrance to the scrum world.
Then I came back to Argentina, and I said I want to live in Argentina, and
I want to do Scrum.
Alan: I don’t know what is it I’m going to do, but I’m going to start
coaching. Luckily, shortly after that, after the training, I was doing some
remote work, remote marketing work for the Costa Rican guys. The guy that I
had known in the CSM course that had taken the course with me, and had
actually been my project manager in the most waterfallish project that I
had ever done, that we both suffered the whole year for nothing. The user
saw it after one year and said, “Worthless.”
It was so hard. The guy said, “I’m currently coaching some people on
scrum, they want training and I think you can give a way better training
than I can.”
So I said, “Okay let’s make it.” Internally I said, “Why the hell is
he saying that? He’s done so many trainings and I’ve never trained.”
Interviewer: That was a very brave step though, that must have taken a
lot of courage to do that.
Alan: Yeah, I mean I just said yes, and I was really confident. I said,
“Okay, what I’m going to do is rerun the course.” I took, Tobias’ course,
well, actually he hadn’t seen me, but I had been Tobias’ assistant, three,
four, a couple of times after I had taken the course. I had traveled for
three months in Europe before that, and I remember I flew to co-teach a
part at a course that was being give by Boros Glover and Jake Sutherland. I
had done some co-trainings and stuff.
Interviewer: You’d seen some of the different styles that the scrum
Alan: Yeah I had seen Stacia as well in Costa Rica, Stacia Broderick.
I said, “Okay off we go, two days, let’s go.” I prepared my PowerPoint, I
took Tobias’ PowerPoint, and I changed many things. I don’t know, I just
Its not that I didn’t care, I said “To hell, this is going to be a
good course!” And it was, I think it was a very good course. I realized I
could do that successfully. Worst thing about my first course, was getting
into arguments with people.
Interviewer: Yeah. I remember those days too, yeah.
Alan: I got really angry, really angry. That made me suffer, and made
the other people uncomfortable. I walked a long path since then. I’m not
getting angry any longer.
Then these guys wanted another course, and another course. Then I
found another course, and we wanted the guys we had taken the CSM with,
maybe some others together with this guy Juan, Juan Gabardini, the guy who
invited me to this course. He said we need to have a conference here. I
said, “Yeah let’s do it.”
He said, “People know you more here, than they know me, so why don’t
you write an email?” Because I had created a user group.
Interviewer: Right, okay.
Alan: Before the CSM course, I wanted it to be the user group for
Agile in Latin America. We had maybe like 800 users at the time, not very
active. It was mostly from people who had taken the CSM, in Costa Rica and
Argentina. I remember I wrote an email saying, “We need to make this more
physical, more real, more touchable; so why don’t we make a conference?”
A couple of us got together and we started. I came up with a name, I
think it’s a cool name, and we still use it. In Spanish it’s Agiles, it’s
hard because in English you don’t change the adjectives you don’t put them
into plural, but it could mean like “Agile people” or if you say “We are
agile.” It could mean many things. I love words that could mean many
things. So, when you read it, it’s not agility in itself its agile people,
it’s a word agile, with telling that you are many and that we are people.
That was the goal. We organized the first Agiles, I wasn’t that present
during the organization as much as I wanted to, I was a volunteer. When we
started gathering a lot of people, we had like 400 – 500 people here in
Buenos Aries that year. I think that kicked off the whole thing, we’re
going to have the 5th one this year in Peru.
Interviewer: So, if you’re having the 5th one this year, that was 2008?
That you had that first conference?
Alan: Yes. We brought over Tobias.
Interviewer: Were you a scrum trainer then, or were you?
Alan: Oh no, that’s right, I was not. I remember I wanted to go to
the Agile conference. It was too expensive, so I think I submitted… it
was hard to find, but you could be a volunteer. It was hard to find the
button where you could be a volunteer, but I told them my story, and they
accepted me. I flew to Toronto. I loved it, it was way off course from the
scrum exchange, but I loved it.
Interviewer: Very big?
Alan: Yeah, very big.
Interviewer: Lots of people, lots of crowds.
Alan: Yeah, but I learned a lot and I enjoyed being a volunteer. I
became close friends with Alexi Krovitzky, the Ukrainian CST.
Alan: The guy who did the Lego City game, we were both volunteers and
we shared a bedroom.
Interviewer: Oh neat.
Alan: We posted signs in places, we did basic stuff, and I met a lot
of people there. I remember an Agile, Agiles; our conference was going to
be I think three months after the Agile Conference 2008.
Interviewer: Right, okay.
Alan: So we wanted, I had the idea that we could run some courses,
international courses, with the guest speakers, before the conference so
that with the earnings we could fun the conference. I prefer that over
So I knew that if we did the CSM with Tobias, we could get some
money. Then some guys from another companies were in touch, were in contact
with some contacts with the pop index were going to come. We prepared a
lean development course. Some people were asking for CSM in Spanish, I
think Tobias’ CSM was sold out. Some of the people who were preparing the
course, the conference with me, told me “Why don’t you become a trainer
yourself?” Tobias told me.
I said, “Well I’m not ready; I don’t have that much experience so I
don’t think that I can do it.”
Toby said, “You should do it.”
Interviewer: Absolutely, yeah.
Alan: He said “Do it, do it by all means.” I remember he said “We need a
guy like you in the trainer community, so come, you’re going to make it.”
So I said “No, this guy is just nuts. I want to be a trainer, but
it’s going to be in 1 or 2, or 3 years time.” I submitted my proposal, my
form, and I remember I got an email right before Toronto, right before the
Agile Conference, from Jim Candiff.
Interviewer: The managing director of the scrum alliance at the time.
Alan: Yes. The MD, he said, you’re almost in, but we need to have a
talk. He said can we have a talk, sometime, somewhere in the world? I said
I’m going to Toronto, he said I’m going to. So we met there. There was one
CST who had objected to my saying that I… well I’m not going to get much
into it, but we had a long talk with Jim. He said “Okay that’s all I needed
to hear, I’m going back to the board,” or whoever was choosing CST’s at the
time, “I’ll get back to you in a couple of days.” He sent me an email that
said you’re now officially a trainer.
Alan: I remember I had at the time, they had sent me an email from
Costa Rica, asking me to go back if I could for a couple of months, because
they needed [inaudible 0:45:10] the shift in the way they were doing
things. I remember I flew there after Canada, after the Agile Conference,
and I think I received the email telling me I was a trainer the first day
that I got there. I bought a bottle of wine.
Interviewer: To celebrate.
Alan: Yeah, and I poured a glass for each of the team members and the PO,
and I said “This is all thanks to you, obviously I quit, but thanks so
much. I love you guys, and I learned, most of the scrum I have learned with
I mean I flew there for, supposedly for ten days, but they said “Okay
if you’re going to leave, then we need you for sometime this year,” so I
stayed there for two months or three months, I can’t remember. I changed my
air ticket, and I became a trainer but I did my first training like four
months later, at the opening, I mean days before the conference. I had a
great time ever since, the course, of course, changed so many times.
Interviewer: As it does.
Alan: Absolutely different from what it was at the time. I think I
ran another session with Tobias, at the Agiles conference, but I was mostly
interested in, I don’t know, the timing of the sessions, and if people
would leave the room at the right time, and if the food was there. I
remember I had been to one open… no I hadn’t been to any open space. I
had been to what they used to call the open jem, at the agile conference,
supposedly like open space, so I liked the concept and brought it over to
No one went there, then I started reading about open space, and I
understood that we had horribly failed, because at the open space and the
open jam was parallel to the conference and that doesn’t make any sense. I
fell absolutely in love with open space later, and became a… I wouldn’t
say that I’m a scrum or agile zealot, but I think I’m an open space zealot.
Alan: Yeah, you can solve anything with open space, I mean I’m over
stating it but, I think it’s amazingly powerful.
Interviewer: I’m exactly opposite. On this particular point, I’ve had
some bad experiences, with open spaces early on, so I have no time for open
space. I really don’t enjoy them, I go to them, I try and participate, I
try and be a constructive member of the community. But inside I die a
little bit for every open space that I go to.
Alan: Oh, whoa, what a shame.
Interviewer: And maybe that’s because I haven’t been to a good one, but
honestly, I do die inside.
The post Listen to how Alan Cyment went from being an employee to Argentina’s first Scrum Trainer (CST) appeared first on Scrumology.com.
Corinna is an experienced facilitator of Scrum and Kanban teams. This month, Corinna began a self-financed 6 month sabbatical to create lots off stuff, such as this book on retrospectives. She already has the very cool Retro-Mat website that gives you instant retrospective agenda ideas in 269,573 possible combinations (so far). Corinna blogs at Finding-Marbles. Here she is:One-on-Ones in Agile (Transitions)
Have you ever had regular One-on-Ones (“O3s”)? If not, I think you’re missing out. Mark Horstman and Mike Auzenne describe them as:
- 30 minute conversation every (other) week
- Between a manager and one of her team members. (Each team member gets their own O3 each week.)
- Default time division: 10 minutes team members topics, 10 minutes managers topics, 10 minutes for coaching or mentoring
Now that I finally experienced O3s, I agree with Mark and Mike that they are the “single most effective management tool.”
Here’s what I think is awesome about O3s for the team member:
- It’s a very close feedback loop – You always know whether what you’re doing contributes to the company’s overarching goal
- Which for me goes hand in hand with “Having Purpose”
- Validation – You are important enough for your boss to take time to listen to you
- Guaranteed sync point – You don’t have to disturb your boss because you know there’s a time to tackle all non-urgent issues in the O3
As the manager you can:
- Influence – Give feedback
- Build trust – O3s give you enough time to truly connect to your counterpart
- Coach and grow your team members
I love O3s in both roles, manager and team member. I think they are a great way to influence people. One example where you need all the influence you can get is during an agile transition. But I hardly ever hear about O3s within the context of agile transitions… Curious!
Over the last months I’ve developed a theory about why O3s are uncommon in Agile. Probably several factors come together:
- Traditional management models emphasize the individual: Tasks for individuals, individual performance reviews, individual bonuses and so on. Agile emphasizes teams and collaboration. It also emphasizes feedback loops, but it’s usually feedback for the whole team as they are “in it together”.
- One of the underlying beliefs of the agile community is that the environment determines 95% of an individual’s performance and only 5% are actually up to the employee. I wonder if the agile movement is currently overcompensating for management models past. I once subscribed to the “It’s the system, stupid”-tenet, but lately I’m not so sure. Yes, the system plays a huge role, but I’ve also seen poor performance independent of environment.
- There’s a faction in the agile community that is highly skeptical of hierarchies and managers. They seem to think that management is inherently bad. I disagree with that faction. A good manager a) connects their team members to the company and b) looks out for their well-being and growth. See also Google’s take on middle managers’ contribution.
I’m convinced additional O3s would be super-helpful, at least when starting with Scrum and probably other methods, too. Think about it: An agile or lean transition means a lot of new concepts that often fly in the face of people’s old concepts. I think it’s a lot easier to address concerns individually in O3s. Plus you avoid groupthink.
Pierluigi Pugliese’s experience when building teams seems to support this. He writes:
… so I started to apply more and more one-to-one coaching techniques as they are targeting directly a change in an individual instead of “averaging” the intervention through a group process.
To my surprise the teams started to grow an effective teamwork quicker than I’ve seen in the past. So I tried even more with other teams… and it kept becoming faster!
He ascribes this to:
… in a one-to-one setting there is a much bigger “arsenal” of tools that can be used, tools that enable change at a much deeper level than what is achievable in a group setting, especially when somebody in the group does not want/like/accept to work.
Although I’ve never done regular O3s as a Scrum Master, I came in really early / stayed real late to catch people alone, when I wanted to change team dynamics. This sometimes helped where preceding retrospectives hadn’t.
What do you think? Have you ever done One-On-Ones during a transition or even afterwards? In which role for which other role? Do you think it might conflict with self-organization?
This blog post originally appeared as “One-on-Ones in Agile (Transitions)” in April 2013. Thanks, Corinna, for contributing it. And, good luck on the retrospectives book!