Tuesday, January 29, 2013
Now, the way it works is, each week the team rotates the role of Blame Well to a new team member. During that week, if *anything* goes wrong that team member immediately assumes *all blame* for anything that goes amiss.
The role of Blame Well enables the team and stakeholders to immediately get past trying to figure out whose fault anything is. Instead, the team can directly move into useful discussion about resolving whatever issue came up.
So…this post is definitely tongue-in-cheek. I think if a team really needed a Blame Well there are deeper problems to address.
What I hope folks could take away from this is that assigning fault and blame is pretty pointless. A better approach is to simply figure out what the next best thing can be done in the current context.
This doesn't mean teams shouldn't inspect and adapt…but true reflection and growth happens without fault and blame.
I'd enjoy hearing stories about how people helped their own teams or organizations get out of the blame game.
Posted by Matt Barcomb at 11:56 AM
Thursday, January 17, 2013
I have a challenge for anyone who would like to participate. This year, all year, when attempting to describe or discuss software development, only use *development* examples and metaphors.
A lot of folks use construction or manufacturing examples to help others understand how the undeniably more fuzzy process of software development works. Others try to use examples from art or drama to try to emphasize the creative aspect of developing software.
These comparisons aren't wrong, but they do fall short. Of course most comparisons fall short of the actual thing at some point. But what is intriguing to me is that humans have been developing things for centuries. We have *plenty* of development examples all around us yet non-development comparisons seem to be the norm.
Now certainly, examples of non-software development will still fall short. In fact, I know they will because most examples of development are of some kind of physical development such as a tangible product. Software is different, but less so in most examples I can think of. Software differs because the economics of its final production is inverted from that of physical products. With physical product development, it is usually more expensive to have to remake the physical thing after it has been initially developed. However with software, if you consider its final production nothing more than compiling or interpreting, its remaking is so cheap its free.
This is not meant to contradict concepts like baking quality it and the obvious increased costs of finding bugs late, or worse finding nobody wants or needs your software after you've built it…but again, with software, those are simply development or design issues, not production of the software.
So what do you think? Can you do it? You up to the challenge? For a full year, when discussing software with anyone, friends, family, colleagues or clients…use other development examples. It should at least make for an interesting mental exercise!
Posted by Matt Barcomb at 3:13 PM
Sunday, November 4, 2012
Within the context of organizational change, we would expect grassroots initiatives to be started by people closer to work. This stands in contrast to top-down initiatives that are started by traditional organizational powers such as "the leadership".
I believe this metaphor, this contrast, creates a false dichotomy between grassroots and top-down initiatives…both things organizational change experience tells us struggle on their own.
However, I think the metaphor of grassroots can be broadened to a more holistic one. Something that is more inclusive of both an organization's individual contributors as well as their formal leadership.
The organic nature of grass is something good to consider. Given it is growing in an appropriate environment, grasses tend to be pretty hardy but also grow out quickly and adapt well.
From an organizational perspective, grassroots efforts allow for more innovation and more responsiveness to changing conditions as well as optimizing for what is currently needed…as long as it has support from the environment.
Environmental support is where we extend the metaphor to "leadership". Grass can only grow so well without rain and sun, both things provided from above.
In the same way, an organization's leadership should allow and encourage grassroots initiatives by providing the support needed for these initiatives to thrive. Leaders should be less focused on growing grass and more focused on creating a healthy environment in which grass can grow well.
Oddly, there are many parallels to gardening and organizational development. Though perhaps this shouldn't be so surprising given both are organic, natural activities.
Posted by Matt Barcomb at 12:27 PM
Friday, November 2, 2012
Think about the moments in your life where you felt that you have learned. Not the events or experiences from which you have learned, but the times where the actual learning occurred. For me, these moments have mostly fallen into one of two broad categories: 1) action and 2) reflection.
The action category focuses on the "what" and the "how" of things. Action is where topical or practical learning takes place. It's well suited for hands-on or skill-based activities or things at which practice is needed in order to improve.
To create action-oriented learning opportunities:
- Approach activities with a learning stance. Sometime the easiest way to create a learning opportunity is to simply pause for a moment to consciously engage from the perspective of a learner.
- Perform new activities. Obviously if you are doing something new you are probably going to learn something.
- Use new tools or methods. Doing the same activity in a new way can provide opportunities to learn more about the activity.
The reflection category focuses on the "why" of things. Reflection allows for deeper learning and eventual mastery of a subject. It gives us the ability to soak in the subtleties and nuance within a subject area as well sense patterns and connections between (sometimes seemingly unrelated) subject areas. Enough reflection eventually allows us to determine principles, establish values and helps us create new mental models.
To create reflection-oriented learning opportunities:
- Create a time and space suitable for analysis and introspection. Reflection can't be rushed or squeezed in. You also have to create a time and space that is compatible with your learning style and personality.
- Get routine exposure to new ideas and experiences. While you can certainly learn by reflecting on your routine activities and experiences adding to these only enhances the process. New hobbies, roles, activities, books, classes…whatever…all add another node in the network to use for reflection.
The last thing to point out is that these two categories, action and reflection, should find some sort of equilibrium that works for you. Certainly, just thinking about how and when you learn can help. However, taking some time to understand how you learn and types of learning may help even more.
Posted by Matt Barcomb at 8:38 PM
Monday, October 8, 2012
But all good things must come to an end…and then on to more good things!
So, starting October 15th, I will be making my foray into independent consulting, operating as the business "odbox". There are a multitude of reasons for this, some of which are even sane ;) …but mostly it's the desire to live a more nomadic life for a while and accelerate my learning and experiences around Business/Software Organizational Development.
I plan on continuing to coach organizations and teams on lean/agile principles and practices as well as round out some training materials. Also, I plan to keep speaking as that has been a great way to share what I've learned from practicing as well as a great way to meet so many new interesting people!
More excitingly, I'm also beginning to plan a professional "walkabout" that will hopefully start mid-summer 2013 and last about a year. My goal is to be able to practice with or shadow folks that I would not otherwise have the opportunity to. Of course I gotta keep whatever lights I may have on, so I will be weaving this in with coaching and training…but, if you've got a spare couch, bed or barn lemme know ;)
Posted by Matt Barcomb at 12:38 AM
Sunday, August 5, 2012
Recently however, someone asked me what *my* passions were and why I do what I do. Since I started Agile coaching, I've always felt my job was a good fit and continues to drive me closer to work/life alignment. But I'd never thought to articulate my thoughts more specifically than that…also, no one had ever asked.
I realized there are 3 things that I'm passionate about (and derive huge amounts of satisfaction from) that I get to achieve while doing the work I do:
1) improve the lives of the individuals I get to work with at the organization
2) improve the experiences of the end users who consume the software the organization produces
3) get the organization to improve a community outside itself and its end users in someway
Of course not every engagement achieves all three, but I always achieve at least one and usually two. In general, I find getting to even one is hugely rewarding.
I'm sure as I think about this more, and both broaden and deepen my experiences this list will change.
Have you thought about what drives you in your work? Can you feed your passion with your job?
I'd love to hear your stories :)
Posted by Matt Barcomb at 10:56 PM
Saturday, March 17, 2012
Unless you can take a single action and reinvent the whole effing universe instantly then EVERYTHING you do is a local optimization!
Here's another thing to chew on…even if we draw the boundaries of the system to just the department level, that is still (in most enterprises) a whole lot of people, interactions and influences. In order to improve a system you should first understand it. Problem is, by the time you understand the system well enough to change it, the system itself has likely changed rendering all your changes useless or non-optimal and much of your time wasted. Of course this issue explodes exponentially for each step towards a bigger system you take.
So, what are we to do? I suggest this fun little metaphor:
Act like a good Proctologist; consider the (w)hole, but treat the individuals ;)
As a change agent, whether an internal employee or an external consultant, you often have to play the cards you're dealt (or fold). You should definitely spend some initial time trying to consider as much as the system as you can. In fact, this should be something you are always doing at some level. More importantly though is to not let this paralyze you. You'll often get more data from attempting a safe-to-fail change than you will from simply sitting back trying to sense the system. Also, don't think too linearly. You can likely be influencing multiple things simultaneously.
In fact, one approach is to intentionally over optimize a local optimization. This will often make apparent to management (or even to you) where the true bottle neck in the system is. We shouldn't worry so much about doing the wrong things righter, but we should be aware that that may be the case and always work to be doing the right things.
In the end, showing improvement and building momentum can lead to exciting changes. In fairness, it can also come crashing to the ground if the right kinds of changes aren't made at some point, but this should not deter anyone who thinks something can be made better from trying to do so and it certainly should not be a reason to do nothing!
Posted by Matt Barcomb at 4:56 PM