Take the example we used of a control culture.  Control cultures, as defined by William Schneider, succeeds by getting and maintaining control.  At it’s best, control cultures can be extremely efficient when  they optimize their rules and processes and at their worst can spin without progress while trying to strictly define and optimize those rules.   The Re-Engineering Alternative goes into greater depth about the strengths and weaknesses of each of the 4 culture types (control, collaboration, cultivation, competence).

What I disagreed with in our discussion is the assumption that Kanban aligns well with control culture.  It’s not that simple.  An organization may have a dominant culture of control, and depending on the size of the organization, teams and departments will establish their own identity and sub-culture.   From a management or executive perspective, Kanban, and more specifically Lean, *can* align well with control cultures because of the explicit tools and practices, the visibility of the work, cycle-time, lead-time and a whole host of deliberate practices that give managers and leaders data they need to find problems and make improvements.  More plainly stated, it’s not the fluffy Agile stuff that means absolutely nothing to a new CEO who has 2 years to get profitable.

What about the team level?  Teams within control cultures can use whatever method works best for them like Scrum, XP or Kanban….or anything else for that matter.  Taking this a step further, at an enterprise or portfolio level in an enterprise organization, Kanban can be quite effective for visualizing projects, programs, products and more.  Enterprise organizations have much more complex systems where work flows through and have, dare I say it, handoffs to downstream teams or departments.  Purists obviously will challenge that with the typical “build cross-functional teams, hug everybody, break down those silos!” and while I agree on a principles level, reality in some enterprise organizations is that their structure isn’t able to support that.    Yet.  As an example, while working in a large enterprise organization, it took us 5 months to get approval to get a cross-functional team together and we had to plug-in our output to downstream “traditional” groups.

Another example, I’m working in an enterprise transition now and we’re using Kanban across the portfolio, plugging functional groups into each other by making the work visible and eventually we will (or might) have some dedicated project teams that make use iterative approaches, including Scrum.  We can roll up project and program status from any team or functional group area into a larger Kanban system that speaks  to management by showing them flow, which is what they are concerned about.    That will help us define capacity, set expectations, find bottlenecks and determine our next transformation steps.  Kanban is much less disruptive and sometimes it’s a better choice to start with, again, read the system and decide what’s best.  Scrum will expose dysfunction quickly and painfully and I find novice coaches preach the Scrum gospel without ever actually having worked in an enterprise where there are strong functional silos, finger pointing and sometimes anger towards other groups.  I’ve been there.  A few times.  I’m actually a bit miffed at myself for being a “beat you with the Agile stick” guy earlier in my career.

Semi-rant over.

Then we got into the people aspect of culture.  Again in this session the topic of “how can we manage resistance” came out.    Read my last post about that. Resistance is a surface response.  Imagine you are a developer and someone comes up to you and says “I have this great book on TDD I think you should read.  It’ll really help you.”  How would that make you feel?  Bringing in Kanban, Scrum, XP, Zomblatt or any other change is a change.  People transition through change no matter what their organizational culture is and it’s pretty ridiculous, IMO, to say one method is going to work better in a certain culture without considering the people being affected by the change.  If people were fungable, meat-based, programming units, or robots, maybe it would be that simple.

Take me for example.  I love change because I love solving problems and change brings problems for me to solve.  That’s who I am, it took me years to understand that and learn patience.  Someone who loves detailed plans and doesn’t like un-certainty may naturally fight against change because that’s who they are.  Someone who loves people will feel they need to make sure everyone going through the change is ok.  Some people find change exciting because it’s new and shiny.  All these people will be affected by change in different ways.  You know that guy in the meeting who doesn’t agree with everybody else about  the newest change to that process?  There’s a reason why.  Maybe he doesn’t understand what the change is.  Maybe be doesn’t see the need for the change.  Maybe he’s in the wrong meeting room. Maybe he is just being an asshole.   Listen to his opinion, show him you understand and move on.

Here’s a diagram of how the 4 MBTI temperaments can be affected by change.  Again, people aren’t robots, there are extremes to temperaments as well, I am strongly introverted.  So introverted in fact after the open space I had to run home to a dark corner to get my energy back even though everybody else went out for drinks.  I’m working with a strongly extroverted fellow and sometimes I have to tell him I need time to internalize when he’s flying at million miles and hour!

This is the Satir change model.  A change (foreign element) is introduced and you spiral into chaos until you hit the transforming idea.  Then you integrate the transforming idea into your identity and arrive at the new status quo.  I’m the blue guy (SP).  ”Yay, problems to solve!!!”  This is great for me, maybe no so great for the SJ (Orange).  I can bring in change for the sake of change leaving the SJ to thrash in chaos which will inevitably frustrate them and then they could be labelled as “resistant” or “not a team player” because they won’t go along with that change.  The NF (green) simply may want to hug everybody and try to satisfy everyone affected by the change.  By the time you read this, the NT (red) has already gotten bored and moved on.

Again, these are based on natural preferences of temperaments and they will hold some truths for some people, people are too complex to say “because I’m an SP I can’t learn empathy to help people transition”  Types and temperaments aren’t to be used to pigeon-hole people, I use them to be aware of myself and my natural tendencies so I can adjust to others around me.

Understanding organizational culture is important, understanding the people within that culture is much more important.

If you’re interested more in this topic, Don Gray and I are doing a half-day workshop on people and culture at Agile 2012.

As a change agent it’s important to recognize, while your purpose is to help bring change, people affected by that change are going to be progressing through it at different rates and intensities.  More plainly stated, some people may appear resistant out of fear.  ”Does this change mean I’m going to lose my job?  Why are you telling me I need to change?  What’s wrong with me?”  Some people may welcome change because they naturally get bored with the status quo.  Some people will be impatient with results from the change.  “Hey, it’s been a month, why isn’t anything different yet?”

There are plenty of models to help with change from ADKAR to Satir to the Kotter Model and each have their own strength and weaknesses as well as approach.  I have more experience with Satir simply because I’ve been exposed to it the most from AYE and PSL.

Change artists need to find a balance between knowing when to push a change, encourage change or even when to avoid or delay a change.  People, teams and departments are all going to react differently to the introduction of new processes and methods.   One team I’m working with now are a close group who talk frequently during the day so they have stand-ups every-other day.  Other teams are having stand-ups every day.  One department is having a hard time getting everyone at their stand-ups for a variety of reasons so they haven’t figured out a cadence that makes sense for them.

During this phase we are helping teams make their work visible and helping facilitate their stand-ups until they get the hang of it.  We’re not forcing the team who is struggling to stick to these rules because the behaviours and outcomes we’re seeing (while some would say it’s resistance) is showing us there are other problems that are preventing them from being able to do this right now.  Everyone is busy.  Everyone is working on multiple projects.  Some have standing meetings elsewhere.

The point is we’re working to accommodate them not forcing them to stick to our “transformation plan”.   As a change artist, there’s a time to push, a time to encourage and a time to lay-off.  The tricky part is figuring out which to do, and when.  I don’t expect to master this skill, I expect to use what I know, and my gut, to help me make the right decision at the right time.   Pushing at the wrong time can lead to people thrashing in chaos which can do more harm than good so the next time you’re seeing ‘resistance‘, take a step back and find out why.  It could be actual resistance and, from my experience, it could simply be bad timing for the change you’re trying to implement at the time.

I’ve been involved in discussions where if you don’t attack certain problems, you’re not progressing towards Agility.  In my younger and less-experienced days I would whiz pretty much anywhere because that’s what I was brough in to do.  Make obstacles and problems aware and help find solutions for them.  Maybe I’m getting old(er) and more mature now so I’ve learned how to find a better balance.

Recently I ran into one of these fences and my first instict was to whiz on it.  Then I realized at that particular point it wasn’t part of this specific phase of the adoption.  It’s certainly a battle I will need to fight down the road, but for now it’s best to leave it alone and focus on the immediate needs.

I guess the lesson I’m trying (poorly) to get across is that different people will approach this problem differently.  Purists may whiz away without consequence in the ‘name of Agile’ whereas pragmatists may avoid it entirely and be shamed as ‘not being Agile’.  All of that is nonesense.   Every transition I’ve been part of has had immediate, short and long-term objectives.  Some battles simply need to wait until the time is right and if that’s ‘not Agile’, so be it.  I’d rather not be Agile than cause harm to an organization by whizzing on an electric fence, no matter how stupidly placed that fence may be.

By the way, I’m hoping some will get the ‘whiz on the electric fence’ reference from a rather entertaining 90′s era cartoon.

As an example, in the eyes of a business person, 100% code coverage via tests sounds great.  Why wouldn’t you want 100% code coverage?  That has to be good doesn’t it?  Well, not really.   When a business person hears “100% code coverage” they can interpret that as “awesome, we have perfect quality!”.   I worked with a client where the team actually said to the stakeholders that the quality would be excellent because they had 100% code coverage.    What if customers couldn’t figure out how to use the software and had to keep calling the helpdesk which drives up cost?  What if the infrastructure is brittle and the software is frequently offline?  What if the feature that has “100% code coverage” doesn’t even work because there’s some stupid validation problem with data being entered?  Is that ‘awesome quality’?

Nope.

That said, measuring code coverage is a great metric FOR THE TEAM.    Teams can use tools like Sonar to analyse the code so they can see what areas have coverage, what areas don’t, what areas are more complex than others etc.  It’s not a metric that should be used by the business and stakeholders as a quality measurement.

A much more effective measurement of ‘quality’ from a business perspective can be inbound helpdesk calls.  If your call volume keeps going up, you have a problem.  Who knows what that problem is, it could be more usage from more users, it could be legit ‘quality’ problems and more.   Use that metric as a way to start a conversation.

One interesting point I hadn’t considered before was that executives like ‘stupid metrics’ possibly because of liability issues.  Let’s say the company get’s sued for some reason because the service was offline or broken.  They may need some metrics to show what quality controls exist.   I can understand that but I think the metrics used in such a situation don’t have to be the stupid metrics Paul was talking about.  In that situation, showing your quality controls is more important than say,% feature coverage.

Stupid Metrics and How They Can be Gamed

• pass/fail %: if 100% of your tests pass but the tests aren’t actually doing anything.  It’s easy to write stupid tests to bring that number up.
• bugs reported per tester: easily gamed, promotes bad competition between testers (IE: “ooh, this pixel is out of place, I’m reporting a bug!”)
• Total # of Test Cases: more test cases is meaningless, you want quality, not quantity
• Test Cases executed by team/individual: test cases vary by size and complexity
• Target % of Test Cases Executed: Is it better to have 95% of test cases executed where the last 5% are gamed than to have 90% legitimate test cases executed when you have a go or no-go release meeting?

What are Better “Quality” Metrics for the Business?

We almost had to sleep in the car our last night before our morning flight because there was a telecom conference happening so hotels were booked but we ended up finding, apparently, the last hotel room in Moncton which was a ‘spare room’ with a couch and table, no bed.

Planning has always been challenging for us as we share the same natural preference for keeping ‘things’ open-ended and not worrying about stuff before we need to.   It isn’t all unicorns and sunshine though.  Many times lack of planning bites us in the butt from simple things like “oh crap, we have no more milk for morning breakfast” to “oh crap, I forgot to pay our property taxes for the last six months“

She’s an extrovert and I’m an introvert so I get tired quicker doing too much stuff at the same time.  She tends to want to cram as much as possible into each minute of the day because “it has to get done”.    Usually what happens is she gets distracted, switches tasks frequently and accomplishes less and is then frustrated by it.    Last Saturday we decided to have a birthday party for our now-seven year old and she was frazzled.   I suggested a simple task board (which we used to use a few years ago but stopped ) and we grabbed some stickies and made a simple to do, doing and done board.

We then wrote down everything we needed to do and prioritized the list and started working.   By the way, she’s an Zumba Fitness instructor (shameless plug: if you’re near Milton, check out a class! You might see me there!), never worked in an office setting or IT and all she knows about what I do is that I help companies adopt ‘Agile’.

Today we had a quick retrospective and this was her un-edited feedback:

1) What did you like about what we did?

“It helped me organize to get stuff done faster without forgetting stuff.  Less confusing to work, didn’t feel as overwhelmed.  I don’t know if that’s the right answer or not!”

2) What didn’t you like about what we did?

“Nothing.”

3) What would you want to change next time?

“Nothing, it worked as I was able to get stuff done.  When I got sidetracked I looked at the list and got re-focused on what I needed to get done.”

I observed her working on one or two things at a time instead of starting and stopping many.  When I saw her start something that wasn’t on the list, I asked her if it was important or not.  That helped her re-focus as well.  The interesting part, for me, was that never did I use the terms ‘agile’ or ‘kanban’.

Based on her feedback, she was more productive by working on fewer things at a time, being visible about the work to keep herself honest with herself and being disciplined (with some help from me once).  That’s what Personal Kanban is and it’s not necessary to use those terms

I’ve always felt retrospectives are the simple most important aspect of Agile, the rest, while important, focus on process over progress even though that’s the opposite of what the manifesto intended.  There’s more power in creating a sense of urgency for change by exposing a system to itself through discussion.  The trick now is, can we keep this up?

Firstly, I don’t like metrics and measurements as it relates to “productivity” or “measurement” of people.  I don’t know how to measure those and I haven’t heard any valid arguments for doing such.

For argument’s sake, let’s say you need some non-sensical measurement to rate the effectiveness of a Scrum Master because you don’t trust them you want to reward high productivity.

I introduce to you, the Impediment Resolution Metric.

Here’s how it works:

1. Team has an “impediment”
2. Put the impediment on a visible impediment wall using a sticky note.
3. for each hour/day/week/month/year that passes, put a tick on the sticky note.
4. Have the team define what “done” means for that impediment
5. Track number of impediment resolutions per hour/day/week/month/year
6. If the average time-to-resolution of impediments increases, shame the Scrum Master publicly
7. If the average time-to-resolution of impediments decreases, give the Scrum Master a cookie

Seriously though, how would you know if your Scrum Master is doing Scrum Mastering stuff?  Well, you can start by asking these questions:

1. Do your team meetings still suck?
2. Are your retrospectives the same old boring “well, not well, try” that rarely have actionable items attached to them?
3. Is the team constantly over committing?
4. Under-committing?
5. Are you still using a stand-up token like a ball or beanbag?

What do you think?  Can you measure the effectiveness of any employee in knowledge work?

Sally proclaimed, “it’s a great company to work for, about 350 people, there is a lot of excitement and enthusiasm about going to Agile, management is 100% fully supportive of it!”.

“That sounds great”, said Jackson, probing a bit further he asked, “can you describe what they are looking for?”

“Oh sure,” replied Sally.  ”They are looking for an Agile evangelist, someone who can coach executives on how to change their organization, someone who knows how to relate to developers and QA, someone who can mentor all their Project Managers who are now Scrum Masters and somebody who has experience with doing training, empowering self-organizing teams and someone with extensive project management, product management and technical background.  They really need help!”

“Wow, that sounds like a lot responsibilities, how long have they been ‘doing Agile’?“, a less-than-surprised Jackson said.

“Oh, a couple of years, they’re just looking for something to help kickstart them to the next level. It’s a 6 month contract.  What hourly range are you looking for?  They have budget for about $90 an hour“, said Sally.

“Interesting“, replied Jackson, “Can you tell me about the structure of the organization, who this coach reports to and what type of work they do?”

“Sure,” said Sally, “they have a PMO, oh, and you would be reporting into the Senior Manager of the PMO, and they have Scrum teams on the ground who work on their Widget X products, an Ops group, an architecture group, a BA group and a QA group.  You know, the standard Agile stuff.”

“Sounds like there are lots of handoffs going on based on what you described, I’m guessing they are having some challenges with quality and getting their projects done on time.” , said a concerned Jackson.

“Yes, that’s why they’re looking for a coach, someone who can come in and mentor people to help get the quality bar raised.“, said Sally, sounding a little annoyed at all of Jackson’s questions.  ”So what’s your rate?  I can setup an interview today if your rate is within their budget.”

Always the curious cat, Jackson agreed to have a call with the company.  ”Great!”, exclaimed Sally, “I’ll be in touch!”

Does this sound familiar to you?  While I may sound like I’m being a bit snarky towards organizations looking for a coach and recruiters, there’s a whole lot more going on then the words in the fiction-yet-based-on-experiences story above.  I’ll leave that up to you to discuss and I’ll follow up with a more in-depth post later.

Lately I’ve noticed Agile, and Agile Coaches in particular, are getting kicked around on the interwebs.  Everything from the evils of Agile coaching to the hypersensitivity  to tools in Agile.  I’ve seen many tweets about snake-oil salesmen, why nobody but <insert twitter handle here> really gets Agile except me and more.  What seems to be getting lost, IMO, is the Prime Directive: “People are doing the best they can with what they have, which includes skills, training and experience.”  That’s paraphrased of course.  I don’t know any Agile folks I’d consider to be ‘snake-oil’ salesmen.  I know a few that are thought-leaders (well known and not-so-well-known), a few that haven’t figured out how much they don’t know yet and everywhere in between.  The point is, they are doing the best they can with what they know and the skills and experience they have.

So how can you find the right Agile Coach for your organization?  Here’s some tips based on my knowledge and experience.  Your mileage may vary.

1. Don’t let the first thing you do be hiring a recruiter:  No that’s not a slight against recruiters, Agile Coaching is a relatively new role and I don’t think recruiters have enough experience in this domain yet.  If you want help with Agile, start with the community.  Find a local user group, online community or reach out to your network.  Implementing Agile takes courage and dedication and if you cannot spend your own time learning or talking to people in the Agile community (FOR FREE BY THE WAY), you are less likely to be successful.  Worse yet, you may develop a mindset that the coach is going to fix everything because, well, that’s what you are hiring them for.
2. Have a purpose in mind:  Suppose you’ve followed my advice from step 1.  Have an idea of what problems you want to solve and be transparent about them to your potential coach.  Coaches are smart people and many have training and experience in organizational behaviour, human behaviour and have studied (and used) many meta-models and Agile processes.  They are going to see right through  a smoke-screen like “we *just* need some training for our BA’s that hand off specs to the team” and other non-sensical stuff.  The more transparent you can be the better, the coach will figure this out anyway and you will spend more money while he/she figures this out.  Having a purpose will help define what success looks like.
3. Be realistic:  The odds you are going to find an expert in organizational change, programming, testing, requirements, project management and the other 30 things you list on your job description are slim….really slim.   If you think having a superman coach is a good idea I’m going to bet that you think this coach is going to come in and magically fix everything by sprinkling some process dust on your organization.   Chances are a coach is going to recommend more coaches or consultants with more specialized skills in certain areas.
4. Have a budget in mind: Coaching isn’t cheap and there’s many reasons for that.  Personally, I spent close to $15,000 on my education last year.  That’s going to training courses, conferences, open spaces, experiential learning workshops etc.  The coaches I know invest in themselves and you, the client, are benefiting from our skills, knowledge and experience.  If budget is constraint, consider options a coach will provide for you.  For example, I was once asked to do a 6 month full time contract to transform an organization at a rate middle-level project managers make.  The skills required for this are much greater than the skills a middle-level project manager have.  Would you hire a CEO to fix your business for $85K per year?   I recommended to use that budget more wisely by not having a 6-month full time coach but instead a front-loaded engagement with recurring touch-points.  That’s one example.  The point is, start a dialogue.  Your policies may state “thou shalt hire contractors in 6-month increments” but don’t let that be a barrier.
5. Be ready to be challenged:  A coach is going to challenge your assumptions and your organizational processes and structure.  A good coach will risk getting fired by challenging your status quo and they will do it with respect and professional courtesy.  Be ready for it.
6. Understand what a coach is:  It sounds hypocrtical for me to say this given my domain is “agilecoach.ca” but “Agile Coach” is a made up term.   I don’t know where it came from but it sure sounds cool.  Better than “Agile Consultant” anyway.  Recently Michael Spayd and Lyssa Adkins have been bridging the gap between “Agile Coaching” and, well, actual professional coaching.  Some Agile Coaches may be process specialists only and not understand organizational change.   That described me many years ago.  I learned quickly there is much more to Agile Coaching than meets the eye.  If you want to hire me as a coach, I will have my own expectations of what you want right off the bat simply because you used the word “coach”.  If your intent is to “hire a coach” and put them on a project as a project manager or Scrum Master, you don’t want a coach.  You want a project manager or a Scrum Master.
7. Don’t try this at home:  I don’t know how many times I’ve heard, “meh, we’ll do it ourselves” in the software industry.  That’s not only for adopting Agile, that’s for building software.  Meh, who needs a usability person, just get Mr Graphics man to skin it.  Bah-humbug, it’s *just* testing, find something who can work a mouse.  I wish those were fictitious examples.  You will be well-served by a coach and will spend much less on a coach than you will learning the hard way.

Now that you have some tips for finding a coach, what can you expect from one?  Again, this is based on my style and experience.

1. Some type of assessment:  A coach needs context which means they are going to ask you lots of questions and will need to talk to people to get a deeper understanding of what problems you are trying to solve.  Different coaches will do this differently.  Personally, I take the Naked Consulting approach, I’m not going to give you a document or outline, I’m going to come and talk to you FOR FREE for a couple of hours and figure out if I can help in the first place.   If your needs and beyond my experience, I’ll help you find somebody more appropriate for your situation.
2. Front-loaded engagement: Unless you are a large company looking to transition your entire organization, you probably don’t need a full-time coach for 6 months.   Most of the effort with coaching is early on when you are in learning mode.  A coach’s goal is to make themselves obsolete as quickly and efficiently as possible and there are numerous engagement strategies.  If you’re a smaller organization, an embedded coach for a couple months might be best.  If you have multiple teams, up-front training/workshops and facilitation may be better.  If you have been trying Agile for a while, a mentor-ship program might be best.  A coach will help you figure this out.
3. Metrics and ROI are really hard to figure out:  It’s reasonable to expect you want some type of assurance that your money spent isn’t a waste.  As far as I know, there’s no success metric for implementing Agile.  Some of the metrics I’ve found useful are escaped defects (how many defects found in the wild after release – which should decline by the way) and net promoter score (how likely will people recommend your product or service).  ”Vanity metrics” like in-process bugs fixed (before release), velocity and on-time releases, IMO are less useful, if useful at all.  More than likely the payoff for being successful with Agile is going to come much later.  If you have ideas for some type of Agile success metric, I’d like to hear it.  Wherever possible, tie metrics into business outcomes.
4. Kind or Brutal Truth? Decide if you want the kind or brutal truth.  All organizations have politics, expect a coach to kindly, or brutally, show you the impact your organization’s culture, politics, technology and people are having on your adoption or transformation to Agile.  Sometimes under an incompetent manager is a high-performing team that can’t emerge under a controlling manager who treats his employees like cogs in a wheel.  Given there’s a reason for that behaviour, you can do nothing, try to change the manager, fire the whole team and get team members who thrive under that sort of management, fire the manager, move the manager to another department and more.  There are always many options to consider, a coach will help you consider them by telling you the kind or brutal truth as they see it.
5. Success Criteria and Visibility: A coach will need your help too.  Expect a coach to ask for time for people to learn new skills.  Expect a coach to ask you to set aside budget to send people to conferences so they can learn more.  Expect a coach to be responsible and accountable by making the work they are doing visible in your office.  I like to use an Agile transition war room, or if a room isn’t an option for whatever reason, an open area in the office to be transparent about why the coach is there and what they are doing.
6. Expect to bring in more people:  Pairing isn’t solely for programming.  Different perspective matters and is much more efficient than relying on one person’s opinion.  I’ve solo coached and pair-coached, pairing wins out every time because when I have a crazy idea, a pairing partner can say “hey, that’s a crazy idea, I think this other idea may be a better option!“.  Voila, you’ve just been saved from a 2 week experiment on a crazy idea.  Again, your mileage may vary, you might not need more people, but then again, maybe you will.
7. All Coaches are Different:  Personally, I skew on the side of possibilities and people focus.  That is to say my coaching approach is generally skewed towards Agile values and principles.  Some coaches may have a more process-centric approach.  Some coaches may come in and install processes and do training while others may go deeper into your people and culture.  The right approach is the one that works in your context.  I understand that some organizations are built on process and structure. “My Agile” won’t work there and I recognize that and will take a different approach.  Other coaches, despite their personal bias, will do the same.   During one engagement in a highly political and process-heavy environment I beat a Director and Senior manager over the head with values and principles.  It didn’t get me fired but I did a dis-service to that client at that particular time in my career.  When they hired me to “go Agile” I let my personal bias of Agile get in the way of their success.  I am aware of that and have worked very hard to understand culture and people more so I can serve my clients more effectively now.

Above all else, get the phrase “we can’t do that because…” out of your vocabulary.  Agile is change and you would be foolish to expect to adopt Agile without changing your organization.  There’s a reason why Agile is rooted is 4 values and 12 principles.

If you are looking for an Agile Coach, the best thing you can do, in my opinion, is to get involved with the Agile community first.  You will learn a lot.  You will meet coaches.  You’ll be pointed to many books and resources that can help you figure out what you really want.

Finally, you need to be dedicated to making it work.  A coach will help you discover problems and will work with you to experiment with solutions, listen to them, decide on reasonable business outcomes that shape what success looks like and be ready for some bumps along the way.

From my experience, and from talking to other coaches and ‘Agile people’, we generally find that what these organizations are doing is iterative, not Agile.   More often than not I see organizations using Scrum, doing standups, 2 week sprints, demos and retrospectives but don’t behave differently than before they moved to Scrum.  Sometimes management hears that their teams are Agile but don’t see much  (or any) difference in outcomes.

How do you know if you’re iterative or Agile? Here’s some things to consider and some outcomes that may help you figure it out.

Keep in mind when I say “Iterative Teams” I am talking about teams who are “Agile in name only”.   Iterative development has been around for decades, these observations are based on my experiences with teams that call themselves Agile but don’t seem to get any benefit from using Agile practices.

Iterative Teams:

• Can experience testers being crammed at the end of the sprint because there is more clear and stricter enforcement of role-separation between programmers and testers.  This can also be called “mini-waterfall”.  Agile teams will experience this as well except the programmers will understand why it’s a good idea to help the testers and they’ll work at it to improve.
• Point blame when problems arise and say things like: “well, that’s what the PO wanted” or “Joe didn’t finish his story so we couldn’t do a demo”  IMO, this is a symptom of an iterative team that has the same organizational hierarchy and structure from their pre-”Agile” days.
• Tend to not deal with un-certainty as well as Agile teams.  You’ll hear things like “we need 2 weeks of research for this” instead of doing minimal planning and a skunk-works hack to learn more information about what’s involved with an un-known task or story
• Say the word “scope-creep” while Agile teams understand the sprint is supposed to start with an un-finished spec and accept changes because they understand that customers don’t know what they want until they see working software
• Say things like “the process is ….” while Agile teams understand a process is a guideline and software development isn’t like making toasters, which is to say it’s not a repeatable and linear process
• Are less likely to experiment with new techniques and practices because Agile may be seen more as a process thing whereas Agile teams will understand that building a learning culture yields great benefits.
• Find problems much later than Agile teams because of the mini-waterfall approach
• Have “hardening” sprints and struggle with the definition of done whereas Agile teams may have a hardening sprint in some occasions but they’ll understand that there is an underlying problem which is driving the need to have hardening sprints.
• Have recurring problems and bugs which leads to constant rework and possible thrashing compared to Agile teams who, upon finding a bug, will start with tests to catch it so it doesn’t come back later.
• Have a less sustainable pace compared to Agile teams.
• Can come up with retrospective improvements like “learn how to estimate better” or “plan better next time” with nothing tangible to do anything about it whereas Agile teams will go to meetups and read books to learn new techniques to experiment with to help solve those problems.  Agile teams will also understand there’s a deeper problem when this happens.

Is one better than the other?  I could say something fluffy like, well it depends on your context, but I won’t do that.  I’ve worked with Agile and iterative teams and the Agile teams I’ve worked with trump the iterative teams without a doubt.  The reasons are that Agile teams are open and transparent about the work they doing, challenges they have and they take responsibility when they mess something up.  And all teams mess up on occasion.  Agile teams have people who get actively involved in the Agile community by going to conferences and meetups on their own time, many of which pay for themselves.  Agile teams also understand that they are serving the customer, like talking to customers and are passionate about delivering great software.

Iterative teams like to blame “outside forces” for their problems, try to fix problems with more process, aren’t visible about their work  and for whatever reason don’t see the value in building a learning culture. I find that teams that fall into my “iterative team” description use Agile as a crutch because it sounds good.

So what can you do to make the jump from iterative to Agile?  That’s the million dollar question.   If you are passionate about being Agile but don’t feel your team is really getting what Agile is, you have options.  Find 1 person who seems to share your passion and work on showing the rest of team that things can be better by doing lunch and learns or working on side projects using different techniques you want to try at work.  Another option is to give up and find a better job with a team that shares your passion.   Another option is to latch on to a business person who isn’t happy with the teams outcome and work with them to come up with an improvement plan, whether that be hiring a coach or dialling back the work to give the team more slack to learn.

There are always options.  Some of those might work, some of those might not and the point is teams become great Agile teams by challenging the status quo and by not accepting things because of the way they are.

The first meeting was with a conservative client who we had been talking to for weeks as they asked 1000′s of questions about our product and our process for implementing it, supporting it etc.  All fair questions in my opinion, and some of those questions were “what happens if 500 people all do ‘feature x’ at the same time?“.     That told me they were more risk adverse and liked the perceived safety of well thought-out plan. They also got into some low-level details that I didn’t think mattered at this stage, but I was happy to indulge and answer their questions.

The second meeting was with a customer who is a lot like me.  Likes action, speaks her mind, doesn’t beat around the bush and moves very quickly.  She hand-drew the UI she wanted for her iPad app, emailed it to me and within 15 minutes we went through all 15 or so screens to finalize the flow and information we would display.

The third meeting was with a customer that we had recently launched an iPad app for.  We were starting phase 2 and were talking about some of the updates we had made to our platform.  This meeting was somewhere in between the other two.  We went into the right amount of detail, IMO, and wrapped up somewhere between the time the other two meetings took.

In all 3 meetings, we reached tangible action and in all 3 meetings I adjusted my tone and language for each situation.  In the second meeting, for example, I had no problem being blunt and direct because I knew that customer would appreciate that more.

I have a “process” for how I build our apps, what details I need from the customer and I adjust that based on the customers needs.  If they need more documentation for some reason, I’ll make it and re-use it for the next customer who requests it.  If they want to work with hand-drawn mockups, I’ll work with that.   If I feel managing them through the building process will be like herding cats, I’ll change my language and use phrases like “I’m concerned if we don’t decide on X we’ll risk missing the date you want the project live”.   I find that’s a helpful way to ground customers who are spinning off into ‘what ifs’.

As I was driving home from work I had an ‘aha’ moment from PSL about that day.  I remember near the end of PSL, Johanna Rothman had stuck around giving a few of us more advice about how to bring PSL back to work the following week.   We talked about how to use what we learned about types and temperaments as a way to understand ourselves more and how we intake and process information from other people.  MBTI isn’t a theory used to label people, it’s never about that other person, it’s about you.   I found that having an understanding of myself helped greatly in these meetings.  It also helped me ‘get a feel’ for how I could change my tone, messaging and questions I asked for each situation.  Never once did I try to get them to change in order to fit them into a process.

I believe what I described is pretty basic customer management and this translates to whatever software development process you use.   The first Agile Manifesto value is ‘Individuals and Interactions over Processes and Tools‘.  Use your process as a guide, not a set of rules that you can’t deviate from.  I remember consulting for a company that had been using Agile for years and I was shocked how many times I heard “we can’t, our process is…“.    You’ll build a great deal of trust with customers by having an adaptable process and that will make it easier to live by the other 3 values.

The key is to find balance, if you’re working on a feature that has many unknowns, plan more frequently and in smaller timeframes.   It  may sound counter-intuitive but in that case, you’ll want to plan less.  Sometimes you’ll need mockups or more detailed requirements, sometimes you might not need any at all.  Once you understand the process you are using, you’ll be knowledgable enough to break the rules, when it makes sense, and realize that software development isn’t a linear and repeatable process like building toasters on a manufacturing line.

This got me thinking about how important the Agile Mindset is to being more successful with Agile.  I pride myself on always asking questions and challenging the status quo, even in environments where that is perceived as “negativity”.  I don’t see it as negativity at all.  I see people who blindly follow process and priorities without questioning the motivation behind them to be far worse.  Now that’s not to say companies can’t be successful implementing some Agile processes, it simply means those rare organizations that really ‘get it’ will enjoy much greater success and enjoyment.   Your mileage may vary, some organizations cannot sustain a fast pace of change for a variety of reasons.  Other organizations will develop a learning culture or commitment to excellence.  This is the important part, there’s no ‘right way’ for all organizations.  Sometimes a strong status quo works best when loss of stability can lead to more problems.

I am skeptical of anyone who says something is impossible, especially in software.  The deeper problem in organizations that find too many things to be ‘impossible’, is that they have stopped trying and given into mediocrity.  In order to develop an Agile Mindset and to provide a more stimulating environment for employees which will drive better outcomes, teams and organizations need to learn how to solve problems and challenge the status quo.  Recently I was talking to a friend who challenged me by saying that sometimes there are external forces that you have no control of.  This was in context of a software problem with a 3rd party integration.

I responded with “There’s much more control you have over that type of situation than you think“.  My instinct was to immediately call BS on his statement.  Once you’ve convinced yourself that there’s nothing you can do, there’s nothing you can do.  You’ve decided on an easy way out and have a scapegoat.  Hey, it’s not us, it’s them, they’re system is broken.  While it’s much less mentally draining to deflect blame and absolve yourself of responsibility , I’m not buying it.  If you know your 3rd party dependancy can cause a problem in your system and you choose to do nothing about it, that’s your problem, not the 3rd party.  What’ll happen the next time it happens?  Believe me, it will.

The good news is that at some point there will be some event that creates a sense of urgency to change.  In one case, the CTO of company woke up wondering, in his words, “where the F**K is my $XX million dollars per year in engineering going?”  That created a sense of urgency to change.  The problem was, after 10 years of neglect, there is no quick fix and you are in for a long and messy road to recovery.  Every hack and workaround piled up over the years leaving the software in an extremely brittle state.

When I experience problems like these ones, I see possibilities for improvement.  Real possibilities for improvement because I have worked with, paired with and been trained by some of the best software people in the world.  Take the case of how Netflix uses Chaos Monkey.  Traditional wisdom says monitor your system and respond to failures.  Hence the advancement of the ‘hero‘ (the guy who fixes problems fast…yay! you did awesome!).  Chaos Monkey prevents those problems from happening in the first place.  What’s more valuable to you?

That’s one example, while talking to a colleague a few weeks back, he talked about how they created their own programming language to solve a problem with how their platform and client implementations work.  Another case of awesomeness was while I was working with a team in a large enterprise.  Our challenge was providing information to the trainers who trained 10′s of thousands of people on changes to a POS app.  They had developed end to end tests using Selenium to automate happy-path regression but also used these set of tests to take before and after screenshots so the trainer could easily see what changes happened.

These are only a few examples, the innovation and commitment to excellence in all these cases can from accepting a different mindset of possibilities based on taking on a problem head on.  The best part is that these solutions were in the context of solving a business problem.

I am grateful to the wonderful people I’ve worked with, trained from and met at conferences and meetups.  You are the people that have helped me develop a mindset of possibilities and I will specifically thank Gerry Kirk whom I’ve been getting personally coached by for the last few months.  Gerry helped me realize that I am not the type of person who will compromise my values and principles.  He helped me understand how far I’ve come in dedicating myself to learning and improving my skills.  Most importantly, Gerry has helped me foster a mindset of possibilities and as far as I’m concerned there is no greater gift I’ve received in my professional career than that.  Thank you.