Letting them build it

February 27, 2019

Agile methods like scrum and XP are very exciting, especially when you are first introduced to them. There is something very common sense about the ideas in them that seems to resonate for a lot of people. I know it was that way for me. I’d looked at a lot of different project management methods before settling on XP (thank you Steve McConnell). A lot of those methods looked interesting, but XP was the first one that just made sense. For a young project manager looking for a new way to do things, it was an easy choice. 

Now when you look closely at a method like XP you learn very quickly that it is actually a collection of practices, many of which have been around for a very long time. The thing that makes XP work, is the way that this particular set of practices or, as I like to think of it, this big agile bag full of cats works together. For instance, iterations by themselves have been around for a very long time under a different name: time boxes. Pair programming on the other hand, was a relatively new innovation as far as I know (although not entirely unheard of). And while continuous integration had actually been around in some form or another for a while, it was certainly best articulated and demonstrated by the proponents of XP. On their own I would argue that each of these ideas had plenty of merit, but the real magic happens when you combine them together. Each of these practices, and in XP there were roughly 13 of them, complements and overlaps one or more other practices in the set. So as a whole, you have a system of related ideas that have some redundancy and interconnection. You can see this in Ron Jeffries’ diagram of XP.

Now this gives you a package offering of interrelated ideas that many, including all XP practitioners I’ve ever met, say you need to adopt as a whole. You can’t just pick and choose the bits you like and expect to get great results. Why not? Well, I would go back to the redundancy and interrelated ideas. Let’s suppose for just a minute that you adopted all 13 XP practices, but you found that continuous integration for one reason or another was “too hard” or “not a good cultural fit” or for some other reason wasn’t going to work for your team. What might happen? Well, in all likelihood, in the short term you might not see any immediate effect. In fact, you might find that the team goes a little faster because they aren’t struggling to build continuous integration into their process. But hang on, we’re not done yet. You see there are practices that depend on continuous integration in order to work. For example, test driven development (TDD) and continuous refactoring. TDD relies on CI to give the developers quick feedback on their tests. That can’t happen without CI. So, developers are going to lose feedback on their tests, which means they aren’t going to get as much value from doing the tests in advance…and therefore they aren’t likely to keep doing TDD. Quality may start to suffer. And if they don’t have CI and TDD, then they don’t have the safety net of tests that they need to do continuous refactoring…so they are going to be less likely to try refactoring because it feels too risky.  By removing CI we have undermined quality and the resilience of the system we are developing (because we’re no longer refactoring). 

The impact of removing practices, especially in a pre-packaged set of methods has some rather insidious consequences. Things don’t immediately fall apart. Instead there is a gradual erosion of benefits that causes a cascade of related and also seemingly unrelated problems. You may still be getting some benefit from the remaining XP practices, but the system is now much more fragile and less resilient. You have removed some of the reinforcing mechanisms from the method that helped insure it is robust. When the team encounters a crisis, some sort of emergency in production where they need rapid turnaround and depend on high feedback, they aren’t prepared. They are slow to respond, introduce more defects and likely to struggle. At which point someone is liable to point out that this process sucks. Congratulations! Of course it does, you made it suck.

This is the reason that adherents of pre-packaged methods tend to sound so religious about the unequivocal adoption of all their practices. You have to adopt all the practices, otherwise you aren’t doing XP, Scrum, Kanban, and so on. I want to pause for a moment, because I don’t think that’s the end of the story. 

If we were to stop for a moment and look at development and management practices (agile and otherwise) we might find that there are practices that tend to have similarities that might cause us to group them together. Testing and QA practices like TDD, BDD, and others do share many similarities. Estimation practices like story points, ideal developer days, and others also share similarities. My point is that for any given meme or idea that we have in XP or in agile in general, there are multiple supporting practices that may fit. In addition, some practices are sophisticated enough that adoption can be measured by degree rather than in absolutes (we are 30% toward CI rather than all or nothing). My point is that there are multiple options for many of the key elements of popular frameworks. And even within many of those options there is a matter of the degree of adoption. After all, as so many agile advocates often say, it’s a journey, not a destination. Therefore, if I’m 30% of the way along the path, that must be worth something.

All of this is to say that we can substitute our own practices with some judicious caution. We’re allowed to do that, despite what the more religious might say. In fact, we can mix and match to find the elements that work for us. Now this is really hanging our toes out on the radical edge. Ivar Jacobson has something he calls essential methods. Basically, it is a catalog of development methods that you can combine and recombine to build your own framework. Now, you can still screw up. Remember that the reason that frameworks like XP and scrum have been successful is that they have concepts that are interlocking and support each other. The DIY approach is much riskier (practices may or may not support each other), but for some groups that may be the best way to go.

The important thing is to understand why these frameworks work as well as they do. They are composed of a series of practices that support each other, making them robust in the face of a world full of disruption and challenges. You mess with them at your own risk. Or…you build your own. Just know that you need to understand what you are building. If you do it poorly, it very likely won’t work.


Time Machine

February 26, 2019

OK, Mr. Peabody, where are we going today?

Well Sherman, Any time I explain what Scrum or XP is, I start with time boxes. The time box method has been around a really long time. The earliest record I can find in a casual search is where they were used at DuPont in the 1980s. I suspect that time boxes are much older than that. The time box basically applies a constraint to the system. It creates an arbitrary start and end date, usually on the smaller side. You commit to a fixed amount of work and when the end of the time box is reached you are done, no matter what the completion state of the work. Work that is complete is counted as done within the time box, work that still remains to be finished is either scope that gets dropped or perhaps that work is continued in the next time box.

This technique has some benefits:

  1. Deadlines, even arbitrary 2 week time boxes, help keep everyone focused.
  2. Deadlines force the question of prioritization. Not everything will fit in the box.
  3. Small time boxes create a short heartbeat or pulse that is useful for measures of capacity and throughput.
  4. It forms a useful skeleton for the OODA improvement cycle

There are also some challenges:

  1. Small time boxes demand that you figure out how to break work down into smaller, but still valuable pieces. Many teams find this hard to do.
  2. Small time boxes means that it is almost inevitable that scope won’t be delivered sooner or later. How the business manages this scenario says a lot about how the benefits of time boxes are perceived.
  3. Much of the angst of estimation is due primarily to the fact that teams are struggling to fit work to their limited capacity in ways they didn’t have to prior to the time box.
  4. It doesn’t work if you can’t break the iron triangle of scope, schedule, and quality. Scope usually has to be compromised in some form or another in order for time boxes to work (it’s kind of what they are based on)

Like so many other things, a time box is useful in the right context, but not all contexts. I’ve seen a few projects where a time box would not work (hardware constraints, legacy mainframe applications, an organization that wasn’t willing to give up the iron triangle, etc.). All too often we force the time box on the team and tell them that they suck if they can’t overcome the challenges. Sometimes that’s true, other times it isn’t. It’s a judgement call. Beware, and don’t let yourself get caught forcing a round peg into a square hole (I’m looking at you Scrum).


Team Genetics

September 28, 2014

dna-163710_640

Today I was listing to “The Splendid Table”, a great cooking show on NPR. They were talking about variation in growing heirloom tomatoes. Somehow, that got me thinking about agile teams (probably time to see the therapist again). It occurred to me that ideas like Agile are memes.

Richard Dawkins defined a meme as “an idea, behavior, or style that spreads from person to person within a culture.” and Agile certainly fits that definition. Agile has spread from obscurity to worldwide acceptance within 20 years. In another 20 years I fully expect that waterfall, plan driven methods will be nothing but a footnote in the history books. Despite some early prognostications to the contrary, Agile has grown at a very healthy rate over the last several years.

“Richard Dawkins invented the term ‘memes’ to stand for items that are reproduced by imitation rather than reproduced genetically.”

While much of the credit belongs to the teams that actually do the hard work of making a new process work, there is also the business that has arisen around evangelizing and introducing Agile to companies that deserves a great deal of the credit. Agile training and consulting has done a remarkable job of spreading the meme throughout the software development world.

I think there are characteristics of Agile training that have made Agile “sticky” as a meme. Much of the Scrum certification is based on plenty of hands-on exercises. Training and certification has yielded a decent business. I’m not sure if anyone has the numbers, but I’d be surprised if it wasn’t a multi-million dollar enterprise worldwide. Strangely enough, much of that spreading has been through imitation. There is no shared agenda for the training, much of it is simply imitated from trainer to trainer.

When trainers and others spread the meme they are like Johnny Appleseed sowing Agile ideas across fertile corporate soil.

Genes change with each generation, and so do ideas. They go through a mixing and blending each time they are shared. Parts of the idea are forgotten, other new ideas are grafted on. Soon the original idea is unrecognizable. I think that’s kind of what has happened with XP. Extreme Programming originally contained a collection of ideas that were very potent. Things like pair programming, continuous integration and others all served as core ideas within XP. Over time, those ideas have been co-opted and found their main expression in Scrum. Today, almost no one trains teams in XP, Scrum is the dominant process that is trained and introduced to teams.

“Memes do this through the processes of variation, mutation, competition, and inheritance, each of which influence a meme’s reproductive success.”

So too does Agile. In recent years methods like Kanban and ideas like No Estimates have arisen and are becoming a meaningful part of the software development landscape. These are evolutions of the Agile meme. Agile is evolving, I wonder where it will go next…


The Agile Experience and The 5 Rules of Accelerated Learning

October 4, 2013

Five_rings

How do you experience Agile?

I’m not talking about the process, the rituals, or the artifacts. I’m certainly not asking you to regurgitate any of the usual Agile jargon. I’m talking about how it makes you feel. It usually starts with a question like, “Are you using Agile?” and I catch myself saying things like, “Yes, we do scrum.” Answers like that probably miss the point on a very fundamental level. What I think some people are really asking is, “What does it feel like to work at your company.” What is the experience like?

All too often, that’s as far as the conversation goes. I find myself frustrated by that. You see, I want people who come to work with me to have an experience that is different from the traditional corporate environment. I want them to feel differently. I want them to interact differently. You see, I think a different experience was behind much of the promise of agile methods. Agile provides this groovy toolbox of collaborative methods in order to help change the way working together feels. It promises to change the experience of work.

Just using Agile methods won’t necessarily generate a different experience. You can just go through the motions and not change the feeling of the experience at all. A planning meeting where everyone is seated at a conference table falling asleep in front of some task board on a projector feels a whole lot different from a planning meeting with everyone standing up talking and trading sticky notes back and forth. Its a visceral difference in the experience. You can call them both agile planning meetings, but one feels very different from the other. I see this all the time in daily stand up meetings. Poorly handled stand up meetings usually have all the life and energy of a funeral.

How do we change that experience?

That’s where Willem and Diana Larsen have some interesting ideas. They are working on a book enigmatically entitled, Name This Book that among other things introduces the Five Rules of Accelerated Learning. These rules offer a foundation for techniques that we can use with our teams to enrich the kind learning they have to do every day. These are ideas for improving the learning experience along 5 different dimensions: Alive, Fluency, Signal, Focus, Setting. Each of these dimensions interacts to contribute to the power and effectiveness of the learning experience.

Willem puts it best “I always recommend thinking of the Five Rules as two Values (Alive and Fluency) and three Principles /Tools (Signal, Focus, Setting), and listing them in a consistent order for that purpose (Alive, Fluency, Signal, Focus, Setting). This also makes them easier to recall for new folks”

They also have a smaller 99 cent book that just gives a summary of the Five Rules that you can find here: https://leanpub.com/fiverules. If you are just looking for a quick intro, this is where you could start.

In brief, here are the rules:

Alive

This is about the feeling of energy in an experience. As Willem and Diana put it, this is that feeling of having a peak experience. That moment of total engagement or achieving flow. There is an element of playfulness to it. We want to maximize this feeling in order to enhance  learning.

Fluency

This is the assessment of our skill at actually doing something. In order to provide the right learning experience, we need to assess the fluency of the learners, and perhaps more importantly, create simulations that challenge and allow them to exercise or experience that skill.

Signal

Changing the signal is about amplifying the message so that the learner is most likely to receive it. This can involve reducing distractions, increasing repetition, upping the emotion – using every tool at your disposal to get their attention.

Focus

Keeping learning going requires steadily adjusting the focus so that you accomodate the varying attention levels of your audience. This involves changing the pace, breaking things up and adjusting based on the overall energy level (see aliveness).

Setting

Altering the setting is creating the environment that promotes learning. It’s all about an environment that enhances or amplifies the learning that takes place.

Putting the 5 Rules to Use

First, if you are interested in this sort of stuff,  you should check out their book. They do a fabulous job of laying out all of the rules and putting them in context. Second, if you have a chance, you should definitely catch a presentation on the topic by either Willem or Diana. They are two very engaging speakers and I’ve heard them speak on this subject – it’s worth it. Finally, even if you don’t do any of the above, it’s interesting to note that Willem has put all of this theory into action with Language Hunters – a learning group dedicated to using these techniques to help with teaching and learning rare languages. Check them out.

So obviously, I’m a big fan of their work. The question is: how can you and I apply it? Here are a few places I’ve tried:

Teaching (training, workshops, presentations)

So, I had an experience not very long ago where I saw these ideas in action. It just happened that I was delivering a very interactive workshop at XP2013. I asked everyone in the room to help me generate what I like to think of as an idea cloud at the beginning of the workshop. The experience was like this: as soon as you entered the room, I was there saying hello and inviting you to help me add ideas on note cards to a wall. My goal was to convey a feeling of “Come play with me!” Soon we had a large crowd of people all standing in front of a wall adding ideas. I was jumping in and out of the group, collecting ideas, offering new ones, handing out note cards and generally dancing like a madman (it all felt a bit maniacal). I had music playing, people were talking and the room got pretty noisy pretty quickly. They were competing for space at the wall, helping me facilitate, and generally helping to contribute to a wonderful atmosphere of barely controlled chaos. Folks seemed to be pretty deeply engaged. They were showing me ideas I had never seen before, and I even managed to toss a few originals into the mix. We were teaching each other.

I remember turning around at a key moment to talk to the group. I had my back to the wall and I was surrounded by about 40 people all standing about two feet away and looking right at me. Staring into this sea of expectant faces, I had a moment of panic (it was a little intimidating). I put up my hands and almost reflexively said, “OK everybody, let’s sit down.”

Immediately I realized I’d just made a huge mistake.

matador

All at once I could feel the energy drain out of the crowd. There was almost a palpable sense of disappointment as people searched for a chair. I could almost feel the energy in the room go “Poof!” and disappear. It took me another 10 minutes to get everyone back up on their feet and fully engaged again. The rest of the workshop went great, but that moment where everyone sat down made a huge impression on me. I realized that I had created a critical element of aliveness and engagement that felt almost magical (people told me afterward that they thought it was one of the most energizing workshops they had attended). I think I had managed, for a brief time, to create that alive learning experience in a group of people. Referring back to the 5 Rules, perhaps I had a combination of focus, aliveness, and setting (3 of the 5 rules!) working for the group.

Interviewing

I wrote about an experience with interviewing recently in Bob the Naked Agilist. In that interview I introduced a drawing and asked the participants in the interview to help me clothe a hypothetical Agilist with the things that they would need to survive out in the corporate jungle. It swiftly turned into a very engaging and dynamic dialog where we were generating ideas together and asking each other spontaneous questions about the things we thought were important for our work. For me, it felt like the conversation opened up.

Compared to the traditional interview where we all sit around the table in combative postures and quiz each other, this felt like we were collaborating on building something together. The energy was completely different (and honestly, quite refreshing compared to the usual drudgery of an interview). All I did was walk up to a white board and start drawing pictures. Next time, I’m going to get everyone up at that white board drawing too. I want people to experience interviews differently.

Dear God I must be nuts.

Fire Writing

So I managed to use the aliveness, focus and signal rules to improve the interview. Now that I think of it, an interview is a very intense learning experience for everyone. It makes a lot of sense to try to improve them.

Meetings

One of the things that I think we have done particularly well in the Agile community is rethinking the way meetings are run. For instance, I believe that when I’m doing a meeting well, there are rarely any projectors or PPTs. The walls are usually completely covered with sticky notes, diagrams and all in a bewildering array of handwriting. That’s because everyone in the room has been contributing. Chairs are kicked out of the way against the wall. Tables are piled high with collaboration tools: sticky notes, sharpies, and stickers. None of this is particularly new or extraordinary – these are all the attributes of what I have come to expect from any experienced facilitator when they are dealing with an Agile team. It could be a retrospective, or a planning meeting – it really doesn’t matter. Why is this important? Because we have a body of techniques that makes our meetings feel distinctly different from the usual meeting. The experience is manifestly different.

Coaching

Recently I was working with a team and just happened to be observing one of their stand up meetings. As a coach I was watching and waiting to see how the team dynamic would play out. As I stood there quietly, it occurred to me that I could use the 5 rules to help me asses the outward experience of the team as an outsider. I quickly jotted the 5 rules down in my notebook, and then asked myself some questions: Does this meeting feel Alive? Joe over there is bouncing up and down on the balls of his feet over there. There’s a lot of energy pent up there. Either he has to go to the bathroom or he has something he really wants to say. Nobody else is moving. What’s up with that? Are these people alive or in zombie mode?

Then I switched to the next rule: signal. What message is this person trying to send. Is it clear enough that I can understand it as an outsider or is it encoded in jargon. How are others receiving his message? Is he mumbling? Why?

For each rule I discovered a lot of interesting questions that were open for me to ask. After the team finished I pulled them together for a quick huddle and shared the 5 rules model with them. As I did so, I offered a few questions that I felt would offer seed opportunities for further exploration or introspection. With the judicious use of a few funny examples from my own past, I set the hook. What would you change to increase the liveliness of the meeting? How would you change the environment to improve the learning that takes place? What could you do to improve focus?

So the 5 rules served both as a source for assessment as well as a roadmap for improvement.

Where next?

These days I ask myself, does this feel different? Is this the experience I was hoping to create? Sometimes the answer is no. When that happens, I feel like what Willem and Diana have given us in the Five Rules of Accelerated Learning is a set of strategies I can use to create that new experience.


Slowing Down

February 12, 2013

photo

Last week I led a session at Agile Open Northwest called, “Slowing Down”. The idea for this session was inspired by my own struggles with becoming quite over-committed to a variety of things (my job, my hobbies, etc.) and the resulting stress and crisis it has created for me. You see, the funny thing about it all was that even though I was perfectly aware of what I was doing by over-committing like crazy, I couldn’t seem to stop.

The Introduction

So I came to this session, not as an expert selling a solution, but rather as a novice seeking help. Since I really didn’t know where things were going to go, I simply started with the session title. I wrote “Slowing Down” on the whiteboard and introduced myself to the small group of people who had joined me for the session. I started with a story of my own. It was a bit like what I imagine an Alcholics Anonymous conversation starts like, “Hi, my name is Tom and I can’t slow down…”

Fortunately for me, many in the audience had a similar story. Since we are a bunch of software development types, it didn’t take long for the concept of sustainable pace to be mentioned. Of course we all knew full well what sustainable pace means. It is a term that I originally encountered in Xtreme Programming. I could ramble on for hours about the importance of keeping the pace and duration of your work under control so that you can sustain your creative energy and not burn out. Easy. But I can’t seem to do it worth a damn. That’s the interesting bit. Why? Why is it that, even knowing the importance of maintaining a sustainable pace, I and others like me seem to struggle so hard with it?

Why?

A few interesting ideas for why we get sucked into this dynamic were suggested during the session:

its-mine

Ownership – Feelings of ownership can make it hard for people to let go of tasks and delegate them to others. For example, it is very easy for project leaders to feel a very strong sense of ownership and commitment to the success of projects that they are working on. This can be quite normal – often our organization want this kind of commitment from us. However, like many things, this can go too far. The undesired dynamic plays out as a feeling that you and only you are personally responsible for the success or failure of the project (what happened to the team?). When challenged, people who struggle with ownership issues will often look with incomprehension when asked to give up some part of a project, “If I don’t do it, who will?” I think that in some cases this inability to give up ownership can also manifest as heroism (ownership + adrenaline junkie). Perhaps at its heart, ownership issues are tightly tied to ego. They seem to manifest as a very selfish view of project success or failure.

nun-with-habit

Bad Habit

Habit – We form all sorts of bad habits that contribute to the stress in our lives. For example, I’ve gotten into the habit of checking my email compulsively throughout the day. Often even when at home. Habits like this that tether us to the office and constant communication serve to raise our overall stress levels. Other examples include habitually taking home the laptop with you every night and carrying the work phone with you wherever you go.

Culture – One major reason for difficulty with slowing down is the work culture you live in. People shared many different stories of how the expectations at work made it hard or almost impossible for them to escape the pressures of the office. Everything from evil bosses that demand attendance over performance to co-workers who make snide comments when a colleague dares to leave the office at 5:00. Some places even provide rewards for those who make decisions that put work above any other activity. Examples of these sorts of influences in the workplace abound.

All of these influences are very common reasons why people find it hard to slow down. It is no wonder that there are many who struggle to maintain a sustainable pace of work at the office. Understanding why you are feeling that pressure is critical to understanding what strategies to use to manage the problem. The strategies where where we ended up going next.

Strategies

As we moved along in our discussion, people identified strategies that could be used to deal with slowing down and establishing a more sustainable pace. We captured and expanded upon those strategies as we wove the narrative of slowing down.

Setting Boundaries

boundary_full

The first strategy that came up was setting boundaries. Setting boundaries is fundamental to establishing control over your own schedule and pace. Fail to do this and all the rest really doesn’t matter. People told many stories about how they managed to establish meaningful boundaries in their work lives that helped them to keep a meaningful sustainable pace. Some made their 9 to 5 work hours non-negotiable. They never offered the longer hours that many fall into. You get me for 8 hours a day, and the rest of my life is not for sale. It was remarkable to hear the strength of some of these voices. Others refused to take work home or turned off the cell phone after 5.

Basically, what I heard were people establishing a service level agreement for their participation. One benefit that I noticed from this sort of boundary was that it made visible to everyone just what they could and could not expect from you. Visibility is a strongly held value in the agile community and it struck me that making my boundaries more visible would be a uniquely agile way of dealing with the issue (I’m closing the door now…). Another way of making my boundaries and limits visible would be to use a personal task board mechanism like personal kanban in order to not only make my existing commitments visible, but also to review them myself and keep tabs on how the work load is balanced (or not).

Reflections

Diana Larsen did a great session last year at Agile2012 on personal retrospectives. As team facilitators, we are pretty well versed in running team retrospectives, however I never do them by myself. That is exactly what Diana proposed: do self-retrospectives on a periodic basis in order to reflect on your progress toward your goals, and where you want to go next. I think this would be a useful tool for many, whether it is only at the end of the year or much more frequently. I know that my own responsibilities feel like they have changed quite dramatically in the last year. Stopping to assess those changes might just give you the opportunity to recognize stressful trends and start to do something about it. You can start to do it now, or wait until a crisis imposes that reflection. Your call.

This is just my summary of what I saw and heard during our talk. Looking at the sheer number of topics that we covered it’s quite apparent to me that we covered a broad number of subjects. Many of them are worthy of deep investigation. Perhaps, as the mind map suggests, we have created a map of the terrain of the topic of slowing down. Others may have different take aways. I certainly hope so. I appreciated everything that the group brought to the conversation and I hope that I was able to serve as a reasonable scribe for what was said.


XP2011 Day 4

May 13, 2011

Sessions

Silo Busting w/Tom Perry and Lourdes Vidueira

Yeah, that’s me. It was our big session. And just for the record, we rocked the house. In fact, the people attending our session made so much noise that people in sessions in the rooms adjacent to us complained about all the noise. What did I think? I think that means I’m doing a good job as a facilitator. Especially given the fact that there were only 10 people in the session. It was awesome! The feedback we received was nothing short of phenomenal. I’m extremely grateful to those who participated.

I was pretty exhausted after running the session. 4 hours seems like the equivalent of running a 220 yard dash. It’s not a sprint and it’s not a marathon. You have to keep things moving fast and you can’t lose your focus. We went out on the town afterward in Madrid and had a grand celebration. I had seafood that would give Louisiana a run for its money, and the people were just as friendly, if not more so.

The conference has been a good one. I’m probably too tired to do a decent recap of everything that happened today, but I’ll give it a shot tomorrow. Signing off from Madrid.


XP2011 Day 3

May 12, 2011

Conversations

What can I say? The restaurant open bar last night was epic. Actually I wasn’t saying very much at all to anyone this morning…

Sessions

Keynote: What Forms of Work and Life Make Sense for Us? w/Brian Marick

As usual Brian’s keynote was eccentric, enlightening, and above all else, unique. At about the halfway point he actually had the entire room stand up and he gave a tango lesson (which was no surprise, he had been talking about it on twitter for weeks). Still, there were a lot of European men arm-in-arm dancing with each other. Perhaps not so unusual. The talk itself covered some interesting subjects.

First he talked about gift economies vs. money economies. The way I understood it, he described the agile team as using a gift economy. Favors are exchanged freely with no exchange of money. However outside the team and especially within the corporation at large, it is a money economy. I think the point was to suggest that we need to be conscious of the different economies at work and adjust our expectations and behavior accordingly.

He also talked about the influence of context on behavior, basically debunking using assessments like Myers-Briggs for any predictive purpose. Instead, there is plenty of evidence to suggest that context matters much more when it comes to predicting people’s behavior. So, my take away from that is that we need to create the right environments for people to be successful.

Grumpy Old Agile Coaches w/Rachel Davies

This was a fun session with Olav Lewitz, JB Rainsberger, Kati Vikki, Mike Hill all sitting on park benches and Rachel Davies acting as moderator. While the conversation was good, I have to agree with some of the participants, that the grumpy old agile coaches looked pretty happy for a bunch of grumps! I was interested to hear about the lonely-coaches-sodality google group which I definitely want to check out.

Agile at Scale

Apparently this was another fishbowl – I enjoyed it and jumped right in with the big fish. It was fun to bounce some of my thoughts off the group and get their perspective. Mary Poppendieck was a hoot and provided some lively conterpoint and tough questions of her own. Jutta Eckstein was the moderator and did a great job.

After Hours

It’s a quiet evening for me. I have to give my Silo Busting tutorial tomorrow morning, so it’s early to bed.