It’s almost a cliche in the consulting field that all problems are people problems… sometimes though, I don’t think we really appreciate the depth of truth in that statement. Improving the systems in which we work, introducing some new processes, or bringing in a new approach or methodology or tool requires people to change what they are doing today and requires them to do something different tomorrow.

Change is hard… change is scary… change isn’t safe.

I’m guessing that most of us have read Kotter’s work on leading change… and while I do believe that managing change… or even leading change… is an essential part of bringing new ways of working into any organization… it feels to me that there is something deeper, more personal around change than putting gloves on a table, or posters up around an office.  Resistance to change often runs deep for reasons that are not immediately obvious.

Let me tell you a little story about my wife and I growing up… while we both grew up in stable two-parent homes… our early childhood experiences were very different.

My family moved around a lot when I was a kid. By the time we settled down in Tampa, FL I had lived 4 different states, probably 6 or 7 different cities, and at least 6 different elementary schools. I was forced to get used to new environments and make new friends on a regular basis. While we had the basics, my family lived with a tremendous amount of financial insecurity.

My wife on the other hand grew up in one city her entire life. Her Dad was a mathemetician at Eglin Air Force Base, had one job, and she lived in one house until she went to college . Kimi grew up with a consistent set of friends and had all her family in the same general area. Her family was able to take a family vacation every year and didn’t have any of the financial instability I experienced as a kid.

While both families ended up just fine… my expectations about change very different from my wife’s expectations. My experience is that you do what you have to do, go where you have to go, and take chances and everything works out well. My wife’s experience is that you stay in one place, hold into what works, and don’t assume a bunch of risk and everything turns out well.

I could go on and on about other differences in our experiences growing up… relationships with parents and siblings… being the oldest or the youngest… the caliber of people we both chose to hang out with… our influences and our faith and the decisions we both made… but at this point I’ve already shared too much and don’t want to get into any more trouble than necessary to make my point

Needless to say people are complicated.

My point is this… as individuals, change isn’t really an intellectual process. It’s not really even just an emotional one… where if people could just see, or feel good about another way of doing things… they would get on board with the new approach. On many levels we are dealing with very personal deep seeded stuff… the stuff that anchors us as people and defines who we are in relation to the world.

I don’t know that I have any answers here… but I’ve been very intentional lately trying to understand more about the people I work with, who they are as people, their expectations about life and the world around them, and what makes them feel safe and secure in their experience with work. Sometimes you have direct access to that information, some times you have to infer it… but either way… it’s usually the truth behind the resistance.

Anyway… just something to think about. It’s an idea that’s been noodling around in my head for the past several months and this is my first attempt to put words around it. I’d be interested to hear what you have to share regarding this. I suspect it won’t be the last time this topic comes up.

The Influencers Mantra:

Mantra (n): A word or group of words, an act or a series of acts – all considered capable of creating “transformation”.

(“man” – mind + “tra” – liberation).

My good friend Siraj Sirajuddin is hosting his workshop “The Influencers Mantra” at the VersionOne offices in Alpharetta, GA on June 7, 2012.

While I haven’t had the opportunity to attend this workshop personally, I’ve had the pleasure of getting to know Siraj over the past several years, and find him very wise and full of great advice and practical guidance.  I’m trying  really hard to keep the date open so I can attend myself… I think it will be that valuable.  So… if you happen to be within driving distance of Atlanta and want to learn more about the human side of transformation, I think this will be a really good use of your time.  At $425/$525 it’s also an excellent value for a day of high-end training.

For more information, or to register for the course, check out Siraj’s site at http://blog.siraju.com/

Unless you happen to be connected with me over Facebook… or in my immediate circle of family, friends, or clients… you probably haven’t heard much from me the past year or so. I was thinking back over the past several months and all the lost opportunities to connect that just haven’t seemed to make the cut.

Back in November… I really wanted to sit down and write an appreciations post to all the people that have directly or indirectly helped LeadingAgile get to where we are today. It didn’t happen. The past several years I’ve written an end of year retrospective post, recapping the previous years accomplishments and struggles and any goals for the upcoming year. It didn’t happen. Kimi and I even broke our 15 year tradition of sending out the Cottmeyer Family Christmas newsletter. There just wasn’t time.

So what has been keeping me so busy the past 6 months or so? That is the topic of this post. It’s a bit personal… but that’s often been the case with my posts on LeadingAgile… so I guess there’s really nothing new there

First of all… LeadingAgile has been doing great. We’ve all been about as busy as we want to be, and then some. We’ve got a great client list and have been doing some really fun and rewarding work and it’s kept us pretty busy. Whenever you are doing a small startup kind of business, you have to get it sustainable as quickly as possible. I think we might be there… it’s been fun, but it’s also been very time consuming.

As I mentioned a few posts ago, Dennis and I hired Rick Austin. About that same time Peter Saddington decided to focus on a few other projects he was working on, so while still a friend of LeadingAgile, he is not part of the company anymore. Business has been strong enough that we hired a 1/2 time office manager and are considering bringing on a few other coaches and strengthening several of our existing partnerships.

On the family front… Kimi and I have two kids in high school and one still in elementary. My oldest started driving back in March and is involved in several school and district level leadership groups. My middle son is the Senior Patrol Leader of his scout troop. My youngest is a three sport athlete. All three are straight A students. As you’ve might imagine, we are spending a bunch of time being involved with their lives. You start to realize at this point, they aren’t going to be home much longer, and we are trying to make the most of the time we have left with them.

Personally, I’ve been trying to focus a little more on maintaining balance. For a long time that mean backpacking and hiking… but lately that’s meant running. I started training to run a marathon a few months ago and I’m getting to the point where it’s a serious time commitment. I’m up to about 20 miles for my long runs and overall am running about 35 miles or more a week. I could write a whole post on my experience here… but for now, I’m running about 6-8 hours a week… time I really don’t have, but it’s important so I do it.

We’ve leveraged the success of LeadingAgile to take some nice family vacations… cruised the Caribbean over the holidays, took Noah to Disney over spring break… while the older two we on a mission down in Nicaragua, and are trying to figure out a long weekend we can make it to the beach sometime this summer. How does that saying go… you can sleep when your dead? That may just sum up our lives right now.

Seriously though… my focusing objective in starting LeadingAgile was ‘freedom of time and place’. I want to be able to work with the people I want to work with, on engagements that are fun and life affirming, and have the ability to spend time with the people I want to spend time with… doing the things we want to do. All that is starting to come together in a really positive way. Everyone is running at full capacity, but the rewards both personally and professionally have been great.

So… no big promises to write the book. No big promises to become a better blogger. No promises to stay in touch better or show up at more conferences… but those things are all on my list of things to focus on. I’m seriously toying with the idea of coaching less and building the business more. As soon as I figure out how that might impact my ‘freedom of time and place’… I’ll either move in that direction or not. It seems like that might just be the path to greater balance, but who knows… for me, it’s emergent.

Thanks for reading… happy Mother’s Day. Instead of running or working, the kids and I are taking my wife and her Mom out for a nice lunch up on Lake Lanier this afternoon. Have a great day.

I am really excited to announce that Dennis and I both had talks selected for the Agile2012 program this year. Personally, I’ve slowed down my speaking and writing to focus on the operations of LeadingAgile and growing our client base.  Given my schedule, I almost missed the deadline to submit… even though it was on my radar for months. I’m glad it all worked out in the end, I really wanted to be at this event and speak.

Here are the abstracts, location, and time for the selected talks:

Patterns for Agile Adoption and Transformation – Mike Cottmeyer
Room: Texas D           Time: Wednesday 13:30 – 15:00

Introducing agile into an organization is more than just running people through a few days of training and hoping for the best. Training is part of the equation but only addresses one part of the adoption and transformation cycle. The problem with a training-only approach is that we can learn new ways of working, but if the structure and culture of the organization don’t support those new ways of working, the training won’t stick. The trick is to create an organizational structure and culture that is congruent with training in agile practices. We need a structure and culture where Agile practices can flourish and grow and produce the business outcomes we all hope for.

This talk will start by exploring the main differences between agile adoption and agile transformation and how to distinguish between structural transformation and cultural transformation. Next we’ll explore criteria for how to assess your organization and create an adoption and transformation roadmap to help you pragmatically and safely introduce agile methods to your enterprise. Finally we’ll explore three primary dimensions of adoption and transformation: competency, frequency, and scale that will assist in guiding your adoption and transformation roadmap and change management strategy.

After establishing the theoretical underpinning of a successful adoption and transformation strategy, we’ll consider several case studies where these ideas have been applied and what has worked, and more importantly, what hasn’t. The case studies will consider 3-5 companies of varying sizes where these ideas have been applied in the past 18 months.

Beyond Functional Silos with Communities of Practice – Dennis Stevens (with Brian Bozzuto)
Room: San Antonio 4-6          Time: Wednesday 11:00 – 12:00

Stop me if you’ve heard this one before… An organization aligns its operation around business products with cross-functional teams focused exclusively on each one. The business likes the focus, but soon people start to complain. Functional experts feel isolated and aren’t able to tap into their technical peers now isolated in other teams. Common practices become difficult. Functional managers feel left out now that their people are permanently assigned to dedicated cross-functional teams. Overall, the organization gains benefit from the re-alignment, but people can’t help but feel they are neglecting their institutional knowledge and have reduced their technical capacity to solve problems. You might think we’re talking about an Agile development team, but actually we’re talking about Chrysler in the 1990′s when they re-organized their engineering around auto lines. (Wenger et al, Cultivating Communities of Practice 1)

This session will explore the concept of communities of practice and how they are a vital component for agile organizations. From providing tactical support in issue resolution, to being stewards of knowledge across vast enterprises, and even helping create support for the larger organizational change, communities of practice are a vital component in improving organizational agility. We will walk through the history of communities of practice, from their emergence in fields as disparate as auto manufacturing, consulting, and oil exploration, and show how these concepts apply to agile organizations. Participants will hear several cases about how communities have been used at our actual clients to help support the organizational change, as well as get some tactical steps they can use to implement their own communities of practice at work.

Understanding Agile Program and Portfolio Management – Mike Cottmeyer
Room: Austin 1-3          Time: Thursday 09:00 – 10:30

More than 10 years after the signing of the Agile Manifesto, agile is now officially mainstream. PMI is offering an agile certification and you can’t hardly find an IT job description that doesn’t ask for some sort of Agile experience. As a community, we’ve become pretty good at setting up agile teams and delivering agile projects. The next frontier for agile methods is tackling the enterprise and one of the toughest nuts to crack will the the traditional PMO.

In larger more complex environments, it isn’t sufficient to pair a single product owner with a single team and expect that the work of the business is going to get done. We are dealing with larger, more diverse groups of stakeholders, stakeholders who’s needs often compete for the attention of the team. Furthermore, the teams have to work together in more complex ways that require tighter integration across teams to deliver larger, more complex feature sets.

This talk will explore patterns for dealing with more complex organizations, managing interdependencies between teams, and balancing tradeoffs to optimize the project delivery organization. The key question to answer is ‘when will we be done, and what will we get for our time and money’. We want to give the PMO a way to answer this question without having to resort to traditional plan-driven approaches. This talk will lay out just such an approach.

Agile and the Nature of Decision Making – Dennis Stevens
Room: Texas 3           Time: Monday 13:30 – 17:00

Organizations are really bad at Risk Management. And the typical approaches to risk management are flawed – resulting in bureaucratic overhead and not much improvement in the performance of software development projects. Agile efforts have rejected bureaucratic and non-value adding efforts and in the process have rejected most of what is practiced as risk management. This is unfortunate – because the nature of agile development fundamentally changes how to benefit from effective risk management.
Risk management is about managing uncertainty to reduce the probability and impact of unfortunate events and the maximize the realization of opportunities. This workshop builds on concepts from SEI’s MOSAIC project and Eric Reis Lean Start-up to present a practical and proven to a systemic approach to integrating threat and opportunity identification and response into the management of Agile projects. Useful for typical delivery teams, this approach is particularly valuable in the large projects and large organizations.

The first post in this series provided an overview of the synergy between The Speed of Trust and Agile.  This post focuses on the first wave of trust, Self Trust.

Agile relies on cross-functional teams of individuals.  These individuals bring a set of personalities and skills to a team.  In great teams, these individuals have credibility.  That is, they contribute character and competence that helps make the team more than the sum of its parts.

The Speed of Trust describes “four cores” of credibility, two dealing with character and two dealing with competence:

• Integrity
• Intent
• Capabilities
• Results

Integrity

Congruence, humility, and courage are three qualities of integrity mentioned in the book, but one passage on humility really struck me:

A humble person is more concerned about what is right than about being right, about acting on good ideas than having the ideas, about embracing new truth than defending outdated position, about building the team than exalting self, about recognizing contribution than being recognized for making it.

-Covey, Stephen M.R.; Merrill, Rebecca R. (2006-10-17). The SPEED of Trust (p. 64). Simon & Schuster, Inc.. Kindle Edition.

Humility is all about the success of the team over success as an individual, knowing that by lifting others up instead of climbing over them, is the right thing to do.  There’s also a hint of servant leadership in there.

Intent

Transparency is one of the most appealing aspects of Agile when it is done well.  With everything visible, there is no question about the intent of those involved. However, if someone comes to an Agile team with a nefarious motive, agenda, or behavior, that person and the team pay a huge tax on the speed at which they can deliver value.  In an Agile environment, you can’t fake it and you get punished when you try to.

Capabilities

The Speed of Trust uses the acronym TASKS to discuss capabilities.  Talents, Skills, and Knowledge are expected members of this list — they’re needed no matter what approach you’re using.  Attitudes and Style are the elements that grab me when I think about Agile.  My attitude — genuinely excited to be at work with my team and sincerely interested in continuous personal and team improvement — make a significant difference in speed of value delivery.

A variety of styles are valuable in Agile.  Personally, I have struggled to deal effectively with people who approach challenges differently than I do, but as I mature (i.e. get older), I am getting better at realizing that there is more than “my way”.  As long as people have integrity and proper intent, I try really hard to consider that their style could lead to a desirable result.

Results

And finally, results matter.  Well, duh, but the book makes a point that demonstrates the mutually-reinforcing nature of Agile and trust.  It is critically important to focus not only on what is achieved, but also on how it is achieved.  Agile emphasizes accountability for results, but it also focuses on sustainability, repeatability — predictability!

“…suppose you hit the numbers, but you do it by creating a team spirit of abundance and collaboration. You help team members work together so that everyone succeeds, no one reaches burnout, and the credit is freely shared. What’s going to be their attitude the next time the challenge comes up? What if you can get the same great results—only this time, it’s going to be 30 percent faster and easier?”

Covey, Stephen M.R.; Merrill, Rebecca R. (2006-10-17). The SPEED of Trust (p. 114). Simon & Schuster, Inc.. Kindle Edition.

In an end-of-chapter section on how to improve your results, the book encourages focusing on results, not the activities needed to achieve the results.  Agile does this via user stories or features defined in business terms by the customer or product owner instead of a task breakdown and by working in small batches that deliver results in a short timeframe.  These activities build the customer’s trust in the team who then gives more work to the team, reinforcing the team’s trust that the customer is paying attention to the results and the direction.  It’s a mutually reinforcing system that leads to performance that is greater than the sum of the parts.

If you’re going to be an excellent teammate on a team, you’ve got to trust yourself.  You’ve got to know that you’re credible.  You’ve got to walk your talk.  You’ve got to know you’re doing things for the right reason.  You’ve got to bring relevant capabilities.  You’ve got to deliver.

It ain’t easy!

At about the same time, the company recognized that it had an issue with trust within the company.  Instead of burying their heads in the sand, hoping the issue would resolve itself like I’ve seen done other places, the leadership team confronted it head on.  The company brought in training and coaching help from CoveyLink, formally reflected on trust behaviors at regular intervals, conducted “360″ assessments — even made trust part of their performance management processes.

Those two decisions and the actions undertaken to become agile and to build trust have had a profound impact on the company’s culture and ability to build products.  Because Agile and trust are behaviors, not destinations, the company continues to work at them and is continuously conscious of them.

I believe that Agile and trust are mutually reinforcing.  In this post, I’ll provide an overview of The Speed of Trust and how it relates to Agile.  In the future, I’ll delve into specifics.

In his book The Speed of Trust, Stephen M.R. Covey puts forth an argument that “trust is not some soft, illusive quality that you either have or you don’t; rather, trust is a pragmatic, tangible, actionable asset that you can create[i]”.  While many, including me until recently, think of trust as a squishy, nebulous concept that is difficult to measure, Covey looks at it a measurable formula where trust impacts speed and cost.  When trust goes down, speed goes down and cost goes up.  When trust goes up, speed goes up and cost goes down.

↑Trust = ↑Speed ↓Cost

↓Trust = ↓Speed ↑Cost

Covey goes on to describe trust taxes and trust dividends.  These are the sometimes hidden variables that quantifiably increase or decrease trust in measurable ways.  As an example, he puts a twist on the traditional business results formula that says results (R) equal strategy (S) multiplied by execution (E).  He says (where T is trust):

(S x E)T = R

In this case, high trust (i.e. trust above 1.0) can be an enhancer of strategy and execution or low trust (i.e. trust below 1.0) can be a deterrent no matter how good the strategy and execution are.

The Speed of Trust uses a model based on waves of trust.

Covey, Stephen M.R.; Merrill, Rebecca R. (2006-10-17). The SPEED of Trust (p. 33). Simon & Schuster, Inc.. Kindle Edition.

The outer waves evolve from the inner waves – it’s difficult to successfully start with organizational trust without relationship trust and it’s difficult to build relationship trust if you don’t trust have self trust.

Self trust relates to our own credibility.  The book focuses on four cores of credibility: integrity, intent, capabilities, and results.  This is the foundation of being able to effectively contribute to an Agile team.

Relationship trust is based on behaviors, demonstrating to others that you are capable of trust.  You need to walk the talk for others to trust you.  Many of these behaviors really resonate with me when I’m thinking about Agile and trust together.

Organizational trust deals with aligning an organization’s structures and systems to decrease trust taxes and increase trust dividends.  This is where leaders can impact the ability of Agile to impact product development from top to bottom.

Market trust reflects an organization’s reputation and trust level of external stakeholders.  If you’re defining “organization” as a company, this wave of trust could get into high-order Agile adoption.  However, looking at “organization” on a smaller scale (e.g. Product Development) with external stakeholders that are internal to the company (e.g. Marketing, Operations, or Account Management) might make market trust easier to grasp.

Societal trust is pretty self-descriptive.  It deals with contributing to the community at large. As with market trust, this wave can be applied with different definitions of “society”.  Society may truly be the city, country, or the world you live in.  It could also be the company you work in.  Or maybe it’s a loosely knit group with a common interest like the Agile community.

Although the relationship between Agile and trust has been percolating in my mind for months, this is the first time I’ll be writing about it.  I’m looking forward to the process of developing my thoughts and getting your feedback.

This is a little late in coming, but Dennis and I want to welcome Rick Austin to the LeadingAgile team. Rick and I worked together back in my days at CheckFree and we’ve stayed in touch ever since. I have personally been plotting to hire Rick for several years now, and finally the time was right. Rick will be doing client work with us and helping with several ‘special projects’ we have in the pipe.  You can learn a little more about Rick by heading over to his bio page.

No… you can’t make anyone do anything they don’t want to do.

That said… when I’m investing my money to have a product built, there are a few things that just won’t fly. It’s not okay to go off for months at a time and have nothing to show for it except a bunch of documentation. It’s not okay to write software that isn’t relevant or recognizable to me as your customer. It’s not okay to work in silos and create hostile relationships with your peers and coworkers. It’s not okay if you can’t give me a credible plan for how you are getting to done. It’s not okay if I have no idea what I am going to get for my money. It’s not okay if I don’t have incremental input into what is getting delivered. It’s not okay to build software that’s full of defects and technical debt. It’s not okay if I don’t understand risk and have no ability to influence how those risks are managed. It’s not okay to waste my money. It’s not okay to deliver the wrong product. It’s not okay to be late.

Agile is the only approach I’ve found that credibly deals with these issues.

So… would I make a team do Agile? No… but I would be really inclined to find a team that would.On another note… this my 400th post on LeadingAgile.  Given how my writing has slowed down over the past year or so… it took longer than it should have to get to this milestone.  That said, I’m really proud of this body of work.  Thanks to everyone that has paid attention all these years

Okay… I finally got off my duff and decided to submit a few talks for the Agile2012 conference this year in Dallas, TX.  Hopefully a few of these are good enough to make the cut so wish me luck.  I’d love if some of you guys would head over and give the talks some feedback.  There isn’t much time before the 2/15 deadline, but anything you might add would be really appreciated and I’d love to hear what you have to say… even if after 2/15 I won’t be able to update anything.

Patterns for Agile Adoption and Transformation
http://submit2012.agilealliance.org/node/15154

Understanding Agile Program and Portfolio Management
http://submit2012.agilealliance.org/node/15151

Introduction to Agile Project Management
http://submit2012.agilealliance.org/node/15150

I’ve got one more space to submit… everyone is allowed to submit up to 4 session proposals.  As it stands right now, I am thinking three might be enough.  That said, if you have any ideas, and want to comment here quickly… I might be talked into submitting one more.  I almost started one on the whole Product Owner/Product Owner Team thing… but as much as I talk about that in my practice, it wasn’t something I felt super-passionate about submitting on.

Let me know what you think… would love your feedback.  Thanks!

Some of you probably already get this… some of you might even disagree… but unless you are building software as a hobby… chances are, you building software for money. In other words, someone is paying you to write software for them.

Why would someone pay you money to show up and write software? They are paying you money to write software because they hope to sell that software and get even more money in return. It is an investment.

Ideally, we should want our investors to get a good return on that investment so they’ll keep investing. It’s our job as software professionals to help our sponsors get good, working software into the hands of paying customers as quickly as possible.  That’s how we make money.

The act of selling software funds our ability to build more software.

Conversely, our inability to sell software makes investors grumpy and a lot less likely to want to keep paying you to write software. Unless we sell software, we don’t have any money to pay people to build software.

To many, the thought that we are writing software for money cheapens our craft… it cheapens our art. We want to be pure. We want to build perfect products. We want to perfect our craft and be artisans.

Don’t get me wrong, I’m all for building great products. That said, at some point, we have to strike a balance between perfection and getting products to market, products that can sell and start generating revenue.

Why am I writing this post?

Over the past few years, I’ve worked with a bunch of folks that have seem to have lost this fundamental connection to the economics of software development. Some where along the way, software became and end unto itself.

…somewhere along the way it became more important to be great engineers.

…somewhere along the way it became more important to be great testers.

…somewhere along the way the design became more important than the delivery.

Some where along the way, it became more important to deliver everything at one time rather than to getting something into the hands of our customers as quickly as possible. I think that mindset is killing many of our companies.

If you were spending your own money to build software, you’d want to see a return on that investment as quickly as possible. As software professionals, we have to start thinking about the economics of software delivery and act accordingly.  How would be build software if our own money was at risk and failure wasn’t an option?