Montague.tv

One of the keys to successfully leading teams of people is to run effective meetings.  On the surface, this seems pretty straight-forward.  Ensuring you have an agenda, take good meeting notes, and sending action items out afterword aren’t rocket science.   Relatively trivial, even though consistency is key and rarely is delivered.  However, when you are dealing with those recurring tactical meetings, especially ones that occur multiple times per week, the old model falls down.

To begin with, there really isn’t a simple strategy to produce detailed agendas any longer.   Many topics, the critical ones that need to be discussed ASAP, sometimes come up just hours before the meeting.  Furthermore, the priority of the litany of things that are on the list changes at a rapid pace.  Sending anything in or prepping for those discussions can be fruitless at best, and counter-productive at worst.

Enter the “Weekly Tactical” meeting format:
Some of the concepts in this format were adapted from the book, “Death by Meeting” by Patrick Lencioni, but others were evolved on the spot as the need arose.

The basic premise of the Weekly Tactical meeting is to get a group of leaders together to make decisions.  We don’t want to go to meetings to “talk” about decisions, we want to MAKE them.  (After all, that’s one of our core job functions)  So many organizations are plagued by the notion that meetings are simply to “discuss”, not to “do”.  This simple shift alone will increase the effectiveness of most meetings.  The word Tactical, for our team, implies that the scope of topics should cover 1 week from the date of the meeting.  We have 2 Tactical meetings per week that are 1 hour each.

Detailed Overview:
The following photos show the simplicity of the process.  I have a large whiteboard in my office that is refreshed each time we have this meeting.  It has the template written on it and is ready when the team comes in.  The image at the right shows what the layout looks like.  I tend to facilitate the sessions, but now anyone can do it as the process is simple and well understood.

Next let’s break down each section with details.

Lightning Round:

Decencies
We have recently added a kick-off titled “Decencies”.  This is probably the one I’m most excited about, and most proud of.  After re-reading Tom Peters book, “The Little Big Things” last week, I was reminded of the need to refocus our efforts on our people.  I’m leading a group of manages and architects and we tend to get mired in the day to day.  The complexity and pressure for those leaders is immense and it’s easy to get stuck focusing on “work stuff” and neglecting the “people stuff”.  Tom reminded me a second time “it’s all about the people”.  Hence, the “Decencies” kickoff was born.

Essentially we will create actions to recognize the wonderful and talented staff we have and the things they do every day to make all of us successful.  We will also think about ways to remember the Power of Pleasant, how we can connect emotionally with our customers, and hopefully keep some “damned perspective” when the tension escalates.

Topics
We then go to each person and ask for their topics.  If you have an issue or topic that you need help delivering, or you need a team decision, then it’s a good topic for our meeting.  They each have 1 minute (yes, 1 minute) to get through their entire list, along with associated explanations if needed.  We then move to the next person, in order, until we have a list of topics.  We then get started at the top of the list.

Note: we used to prioritize the list, but as of late, we have blown through very large lists so rapidly that we haven’t needed to prioritize.  If we start leaving important stuff undone, we will go back to prioritizing.

Actions and Decisions:

We then take each topic one at a time and attempt to give each topic its due attention.  We are all aware of the need to get to an Action or Decision so we tend not to lollygag.  We will discuss for a while and someone will say, “Do you need us to help choose for you?” or “Is there a next action for this that we can assign to one of us?”  More often than not, the topic simply needed a quick decision and some collaborators to ensure there wasn’t something being missed.  Other times, the issue is a bit more complex and the initiator needed help deciding on the next steps to take.

As we move through the list, the grid in the image to the right begins to unfold.  We assign tasks with associated details, 1 per line until we’re done.  Normally a “decision” is indicated with a task to communicate the decision so we ensure we are communicating those decisions effectively.

Parking Lot:

As a group, we occaisionally bump into a topic that has no simple solution or the right parties aren’t present to discuss.  They also span many teams and possibly a large time horizon.  These issues we deem “strategic” and get placed in the parking lot with associated detail.  We have a few venues that these strategic topics can end up in so we attempt to classify them on the spot

Note: this classification exercise is new.  I will update you on how its going.

The three Strategic Meetings are a “TRI-Weekly” meeting that we prepare for in advance.  It includes both leadership teams in my organization (Development Managers and Enterprise Architecture) as well as any special guests needed to (once again) make decisions on the topic at hand in the meeting.  The second is a “Development Manager” Strategic meeting and the third is ”Architecture” strategic meeting….all similar formats.  I will try and describe these formats in a subsequent post.

Well, there you have it.  This evolved format has helped our team and organization communicate better, make timely decisions, and get aftet the topics we know are critical for success.  With the addition of our Decencies section, it will also help us double down our efforts to remain focused on whats important, our people and their well-being!

I’m a firm believer in “surveying the landscape”. I think the time you invest understanding your clients and customers needs, the better off you are. It’s one of those things that’s just reasonable. Don’t jump to conclusions. Don’t pedal solutions before you know the problem you are trying to solve. Which is why what I’m about to say feels blasphemous…

Sometimes it’s just not that hard to understand the real, honest to goodness business issues that are right in front of your face. Furthermore, left unchecked, some could mean curtains for your customers. In that moment, make the tough decision.

For instance, it really doesn’t take much to diagnose a gaping gunshot wound. There is no need to take someones temperature and have someone step on the scales when there is an obvious diagnosis and prescribed course of action. I would classify these types of issues as Organizational Emergencies. These issues need immediate attention! They need decisive action and the trade off between a “timeliness bias” and “consensus building bias” is wildly weighted toward timeliness. If your business problem is of this variety, don’t be afraid to make the tough decision.

In the agile community, we lean toward a complete consensus building model. In my mind, this is a very, very good approach. However, this makes Organization Emergencies more precarious. Often times the process of complete consensus building is near impossible to achieve, and left with the choice of making a tough call or throwing up our hands, we choose the path of least resistance. The typical choice leaders make between errors of commission and errors of omission is to choose omission, every single time (and twice on Monday). After all, we don’t really track this type of error. This makes the process even more difficult to manage and time begins to slip through our fingers.

I truly believe the majority of the decisions organizations need to make have a clear “consensus building” bias. This is why I feel the agile community has it right. But, when you recognize those rare occasions where delay might have dire consequences, find the fortitude to make a decision and trust your instincts.

I have been thinking a lot lately about how I might go about working with teams to ensure they understand the main message behind agile engineering practices. In many ways, the knee jerk reaction of many managers, including me, is to edict the use of common practices and skills. In my past, I have heard many many reasons for why people don’t want to unit test, setup build automation, peer review code, and refactor. What I haven’t heard is a GOOD reason. This has made it even tougher to refrain from handing down a set of criteria to the teams on “how to code”. After all, for me these practices “just makes sense”.

“What” vs “How”
A lot has been said about internal versus external system quality and I think this concept has helped me teach the difference between “what” systems teams deliver, and “how” those systems are built.  When starting a conversation with teams about learning the well tested agile engineering practices, I typically hear a common refrain.

“We are senior developers.  We don’t need to improve quality. We’re doing great…just ask the business!”

In one way, they are RIGHT. The business loves what they are seeing. But quality to a user of a system is only skin deep. They see half the equation (arguably the most critical) but half none the less. They see the working system. They see the new feature they requested and by gosh it works exactly as expected!  The system is performing as expected.  There may be a few lingering issues, but 95% of the system is awesome.  It supports the business just fine.  Mostly, we just need more features, faster!

Lurking Under the Surface
So what don’t customers see?

• They don’t see the manual jobs we kick off behind the scenes every morning to ensure the data “looks right”.
• They don’t see the delays to building products because only one person knows each individual part of the system, and if they are busy (or even worse on vacation), then nothing in that specific module can be delivered.
• They don’t see the painstaking manual testing efforts that go on before we push to UAT.
• They don’t see the manual roll out, roll back, roll out dance we do simply “moving” code to UAT and PROD.
• They don’t see massive nested If-Statements that look like Japanese word art.
• They don’t see the 12 year old version of J++ that their core processing engine is built with, and that if Christy loses the J++ disk she has in her desk drawer, we’re screwed.
• They don’t see how difficult it is to add simple logic to the system each time they ask for something new.
• They don’t see how often even simple changes strike fear into the hearts of anyone relatively new to the team.
• They don’t see the 18 month ramp up time it takes skilled developers to “learn the system”.
• They don’t realize that “regression testing” really means “test whatever we can for the 2 weeks we have left”.  (hint: ~10% of features)
• Etc, etc, on and on, ad infinitum -1.

For the above reasons, we need to be better.  As technologists, we need to be stewards of our systems.  And in many ways, that means protecting both “external” and “internal” quality.

Stewards? What does that mean?
It means if there are time bombs in our code, we have to make those time bombs REAL to the business and advise them how to prioritize up what is critical and to prioritize away what is not. In technical debt terms, pay down your high interest technical debt quickly by prioritizing it as high up in the backlog as possible. Business people will never do this on their own. We have to help them toward this decision.

It also relates to “how” we build systems.  As professionals, we need test automation, build automation, refactoring, pairing, peer reviews, patterns, etc.  This is where my brain and my emotions clash.  On one hand I want to pass down upon high an EDICT, “Thou shalt unit test!”  I would say this is my emotional, impatient side.  Intellectually I understand that I need to lead these teams toward these principles.  More “supposing” and less “proposing”, as they say.  The minute I create the rule, the simple and powerful act of automated unit tests lose their power.  People begin to test in haste.  They write tests that assert nothing so test coverage reports show arbitrarily high numbers.  They write tasks for testing and never get them written.  They come up with every reason in the book why testing isn’t that valuable for them, in their system. And when rules are imposed, any shortcomings, difficulties, roadblocks, or otherwise ill will surrounding the approach are attributed to external sources…namely, me. After all, this is Jason’s RULE. He owns it, not us.

Grass Roots
So, I am back to the grass roots. I want to rebrand engineering principles (and the stewardship it implies) as a virtue, not a rule.  I am back to the task of building a ground swell in our culture.  I am back to focusing my efforts around a few key (and critical) early adopters who have seen the value of software craftsmanship.  With these progressive folks, I hope to create a magnetic pull.  A “why aren’t we doing that” effect that emanates.

With the rest, I have but one request:

“If you don’t think that these principles and techniques are valuable, so be it.  In the absence of using these techniques, please show me how you can assure consistent, sustainable, internal and external quality of the systems in which you have been granted stewardship.”

I am being sincere when I say I am open to being wrong about this.  If those principles I have come to lean on are of low value for these teams (and in their context), I am anxious for a better answer.  More to come!

I recently re-read The 5 Dysfunctions of a Team. I am through it for the 2nd time and find that I have gleaned so much more this time around.

The Role of a Leader: (A look back at 5 Team Dysfunctions)

1. Absence of Trust – Avoid Invulnerability
2. Fear of Conflict – Avoid Artificial Harmony
3. Lack of Commitment – Force Clarity & Closure
4. Avoidance of Accountability – Confront Low Standards
5. Inattention to Results – Focus on Collective Outcomes

In my first foray into this book, I found many insights useful, but not particularly familiar. I read the book quite a few years ago and really didn’t have the background to understand the content that the book addressed. I just hadn’t faced those types of team building dilemmas (or maybe I just hadn’t thought about it that way). Even in an Agile coaching capacity, I find many small teams quickly gel and find a rhythm, building trust, managing conflict with help, and holding one another accountable. I think software teams are, in the end, really good at this given some subtle guidance.

Fast forward to 2010
I’m currently part of a management team that displays many of the detrimental failure modes that the book describes. Sadly, I’ve come to realize over the years that this is more the rule than the exception. The team members are all, individually, extremely talented.  They are also great people.  I mean that sincerely.  This fact makes me both hopeful and fearful at the same time.

It’s great news because it’s obvious that my current challenge is unambiguous and squarely in front of me:  work on building a dynamic and healthy TEAM.  It’s also scary because I now know what I need to do: work on building a dynamic and healthy TEAM!

This supremely simple concept, the one that eludes 95% of leadership teams in all types of organizations, is one of the most difficult experiences teams can go through. Knowingly embarking on that journey is a sure-fire way to bring emotional exhaustion and short-term discomfort to your collective lives.  But alas, like many things in life, I know it’s critical and completely necessary. There is no exception.

Mentally I know that this hard work and emotional discomfort will be the only way to long-term fulfillment and happiness in a collaborative endeavor like building great software for customers.

Outlook
I’m growing more encouraged day by day.

“Drive”, by Daniel Pink answers plainly the omnipresent question “What will make me happy and engaged in my life and  career?”. What I have felt so strongly throughout my career is confronted head on in this book and the answers you uncover will likely surprise you.

Like many, I typically would fall back to standard, cliche’ answers:

• “I want to be promoted. If I just moved up, I would be happy.”
• “I want to manage people. The more in my organization, the happier I will be.”
• “I don’t have enough money. I really just need more money to be happy.”

 
All of these things have come pretty quickly in my career, and I can tell you without doubt, they do not ensure sustainable engagement, motivation, or happiness. The things that have motivated me seem to be the residue of having a persuasive personality and organizing my work (come hell or high water) to give myself the three things Dan Pink describes as critical. 

1. Autonomy – being self directed and interested
2. Mastery – being great at what I do
3. Purpose – what I do “means” something and makes a difference

 
Not only does the book describe those motivators, it also explains the incredible disconnect employers of “thought workers” have had (and still have) related to what motivates their teams and workforce. I happen to work with teams that create art for living (software systems). These people spin value out of whole cloth. They essentially take concepts and thoughts and turn them into tangible goods for others to hold, interact with, and use. I cannot think of a better definition of a “thought worker”, can you?

Yet, nearly every employer of software developers I encounter has had it wrong in some form or another. To begin the journey of trying to satisfy the needs of those team members, you first must understand what motivates them. The book has moved me a bit closer to that understanding. This video, brilliantly produced by RSA Animate, gives you some of the shocking truth behind what motivates us.

Recently I ran across a manuscript that my father was writing some 25 years ago. The topic: how to engage and cultivate greatness in a battered, and oft embittered workforce. My father focused his career managing companies, mostly in the manufacturing sector, so you can imagine the context of the following line:

“If we are to cultivate greatness in our organizations and in ourselves, we must learn to tolerate and acknowledge failure, and have a fervent disdain for apathy.”

Can you imagine what that statement might have meant to a union worker at that time who was all but *commanded* not to care?

Union Labor vs. Knowledge Workers

I can just imagine the union dominated workplaces, the heavy handed bosses who sat up in the plant office looking down at the hired help, and the scores of unmotivated and distrustful factory workers staring back up at them. As I read through the pages, bound together into distinct chapters by binder clips and rubber bands, that one line stood out. It still does. “Failure”, the subject of a few of my recent posts, is something I seem to be exploring these last few months. Mostly because I see it for what it is, for what it truly stands for, and how wrong our command-and-control heritage had it. I also think of how good, comparatively, we have it. Many of my staff have Masters Degrees. Some have had PhD’s. Most are still searching for an organization that will allow them autonomy over their work and a healthy place to practice their craft. I can’t say the same of the factory worker of the 70′s and 80′s. How good I (we) must have it, right?

My father passed away in the early nineties before he could publish his book. He had gotten through six chapters and what notes and collected data that accompanied these six chapters has long since vanished. At the time, I was an awfully young man caught up in endeavors that feel a thousand miles away from this.

Failure is an Option. Stopping is Not.

Fast forward to 2010. I am in the middle of a career spent coaching others, cultivating relationships and friendships, striving for purpose and mastery in the field I have chosen. I now have an opportunity to lead others. To teach. And I hope, in some small way, to inspire. Every day I think about how truly difficult it is for me to discuss these heavy topics in a meaningful way. Every day I feel like I can’t quite pull our teams out of the rut they find themselves in, inching toward some level of congruity and understanding. Everyday it feels like someone in the management hierarchy is willfully subverting *every* effort toward a more sane and rewarding workplace. I know this is not true. But it does FEEL true sometimes…even through the exciting highs and feeling of accomplishment our field provides.

Caring Enough to Do It Again

After finding his book and imagining the “all but impossible” tasks my father must have gone through, I now have a slightly different perspective. Failure is an option and one that must be tolerated and even expected. The hard work, the true heavy lifting, comes in the form of caring enough to do it again. To learn what just happened, revise your strategy, and do it again. The moment you let apathy creep into your day, even *after* a monumental failure, you’ve lost.

Now, everyday (win, lose or draw), I vow to do it again tomorrow and try something new. I do it again – because I care enough about the outcome, the people, and myself – to do it again.

In the last few months, I’ve been reading and discussing a few different books. One is Chad Fowler’s “Passionate Programmer”. I’ve found his book to be extremely entertaining and in many ways have spoken to me at some level.

I have felt for some time that careers of those I meet (at least a high percentage) are simply “drifting where the current takes them” instead of having a specific purpose. As Chad puts it, they are not leading a career of “intention”. This is one of the first steps to understanding how to look at your career and manage it like a business (with YOU as the product). Intentionally create a brand. That brands sole purpose is to elevate YOU as it’s product.

The question I have posed to myself is, will creating a personal brand, complete with all the trappings of my own distinct personality really help my career move forward?

Well, that is a goal I have set out to test. I currently have a strong, sometimes overwhelming feeling that my career has stalled in some way. I work for a large enterprise leading development teams that write large enterprise-scale software systems. By my standard I am making a good living for myself and my family. I am staring at a good job working with great people. Is that enough?

So now I am taking the advice of Chad Fowler and asking myself – if I were running a company with ME as the product, would I be OK with the results I am getting? Or, would I want to push the envelope, take risks, and come out on the other side with a remarkable product and career? I am feeling compelled to make an honest effort at setting my career and character apart from peers. I would say I am taking a path that leads me to educate myself in every way I can and not rely on a typical approach. As James Bach says, the typical path will ultimately not help you distinguish yourself, but will only place you in a slightly smaller (yet still massive) sea of similar people with very little chance of differentiation.

Interestingly enough, when I pose these tough questions to myself using Fowler’s advice as a backdrop, I always have the same answer.

Today I was invited to go to a seminar and talk about a new book, “The Superperforming CEO”. The books author, Dave Guerra, found me through a local organization I help coordinate – Milwaukee Agile. When I spoke to Dave prior to the seminar, he mentioned that he was very interested to get more plugged into the Agile community as the concepts that Agile proposes are very similar to that of his book, and life’s study in management and leadership.

The seminar was very interesting and as the talk went on, I found that he was indeed singing out of the same hymnal that agilists are regarding leadership and management.  Dave also explores the duality of problems and opportunities that business people encounter.  Here are some of the critical takeaways I received from Dave’s talk (and book) that support agile tenets:

• Super performing leaders share common traits that are pervasive – part of their fabric.  They have transformed from managers to Servant Leaders.  This models the approach used by scrummasters and agile managers (remove impediments and cultivate an environment to innovate and get the job done)
• Great leaders understand that getting process well defined without a great culture leads to unsatisfied workers, stifled innovation and broad under performance. They also understand that having a great culture without process control leads to terrible mismanagement and woeful under performance.  Similar to agile techniques, these systems need to exist in balance and are ever-evolving.  (Manage your processes and Lead your people)
• Dave spoke of a principle he calls “tacking” similar to that of sailing.  Tacking too far in one direction can throw a system drastically off course.  Minor, incremental (or evolutionary) shifts in direction yield the best results, and will serve to keep your ship upright as a side effect!  Agile often manages this through short iterations, and constant feedback through retrospectives to make micro-changes to the process.
• Superperformers are those that consistently perform over time.  This is similar to the concept of sustainable pace and continuous improvement in the agile paradigm.
• Superperformers tranform “flow” and consistently look for ways to optimize.  Kanban and Lean help in this regard by managing flow of work into the system and eliminating waste.
• The foundation for Superperformers is “passion”.  The passionate CEO will liberate the the teams to become superperformers individually by giving them the tools, encouragements, and environment they need to thrive.  This concept is similar to Scrum and self-directed, highly motivated teams.

Over all, Dave did a very good job of highlighting the key principles of the Superperformer and how to begin to achieve or unleash the super performers in our own organizations.  The book seems to have some very good detail and touches on a much broader, more tangible set of principles and some steps to take to begin to explore this on your own.  I will try and read the text this weekend and update the post.  On a personal aside, one of the things that struck me about Dave personally was his authenticity and his willingness to “want to help”.  I think he does see the value in the concepts of servant leadership, and is putting them to use in his own career as he tries to spread the word of his life’s study.

I was speaking to one of the guys on the team yesterday and discussing what I might propose for the Agile 2010 conference. (I gotta tell you, I’m somehow worried about what I might propose as I always feel that people who would be going to a conference, and paying good money to boot, won’t want to hear about my petty learning. He has convinced me that I am over thinking that one. I’m reserving the right to worry again based on how my proposal comes together.)

The basic concept is to talk about something I have experienced at each of the three major organizations I have proposed and led adoption of agile principles. This has happened in all three, even with hindsight being in my favor. What is it? It’s the feeling of hitting a productivity plateau somewhere around year 1 to 1 1/2 of our agile adoption. Over the span of leading these changes, I have realized that each organization seemed to be hyper focused in certain disciplines, and neglecting the others. Moreover, it seemed to follow a line dissecting Project Management methodologies from Engineering methodologies.

I know this concept isn’t new, but I call these the 2 pillars of agile. I think they are “pillars” because I feel none of the hyper productivity claims can truly be realized without both. If either is absent, you hit a productivity plateau. In my Agile 2010 proposal, I would like to discuss these pillars; the project and process management framework, and the engineering and development principles and practices. I might be oversimplifying this a bit, rolling lots of critical stuff together in one big package, but this is the way I have seen it unfold in all three major organizations.

Let me describe the adoption process and see if you see any similarities to your implementations. Typically, we have very focused, engaged teams in the initial adoption. Just meeting daily and retrospecting our work is a boon to efficiency. People love it. So much so, that the groundswell quickly spreads to other teams and eventually, management wants in. The promise of Scrum is typically alluring to IT managers. Who could blame management for thinking this way. “You mean to tell me I can see everything my teams are doing and have instant transparency!?…and the teams want to do that?” Why wouldn’t they push for that. (By the way, that’s not what is said, but I’m pretty sure that is what they “hear”).

What I am finding in my experiences is that, if Scrum or Project Management adoption is easy, then the 2nd pillar of engineering and software development principles comes extremely hard. If the opposite happens and the XP principles are first out of the gate and get the focus, then the adoption of a project management framework is hindered.

I truly cannot explain this with data, but have some theories. My current theory is that organizations that are willing to focus so much energy around project management and organizational “stuff” are typically ones that don’t truly value, or even understand, the artistic and complex nature of building software systems. If the inverse is true, then my theory is that engineers are the ones who’ve started the movement toward XP agility, and don’t have much sway over the teams that manage projects. When that happens, it’s difficult for engineers to get the necessary buy in from project managers or IT management.

So how do we fix this? Well, my strategy has been an evolutionary one. I happen to belong to the type of organization that has allowed Scrum to smash into it like a tsunami. It’s been good thus far. As my theory holds, our teams have struggled getting much traction in TDD and FIT test automation, pairing, continuous integration, etc. I do see pockets of adoption though. Some groups are great! The majority are hoping Scrum solves their problems. The goal is now to leverage those people who are trying to do both pillars effectively, along with some savvy project managers and make little additions to the culture over time. Like building a house, brick by brick.

I’m encouraged by some of the little wins we are getting so far, but moving ourselves off of this plateau will be difficult. That said, I think we can do it, and that means you probably can too.