New Year's Resolution: Kaizen!

If old acquaintance be forgot and never thought upon then you're not holding retrospectives correctly.

I've never been a fan of making New Year's Resolutions - their short life spans are clichéd for a reason. I've also been reading Scott Adam's new book "How to Fail at Almost Everything and Still Win Big", and one of the major themes in the book is that goals are for losers; winners use systems. This resonates with the Agile principle of continuous improvement through inspecting and adapting.

So my New Year's Resolution this year is not a goal, but truly a resolution. I resolve to exercise personal Kaizen. Continuous improvement has been a major part of my life for as long as I can remember, but it hasn't always carried the urgency associated with Kaizen. I'm going to experiment more so that I can fail more so that I can learn more. I'm going to schedule Introspectives (1-person Retrospectives) on a regular basis whereby I can challenge my own personal status quo.

I wouldn't be an Agile Coach if I didn't encourage each of you to adopt Kaizen as a New Year's resolution as well. If you don't like the commitment associated with that term, can you commit to trying it just for January? Each Friday in January, I challenge you to hold your own Introspective. Ask yourself what you did well and what you could have done better. You may have made good decisions, but did you make the best ones? Did you have an answer for each time you were asked "Why"?

I'll be sharing the results of my own Introspectives every Friday this year. What I share may not be comprehensive, seeing as how I don't have the time to write out all the context for my results, but I'll share as much as I can within reason. I'll also work hard to blog frequently between Introspectives in an attempt to get more of a dialogue going than I've been able to in the past.

If you decide to take on my challenge, please share your results with me. You can comment on my blog, message me on LinkedIn, or tweet me @MLCarey321. I'd love to see the effects of personal Kaizen in your life!

When NOT to Use Agile

When HealthCare.gov first rolled out, everyone experienced how terribly it was built. Many Agile enthusiasts cried out, “If only they had used Agile…!” We have since learned that HealthCare.gov used Scrum. It’s uncertain how superficial their adoption was. Michael Daconta has already done a great job describing their poor use of Agile methods in the GCN blog, and NPR has published findings from the McKinsley & Co. consultants who were brought on in March to do a progress report.

My focus here is not about the degree to which Agile was or was not properly used for HealthCare.gov. My focus is to debate under what circumstances, if any, Agile will not work. When would you NOT use Agile?
My assumptions for this debate are as follows:

1. Agile is any processes, practices, tools, and frameworks that comply with the Agile Manifesto and its 12 Principles.
2. In the spirit of healthy debate, I assume the audience to be open to the possibility of new and different ways of doing things. This applies particularly to both Agile skeptics and to those entrenched in a specific Agile approach.
3. The ideas in this discussion are not etched in stone. I encourage you to share your own ideas so we can learn and grow together.

Possible Agile Risks

I was recently invited to an introductory Agile presentation. The audience was Project Managers with varying Agile knowledge and experience. It facilitated a conversation for answering questions and resolving concerns around Agile adoption. About halfway through, there was a slide that had five “Possible Agile Risks”:

1. Business or management commitment
   • Agile requires an increased level of commitment from the business and IT management to be successful
2. Remote or distributed teams
   • Agile benefits from close collaboration on a consistent basis. Distributed teams pose a challenge in the effort to do this effectively
3. Remote product owners
   • The business must be consistently involved, so a remote product owner may be challenging to engage
4. Balance delivering new features with high-quality, sustainable code
   • Agile delivers new features frequently, but this should never come at the expense of creating low quality code
5. Team not provided adequate guidance as they implement Agile
   • Anything new will take time to get good at, it is important to supply the team with training and guidance so they can improve quickly

This disclaimer followed these risks: “These risks do not preclude teams from applying Agile; they just need to be addressed in the scenarios they are present.”

Before we get to my reaction, let’s walk through these risks. Let’s identify why they’re risky in an Agile environment.

Business or Management Commitment

A deep understanding of the business is essential to the success of the software that supports it. In Agile methodologies, this means a dedicated person who has a deep understanding of the customer’s needs, often called a “Product Owner”. Traditionally, this person is seen as “from the business side”. However, getting someone from the “business side” isn’t always possible and is, arguably, unnecessary.

In my area we have Business Analysts who understand the business needs. They are bilingual in business and IT speech. Our developers and testers have a deep business understanding of the business because they’ve been supporting it for a long time. Some Agile practitioners feel the Product Owner role is unnecessary; they believe the team should understand the customers’ needs better than anyone. The team can, therefore, manage the work themselves.

In Agile, management is not a clearly defined position. Managers may feel their job is threatened by a “self-managing” team. A manager must have the team’s best interests at heart. They must become Lean-Thinking Servant Leaders, not Command-and-Control Managers. This is a cultural shift from Waterfall. Agile teams without Servant Leader management will plateau until they are allowed to “self manage”. However, that doesn’t mean they can’t find some measure of success.

Remote or Distributed Teams

This is one of the first and most frequent challenges brought up when introducing Agile. A team is distributed when its members are not capable of frequent face-to-face conversation. Lack of co-location for an Agile team is a challenge, no question. However, modern tools such as IM-enabled ad-hoc video conferencing, digital code review tools, etc. make long-distance coordination much simpler. It may be hard to work out timing with time-zone differences, but it’s possible to have a time overlap for some real-time collaboration. This may result in having a tech lead that takes the brunt of the development’s complexity to reduce the need for collaboration among the other team members, though this will limit the team’s overall productivity.

Remote Product Owners

For this I say, “See my previous 2 sections.” However, perhaps there are situations where the team is new to the product? Perhaps the SMEs are remote? Even worse, what if those remote SMEs do not dedicate time to work with the development team? Wait, what on earth are you thinking? Seriously, this is a bad idea, regardless of methodology. You are stacking the deck against yourself and setting the team up to fail.

Balance New Features with Quality Code

One of the 12 Agile Principles states, “Continuous attention to technical excellence and good design enhances agility.” Delivering new features at the expense of quality is the technical equivalent of being “penny wise, pound foolish”. This may be faster short-term, but the long-term consequences are a slow-down of delivery. Without addressing the quality of the application, it will eventually be cheaper to replace the application than to fix it. This isn’t unique to Agile. This brings me to my initial reaction to ‘Possible Agile Risks’.

My reaction to "Possible Agile Risks"

When I first saw this list, my reaction was that the first four are not “Possible Agile Risks”. Instead, they are “Possible Software Development Risks”! The four risks of commitment, distributed teams, remote product owners, and quality are often associated with Agile development because Agile brings risks to light early. Agile makes it much more painful to ignore risks than to address them. They are not less risky with non-Agile approaches. In fact, the realization of these risks is more likely in a non-Agile approach. In Waterfall projects, risks manifest so late in the process that they are painful and expensive to fix. The first four are risks to all projects; but not necessarily the fifth and final risk on the list.

Agile Training and Guidance

Without proper training and guidance, it is difficult for those unfamiliar with the Agile paradigm to be successful with an Agile approach. Most people new to Software Development find the Agile way of thinking to be a more intuitive and human-centered. In those cases, there is less risk because less training is needed.

Those entrenched with Waterfall approaches will find it difficult to switch gears. This is the only risk I could concede as being a “Potential Agile Risk”.

Where’s the Risk?

So there are my thoughts on five risks commonly thought to make Agile less successful. I have yet to find a risk that is made any less risky by Waterfall. Does that mean Agile’s guaranteed to succeed? Absolutely not. In fact, Agile will push you to your limits. Then, right as you’re starting to feel comfortable, it pushes you some more. However, Agile will consequently turn your team into the best team they can be. Agile will expose risks and inefficiencies sooner. It will also make them more painful. As long as you don’t ignore the pain, taking care of those risks and inefficiencies will be less expensive because they are dealt with early.

But hey, maybe I’m wrong. What risks have you heard associated with Agile? What situations are wholly inappropriate for the basic tenants of the Agile Manifesto?

Agile Complements

I was recently asked to explain the relationship between Agile and Innovation. I was intrigued by the question as I've never really tied the two together. In thinking about it, I've concluded that Agile complements many things, but it doesn't necessarily drive any of them.

The Role of Practices

The Agile Manifesto clearly states that one who considers themselves Agile values "Individuals and Interactions over Processes and Tools". However, we know that there is some value inherent in Processes and Tools, primarily in the behaviors that they reinforce. Given it's popularity, let's take Scrum as an example. Scrum has a highly prescriptive process that still manages to leave a lot up to the team. Sprint Planning reinforces commitments and transparency; the Daily Scrum reinforces face-to-face communication and self-managing teams; Sprint Reviews reinforce feedback loops within the team, as well as with stakeholders and customers; Sprint Retrospectives reinforce continuous improvement; the Sprints themselves reinforce small time-boxes; and on and on and on.

If you want to reinforce something positive at work, whether it be innovation, elimination of waste, any of the items listed below, or pretty much anything else, you can find an Agile process, tool, or practice that will reinforce it. With Innovation, you can take the practices of Capacity Allocation and Spikes to explicitly include time and effort for innovation into your process. This is assuming we're talking about developing innovative things, in addition to a Retrospective or other feedback mechanism for innovating the process and team themselves.

However, it is possible - and happens all too frequently - that teams adopt these processes, tools, and practices superficially, thus obtaining little, if any, of the intended benefit. In order to effectively reinforce behaviors, those behaviors have to already exist as part of your culture.

The Role of Culture

I've blogged multiple times about the difference between doing Agile things and "Being Agile" ("Agile: The Book vs. The Movie", "Understanding the 'Why?'", "Descriptive versus Prescriptive", "I Madge I'll - Agile Posers", etc). To deliver the best results possible, your team has to be Agile - they can't just superficially adopt an Agile implementation. When asked to explain Agile, they should go to the manifesto first and the day-to-day second. At the risk of getting too theological, Agility is a state of being and influences all aspects of a person's life (at least at work). Simply put, you have to establish a culture of Agility, where the principles are embedded in your company's DNA.

The same is true of Innovation or anything else. When people think of innovative companies they think of companies that have a culture of Innovation. Innovating isn't something you do as much as it's part of who you are. Of course their processes, tools, and practices reinforce Innovation, but that's a byproduct of something deeper.

As I said before, you can use tools from the Agile toolbox to help drive Innovation, but it can't just be lip service. If your company was built on Innovation (and it probably was) then get back to your roots and tell that story; remind people where they came from. Make Innovating seem natural, like coming home and eating comfort food.

No Silver Bullet

I'm going to be going more in-depth in the coming months on the idea that no one Agile implementation should be seen as a Silver Bullet. Before you implement anything, ask yourself "Why?"; what result or behavior are you hoping to get from it? Understand that different Agile processes, practices, and tools have their own strengths and weaknesses. Sometimes you'll have to blend different solutions to make something new that fits your needs. Sometimes you'll have to invent something that hasn't been done before. Most importantly, you will always have to examine what you're doing and ask what you need to change to be better. Keep the mantra "Never Perfect; Always Better".

Can Agile help drive Innovation? Sure. But some approaches will do that better than others. Begin with the end in mind, but remember that this is a journey and you don't know what you don't know. Be willing to adapt, but don't lose sight of your vision. If it sounds hard, that's because it is; if this were easy then we wouldn't be having this conversation!

What do you think?

Seriously, what do you think? Please tell me! I really don't like the "thought leader in a vacuum" setup. What I've shared here is the result of my learning and experience, but I recognize I don't know everything. I crave the perspectives of others. I want your insights, suggestions, criticisms, reinforcements - all of it. Leave a comment or tweet me @MLCarey321.

The Best Lesson I Learned the Hard Way

Let me preface this by saying I do not recommend learning lessons the hard way. There's a wealth of human experience out there to learn from before you go off and make the same bone-headed mistakes. However, bone-headed mistakes will be made regardless of how cautious you are. In those cases, please go into it with a Fail-Fast, Kaizen mindset so that the mistake becomes a short-lived learning experience.

The Almighty PM

I've made a lot of mistakes in life, which means I've learned a lot of lessons “the hard way”. The one such lesson that has had the most impact on my current work life took place my senior year of college. I was in a capstone class where we were to organize ourselves into a real software team to develop a real-life application on top of a new API that we had Beta access to. We were given a little guidance, including how previous classes and many companies organize themselves, but told we could do whatever we wanted. We ended up with a very “traditional” model of a few Dev teams, a few Testing teams, an Architect, and the one Project Manager to rule them all.

I was eager to prove myself, so I went for the PM position (oddly enough, I didn't really have any competition from my obviously more self-aware classmates). The problem is Computer Science majors in their fourth (okay sixth) year of study haven't usually had any PM classes or experience. My architect laid out the architecture, lots of open source Java, wikis, subversion, etc, and the class was excited to get started. However, I was concerned about how to manage the work, as well as expectations. I started demanding individual Gantt charts up-front for the duration of the semester. I was asking each team lead to compile the Gantt for their team and report that to me so I could put it all together.

The Blind Leading the Competent

Basically, I was trying to command-and-control manage a team of part-time team members, all of whom were taking at least 12 hours that semester and had limited time to spend on this class. Of that limited time, I was asking an unreasonable amount of time on administrative work. My architect was an excellent “Yes Man”, which made it difficult for me to see what I was doing wrong. The tipping point came when we weren't getting the information we were asking for from the teams and we were way behind where we expected to be on the application. Our professor was pulled away for a class and gave me the option of keeping the class time or giving everyone the day off. My architect decided, with my blessing, to use that time to express our mutual disappointment with the team and shame them into getting their act together.

I knew it was all over when the architect started his oratory with something to the effect of “By the time I finish talking you should all be mad at me, and that's okay because I'm mad at you.” It was a horrible hour and ended with our organization in shambles. I was a broken, broken man who was certain I was going to fail the class.

A Lesson in Servant Leadership

Then one of the testing team leads asked if he could meet with me to talk through things. He kindly and patiently explained why what we did was so stupid and counter-productive. He told me that the teams needed a cheerleader, not a dictator. He asked me to spend time with the individuals on the teams. He wanted me to spend more time in face-to-face conversations instead of mass emails. He wanted me to understand how hard the class was working to accomplish a common goal so that I would stop wasting their time with unnecessary busy work. He wanted me to focus on listening and removing roadblocks. He is now, unsurprisingly, a manager at Amazon, and someone I still hold in high regard.

I didn't fail the class because the objective of the class wasn't to develop a fixed scope within fixed time and budget. My wise professor wanted us to experience real-world project work as best we could in an academic setting and learn from it. He saw me try to turn things around at the end and knew that I had seen the error of my ways. He knew that I had learned my lesson, albeit the hard way.

Lesson Learned

So what lesson did I learn? To be honest, I initially thought that the lesson I was supposed to learn was that I suck at Project Management. I could not be trusted with leading a project to completion. I could code well and kinda sorta test, but the realm of Project Management was beyond my grasp.

This lesson was reinforced when I entered the workforce a few months later and saw command-and-control PMs leading projects “correctly”. These were professionals who did not go on rants against their developers and testers. They were not perfect, but they did their best to make things work in alignment with the command-and-control, iron triangle, Waterfall-driven style they were trained to use. Despite their best efforts, I found myself in War Rooms quite frequently, and my wife learned to not expect to see me in the months surrounding a Production install. I didn't realize it at the time, but I was living through the hell that I had just put my classmates through.

Of course, that wasn't the PM's fault. As I said, they were doing the best they could, and we were doing the best we could. The problems were much deeper than any one individual. We had to change the way we work, starting by not only recognizing but emphasizing the human element of software development.

The real lesson is that command-and-control Project Management doesn't work. Had I taken the time to understand Lean/Agile development processes and practices, I could have done a decent job as a Scrum Master or Agile Servant Leader in my capstone class. I might have even done some coding and testing alongside my cross-functional Agile development team(s). Even before I learned that lesson, I learned the importance of being a cheerleader. I have always striven to let the teams I've worked with know what a great job they're doing and how much I appreciate them. I haven't always succeeded, but that pep talk I received my final year of college never left me.

Once I realized that what I was experiencing in corporate life was essentially the same as that capstone class, I vowed to change things. I delved into the world of Lean and Agile and brought the things I learned back to my area. To many people it looks like I've picked it up extremely quickly; in reality, I've been learning this lesson for at least six years. If anything, I'm ashamed it took this long to finally “click”.

Muscle Memory vs. Muscle Confusion

The most popular Agile methodology in practice today is Scrum, which relies heavily on ceremonies. Any decent Agile coach working with a new Scrum team will drill these ceremonies into them in an effort to get the most out of the framework. They drive cadence, alignment, continuous improvement, transparency, etc. One of the big benefits of doing this is that it becomes a part of their routine. They no longer have to figure out how they're going to align on a daily basis; plan their work; communicate with their customer; inspect and adapt; etc. All of those things are "baked in" to the framework. Because there's so little prescribed, it's easy to pick up and repeat forever. By making those things rote, you develop a sort of Agile "muscle memory".

Wax on, wax off, stand up for 15 minutes

Muscle memory is a condition where a task is repeated so frequently that it can be performed unconsciously. Just think of Mr. Miagi and Daniel-san in The Karate Kid. Mr. Miagi had a lot of landscaping work to be done, and Daniel wanted to learn Karate. As luck would have it, the motions required of a Karate black belt are the same as sanding decks, staining fences, and washing cars - who knew? Right as Daniel is ready to throw in the towel, Mr. Miagi attacks him Daniel's muscle memory kicks in to save himself from being pounded by a Karate master. Likewise, those Scrum ceremonies become reflexive and help new Agile practitioners focus on the hard task of developing new software instead of thinking about how they're going to go about "Being Agile".

However, too much of a good thing can be bad. Once that muscle memory kicks in, it makes it harder for our Agile "muscles" to grow. The body has optimized how to do the repetitive thing, and doing it more doesn't really result in any added strength. This is a problem that strength trainers and body builders are familiar with. Your workout routine can't be too routine or you'll plateau. You have to introduce what's called "muscle confusion".

Muscle confusion is the concept of varying the types of exercises you do, as well as the number of sets and reps of those exercises, to avoid muscle memory and keep building muscle by tearing it and letting it repair stronger. If muscle memory kicks in then it becomes harder to tear the muscles. You see this concept manifest in workout regimens such as P90X and Cross Fit. One of the difficult things to get right, though, is the right amount of muscle confusion. Switching 100% of your exercises 100% of the time won't get you optimal performance.

I liken muscle confusion to a Kaizen mindset in Agile. You have to have an urgency about change, but it has to be small, incremental change in order to be effective. Change too little and muscle memory sets in - boring scrums, useless retros, tedious planning, etc. Change too much and the disruption causes everything to start falling apart.

P90X and Cross Fit are not for everyone. You will have to determine as a team how much change you can handle on a sprint by sprint basis. Some will change almost daily, others will be lucky to successfully adapt on one thing per sprint. As long as you're being honest with yourselves, that's fine. Just beware of muscle memory and muscle confusion. Optimize the change, and there are no limits to how much you can grow your Agile strength.

Caution: Spikes

                Several misconceptions exist around the concept of a spike in Agile Development.  Spikes are an essential part of the development cycle but are inevitably either over- or under-used due to a failure to understand why we create spikes.  Hopefully I can help shed some light on how to use spikes to best drive business value and when to eschew them in favor of directly driving business value through stories.

                Taken from the Scaled Agile Framework website (www.scaledagileframwork.com): “the purpose of a spike is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate”.  So that seems fairly straightforward, right?  Unfortunately, due to the nature of human language, different people draw very different conclusions from the same source, taking a fairly simple, direct statement and completely misrepresenting it in ways the author never dreamed of.

                Let’s take the last two parts of that statement first: “better understand a requirement” and “increase the reliability of a story estimate”.  This means that if a team comes across a story that has so many unknowns they can’t accurately provide an estimate for the story, then a spike is in order to perform some research to determine how to best tackle the story.  This research may mean meeting with the end users to get more in-depth knowledge of the business process involved, meeting with other developers to determine the best way to implement a solution, working through external dependencies with other teams or many other activities too numerous to list here.  Performing this research will provide a better understanding of the given acceptance criteria, thereby raising the comfort level of the scrum team.  So how is this one botched?  Developers get spike-happy.   It is not uncommon for developers to become uncomfortable even with small levels of uncertainty and create spikes unnecessarily clogging up the backlog.  As a general rule of thumb, if you are creating a spike for an hour or two worth of research, it is probably not necessary to create that spike.

                Climbing further down this particular rabbit-hole, one must ask the question, “Why does it matter how many spikes I create if it helps make the story more accurate?”  The answer to this question is alluded to in the title of this article.  Customers do not care about spikes.  A spike by its nature delivers no business value and is generally throwaway if anything is actually developed during it.  As a result, it is important to minimize the spikes created unless necessary. 

When faced with uncertainty, the team must assess the level of unknowns in the story and make a determination.  Create a spike?  Perhaps increase the story points a little to account for some possible research needed?  Locate an SME on the story in order to provide feedback on the complexity of the story while pointing it?  The last option is preferable as it eliminates the unknowns immediately and gives the team a reasonable comfort level while actually pointing the story.  In this instance, it is important to be proactive and make sure that SME is invited to the discussion of the story or consulted with beforehand.  The second option of buffering the story points is not the optimal solution but is still preferable to creating a spike since most likely both the spike and story will not be completed in the same sprint.  This delays business value delivery to the customer.  On the downside, it still increases the size of the story, potentially making it too large to be taken in the preferred sprint.

Moving on to the first part of the definition of a spike (in case you’ve forgotten already, “gain the knowledge necessary to reduce the risk of a technical approach”), a spike may be created if a new technology has been decided on and some research or a proof of concept (POC) may be needed in order to proceed forward with development on the stories in question.  I have observed a couple of key pitfalls when dealing with this particular kind of spike that should be avoided if the spike is to be effective in the long-term. 

The first pitfall when dealing with POCs is the failure to time-box it properly.  A POC is throwaway by nature.  Please do not spend more time on it than necessary before completing the story.  Specify a time-box beforehand when planning the spike and ensure that once that time-box is met, the story that initiated the spike is revisited (Many sources recommend specifying the time-box in days or even hours to ensure that the developers involved are actively keeping track of the spike’s time).  If at that point, too many unknowns still remain in order to point the story, then another spike may be needed.  It is critical that the spike is kept as short as possible since again, no business value is being delivered.  That time-box is important because developers typically like to develop (go figure…) and may want to get that POC completely working.  Guess what?  That POC is junk.  Throw it away once you’ve gotten what you need from it and work on something the business cares about.

This leads me to the second pitfall.  Don’t turn the POC into the story.  If the developer starts actually coding the story, then why are we doing a spike?  This is risky for a couple of reasons.  For one, typically POCs are very short-lived and ad-hoc, leading to coding them with looser standards than we might have for our flagship applications.  If the POC starts to turn into the actual application, there are likely some bad habits that do not need to be carried forth.  Another concern with mutating a POC into story is hidden in intrinsic idea that we are in agile development and as such, things change.  The developer runs the risk of working on an actual story, integrating into the environment, and then ultimately undoing it when priorities shift or the technology being used doesn’t pan out.  And I haven’t met a developer yet that loves rework.  If you are still trying to decide what color to paint your house, you are probably not going to just start painting the front of your house with the first color you find that you sort of like the look of, right?   The important thing to remember with POCs is to keep them simple and keep them focused on the key unknowns that are being solved for.  Your POC does not need to adhere to all coding standards.  It does not need to have a full suite of J-Units.  It does not need to look pretty.  Heck, it really doesn’t even have to completely work, as long as you’ve gotten what you need out of it. 

In summary, spikes are absolutely important when used properly but are easily abused.  A good rule of thumb is not to spend more than a day or two on a spike unless you are dealing with a large number of complex unknowns in which you may have a few spikes to deal with.  Use your best judgment and remember than your customer does not care about these spikes.  Treat them like the begrudging necessity that they are and not as your top tool in the tackle box.

I Madge I'll - Agile Posers

When I meet someone who wants to talk about Agile I start by asking, "What do you know about Agile?" Most of the time I begin to hear those key buzzwords the newly indoctrinated are so proud to spout off: "It's where, instead of Waterfall," said with a grin and a wink, "your scrum has sprints and they stand up and there's no requirements and you demo and it's amazing!" I often think to myself, "Seriously? Why do these people think this?" So recently I decided to apply Occam's Razor and ask what the simplest answer is. My conclusion? Somebody told them this.

Consultant Speak*

Okay, so I don't think anyone told them something quite so incoherent as what I put, but they definitely started out with 1) a specific methodology in mind, almost certainly Scrum, and 2) an unholy amount of buzzwords and Agile vocabulary to accentuate just how different Agile is from the dreaded Waterfall. I get it - you're probably (relatively) new to Scrum and you're super excited about it and want the whole world to know how it changed your life. Unless, of course, you're a consultant who's trying to confuse a potential client into throwing money at you to turn their IT shop around. Tsk, tsk.

"...It's Not What You SAY, It's What You HEAR!"

The problem is these people don't know what Agile is. They don't fully understand what it is they're saying. All they know is that if they keep saying certain words with enough conviction then people will think they know what they're talking about. It reminds me of the game "Mad Gab". In case you're not familiar, players in the game read words on a card that don't really make any sense. They're not supposed to. The words on the cards, said with the correct inflection and pacing, are supposed to sound just like a commonplace phrase that your team is trying to guess. For example, these new, hopeful, and largely ignorant future Agilists are saying "I Madge I'll" in hopes that you'll hear "I'm Agile"! The problem is they aren't.

Agile Posers

I was recently working with a fellow Agile Coach (I know, I don't care for the term, either, but I'm not sure what else to call him) and we were collaboratively taking notes via Google Docs. On occasion we would have an impromptu discussion in the document due to a tangent that our notes took us on. One such tangential conversation was about Agile Posers. It went a little something like this:

"‘how to spot an agile poser’ (consultant-speak?)

1.one who pretends to be someone who's not. 2. who tries to fit in but with exaggeration
urban dictionaryl33t speakpwned you, you poser

'5. Someone whos acts like someone they’re not,but not realizing that there being fake, basically a loser trying to fit in.' - UrbanDictionary.com

'6. A poser is someone who tries hard to be something they arent. Usually, posers call other people posers because they are jealous that the person they called a poser is more skater/stoner/goth/punk/rocker/grunge/Agile/etc. than they will ever be.' - UrbanDictionary.com

posers often fool themselves first.  they aren't always (deliberately) not

ask probing questions.  why do you like it, what was good, test their belief."

On the off-chance any of my readers are Trekkies...

Our conversation went on to include things such as mining for conflict and Open Space sessions as means to help draw out and coach Agile posers. Take another look at definition #5. These are the people I'm talking about here. Those who want to be Agile, who hear about it and crave to belong. They'll ask anyone who claims to be Agile what that means and they'll cling to whatever they're told. So what's the take-away here? Tell them the right thing!

Being Agile vs. Doing Scrum

When people ask me what Agile is, I always go to the Manifesto and backing Principles first. I emphasize over and again that Agile is a way of thinking, a paradigm, a perspective, an approach. Yes, there are implementations and yes, Scrum is the most popular by far and yes, there are those who will tell you that the definition of Agile is Scrum. I'm here to tell you that it's not.

So what's the harm in people thinking Agile is just Scrum? Scrum's not all that bad. Of course it's not. I love Scrum, it's helped my organization tremendously. The problem with believing that Agile is just Scrum is it sends you on a quest to be the best implementer of a set of practices. Your Retros will eventually dry up because you can't get any more Scrum-like. But you'll keep doing them because "that's Scrum." You have to understand why Scrum is set up the way it is. Why you're asked to perform certain ceremonies. You have to know in what direction to Adapt when you Inspect in your Retros. And, most importantly, you have to be willing to break the rules like an artist once you've mastered them. You have to be willing to try things that are not in the Scrum Guide. You need Kaizen!

I'm Right!.. Am I Right?

As per usual, I don't have much to go on here other than my experiences and the stories I hear from others. So I want to know: What does being an "Agile Poser" mean to you? Have you experienced those "Mad Gab" Agile enthusiasts? Have I hit the mark on being Agile versus doing Scrum, or am I way off base? I want to know what you think, and I want to use your ideas to make myself better (being completely transparent here). Please leave a comment or shoot me a message on LinkedIn. I'd love to hear from you.



* I received some feedback that this post was offensive to consultants. I would like to clarify that I am not trying to group all consultants together and say that they are all this way. I am basing this on conversations I've had with people who were introduced to Agile by these types of consultants; observations from a friend who is a former consultant; and my first-hand experience with sub-par consultants. I know there are amazing consultants out there - I've met them, too, and admire the work they do - but there are an alarming number of consultants out there who do fit this bill.

Descriptive versus Prescriptive

“Imposing an agile process from the outside strips the team of the self-determination which is at the heart of agile thinking.” -Martin Fowler, Agile Manifesto signatory, from his October 2006 blog post, “Agile Imposition”

As a member of the SAFe community, I've heard and experienced a lot of concern and displeasure with what is perceived as a highly prescriptive Agile framework. However, having actually met and worked with Dean, Colin, and Alex, I have never felt they were trying to shove a framework down my throat. To me it felt more like "your organization is new to Agile and we come with decades of experience; try this framework on, including all of these recommended practices, see how it fits, then tailor it accordingly." Granted, that vibe came from face-to-face conversations, not websites and white papers.

This problem is not unique to SAFe. Pure Agilists have always pushed for a more "hands-off" approach. It's interesting to me how married some of agilists become to a certain methodology - conversations with these people usually boil down to "you should let people do whatever they want, but if you're a good coach and they really get the principles then they're most likely going to go with my favorite methodology." This is often coupled with, "I also offer Agile Coaching services..." The problem is, they've got a point about the coaching. You can't leave teams all to themselves; you have to support them somehow. I'm not saying all Agile teams need a dedicated Agile Coach, but they need the resources necessary to ensure the direction in which they adapt is in accordance with Agile principles and the environment that will support them when (not if) they fail.

Many of my thoughts on this subject have recently been affected by the information I was recently exposed to at OpenAgileAdoption.com. One of the references cited is Martin Fowler's "Agile Imposition" - an article written nearly seven years ago and more relevant now than ever before. Of course, Fowler and Open Agile Adoption are both focused more on organizational transformation than prescriptive frameworks, but I think the principles still apply. It all boils down to enacting change through influence but without mandate. It's a principle that every good Scrum Master is already familiar with - Servant Leadership. You've got to not only lead the horse to water but get them to realize just how parched they are!

So how do you do this within the context of a framework? My opinion: change the way you say what you're trying to say. More specifically, make it clear why you recommend certain practices, when they're relevant and highly likely to improve results, and when it might make sense to try something else. You're still going to lay out the recommended practices, but you'll be taking a descriptive approach to explaining them rather than a prescriptive approach.

The Scrum Alliance uses the term "Common Practices" instead of "Best Practices" to describe what would traditionally be considered "Best Practices". By changing the term they change the reader's perception. They're not saying "you need to do this or you can't be considered among the 'best'"; they're saying "this is something that a lot of people do in this situation, and here's why." That's the approach the entire industry needs to be taking. I would bet that many framework authors already think that way. The problem is that way of thinking is not reflected in their writings.

What do you think? Does this resonate, or am I way off base? How would you expect websites and other communication regarding what are typically seen as "prescriptive frameworks" to change to be more in line with a descriptive approach?

Respectfully Real Guest Blogger

"Respect for the Individual is a part of my company’s culture and a huge part of my personal belief structure. When I was a kid and would get in a fight with my siblings my parents usually took the 'stop your fighting now; kiss and make up' approach. So, as I grew up and entered High School, University, and the workforce, that was the approach I would most often take; if I saw conflict arise I would encourage the parties involved to stop fighting and 'kiss and make up', as it were. What I've come to understand as a Scrum Master and Agile Coach is that conflict is not always a bad thing. In fact, in order for self-organized teams to reach their fullest potential, conflict is necessary."

Hopefully that piqued your interest enough to want to read the rest. However, I'm not going to publish the full post here - this is a snippet of the post I published as a guest blog on AgileYammering.com. AgileYammering.com is a great blog that's primarily authored by two people, Ed Wehr and Valerie Santillo. Valerie is the blog's creator and a friend of mine that I met in D.C. when I got my SAFe Program Consultant certification. Hopefully you'll not only check out the rest of my blog post but read the wealth of information made available there by Valerie, Ed, and others. Enjoy!

Titles

I work for a company that is predominantly (for the time being, anyhow) NOT Agile. As a person who is passionate about Agile and leads one of three areas in his Division that are all-Agile, this wreaks havoc on my job title. Technically, my job title is "Systems Analyst". But I'm not that. That doesn't describe what I do at all, really. Maybe if you use "System" to refer to a team of people, as in Lyssa Adkins and Michael Spayd's teachings. However, that's not what the title is meant to refer to internally. So I'm stuck with the dilemma of how I describe who I am and what I do for the company.

Okay, I know I started this post out on a somewhat pessimistic note, but I have to be honest: coming up with my own job title has been fun. It's rather liberating to just make something cool-sounding up when you are asked what you do. One example of this is my LinkedIn profile, where I brand myself as a "SAFe RTE, Agile Evangelist, and Scrum Ninja". What does that mean? Exactly what it sounds like. I've also referred to myself as a Defender of the Agile Brand; Agile Enthusiast; Head of the Walmart Agile User Group (which isn't so much silly, as I really did found and lead the Walmart Agile User Group); and Über Scrum Master (I really like that one because the Ü looks like a ridiculously happy face). I also have a whole slough of non-Agile titles that describe me outside of my professional life, such as Dad, Brother, Son, Captain Obvious, and Snarky McSarcasticson.

Titles are a funny thing because they define so much of who we are, whether we want them to or not. In some cases, such as my "Systems Analyst" title, that can be a bad thing (read more about the cons of titles here). Yet I wouldn't refer to myself as anti-titles. I consider myself a proponent of creative, descriptive, and self-appointed titles. Your title should be part of your brand. If you don't live up to your title then it quickly becomes apparent and does you more harm than good, so it's in your best interest not to pick something entirely inappropriate.

What do you think? Are you a fan of titles? If so, what titles do you hold? If not, how do you describe yourself succinctly when asked what you do?