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?

Understanding the “Why?”

"Would you tell me, please, which way I ought to go from here?"
"That depends a good deal on where you want to get to," said the Cat.
"I don't much care where –" said Alice.
"Then it doesn't matter which way you go," said the Cat.
"– so long as I get somewhere," Alice added as an explanation.
"Oh, you're sure to do that," said the Cat, "if you only walk long enough."

I've written a couple of blog posts on understanding the principles of Agile, the “book version”, as it were, in order to achieve the success that is associated with Agile. If you've been in the Agile arena for any significant amount of time, you know there are a lot of disagreements as to the “How” of Agile. There are many different methodologies, frameworks, tools, and practices out there to support Agile teams. Some believe this is because people simply disagree on how to best implement Agile and, in some cases, this is true. Others understand Agile was never intended to be “One Size Fits All”. There are many options because there are many teams and each team must determine what solution works best for them – and evolve that solution over time in the spirit of Continuous Improvement.

This means you cannot determine “How” you want to implement Agile until you understand the needs of the team. “We need to have a Daily Scrum.” Why? If you can’t answer this then it’s not going to bring as much benefit as it should. If you understand the Daily Scrum as a touch-point to align across team members; identify risks and dependencies the team is encountering; and jump-start communication that will occur throughout the day then it becomes a stale and stagnant status update meeting.

My recommendation to Agile teams, and all human beings for that matter, is to not adopt something without understanding the “Why?” behind it. True Agile teams do not do things for the sake of doing them. They do them for a reason and nothing is sacred; if a tool or practice outlives its usefulness then it must be “put out to pasture” so as to not get in the way of the team’s continued growth. By regularly re-evaluating the usefulness of your current implementation, you also get the benefit of being open to new things. No matter how good your team is, they will never be as good as the team they could be.

People vs. Process ... vs. Principles

“Be firm on principle but flexible on method.”

-- Zig Ziglar

Until recently, I have observed the difficulties and issues manifested in the work environment and debated, both with myself and with peers, whether the root cause was the people being unskilled or unmotivated or the lack of a quality process. It was not until recently that I have come to realize that it is the founding principles on which we operate that makes the biggest difference in how successful we are.

When debating people versus process, the argument for people is that good people seem capable of producing amazing results regardless of process. However, I’ve seen great people time and again be suppressed by poor process, being forced into inefficiency for the sake of policy. In grass-roots meetings and informal conversations, both within my company and in conversations with others across the industry, I hear complaints of red tape, write-only documents, and wasteful tools and bureaucracy that dishearten and discourage talented people. At best, people are being forced to work below their capabilities. At worst, people are lost to another company that doesn’t include such roadblocks.

On the other hand, a good process can, ideally, bring a team to a hyper-performing state quickly and keep them there, while poor processes seem to only be good for shielding people from the ugly truth. Processes, policies, methodologies, and frameworks that emphasize value and seek to eliminate waste tend to bring out the best in people. The downside is that the best processes expose weaknesses within the team and force them to confront their demons. If the problem is the people are not skilled or committed enough then they may not be willing to put in the effort required to get the team to where they need to be. The best case scenario is the team members who are unwilling to change leave to free up the rest of the team to reach their potential, while the worst case is they stay and cause the team to drag and stagnate.

Neither of these seems to get to root cause, so let us consider the principles that form the foundation for people’s decisions and behaviors. When considering founding principles as the root cause, it is necessary to start with two assumptions. The first is that the people doing the work are genuinely doing the best they can with what they have. It may be somewhat altruistic, but I believe it is true for most people. The next assumption is that these same people are working with a process and in an environment that allows for and even encourages continuous improvement. Whether it’s explicit or not, people tend to adapt the way they work over time, based on their experiences and their guiding principles.

If my assumptions hold true, and my experience tells me they do, then those guiding principles that determine in which direction the process evolves are the most important factor in driving productivity, efficiency, and morale. The founders of the Agile Manifesto understood this. They came from various backgrounds exercising various forms of what are now considered Agile Methodologies. They did not define any specific process for success – instead, they defined a mindset, a paradigm, for approaching Software Development. They backed this manifesto with 12 principles, only one of which pertains to the type of people that are needed to be successful:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

The only qualification they state is that the individuals be motivated. Surely some people are inherently more driven than others, but, for the most part, motivation is something that can be fostered by the culture and environment that the individual is operating in. The other 11 principles provide great insight into how those people should work as well as what should be done to support those people in their pursuit of high quality Software Delivery. If people have learned and accepted these principles then they will recognize how important and urgent it is for them to improve individually, not just as a team. It is not a character flaw to admit imperfection – indeed; it is the manifestation of character that one can admit to room for improvement.

The Agile Manifesto is not the only source of correct principles. There are many books and courses in existence that focus on this very subject. The whole premise of Lean Six Sigma is there are solid principles that can be applied in any situation to eliminate waste and reduce delay. I think Lean, Agile, and Product Development Flow principles are the most crucial to our combined success, but I recognize that there are others. What I would like for you to ask yourself is, “What are my guiding principles? When things get uncomfortable, how do I evolve the way I work?”

Why is this important? Because too often we pick up a new process hoping it will be our Silver Bullet, the solution for all our problems, the answer to all our prayers. But we adopt these processes without taking the time to understand the principles on which they were founded. As a result, we bend the process to fit what we are comfortable with and lose much, if not all, of the benefit the process could have afforded us. This mistake of adopting a process without adopting its defining principles is what I’ve referred to previously as the “Movie Version” of that process as opposed to the “Book Version”, and the book is always better than the movie.

Only by taking the time to understand correct principles will we be able to govern ourselves most effectively. As Blaine Lee said, “The principles you live by create the world you live in; if you change the principles you live by, you will change your world.”

Bottlenecks: the Enemy of Agility

I am the Release Train Engineer for one of my company’s first Release Trains. One of my early struggles when we first adopted the Scaled Agile Framework was understanding what the responsibility of the System Team was and how to concisely articulate it to others. That understanding finally came during the Quick Start event where I heard Alex Yakyma say the System Team identifies, manages, and eliminates bottlenecks. What a powerfully simple mission! I’ve since dedicated time to understanding and helping the team understand what that means, and this is what I’ve come up with so far.

First, how do you identify a bottleneck and what does it mean to be a bottleneck? Sometimes this can be rather obvious, but often it is difficult to separate the symptoms from the root cause. This can be a process, practice, culture, etc. I have come up with a process to help myself and my System Team identify bottlenecks.

First, envision what it would be like if we could deploy to Production a dozen or more times per day. Not that we would, necessarily, but what would it take to be able to roll new functionality to Production the same day we get the request? Second, document our current process and lead time from conception to Production. Third, identify the gaps between our current process and the ideal of Continuous Delivery.

If you find yourself defining symptoms and not the root cause, start using a Lean perspective and start asking “Why?” For example:

“It takes too long to get a package to Production once it’s been approved.”
“Why?” “Because we have to find someone who has the bandwidth to get it deployed.”
“Why?” “Because we do not have an automated deploy process in place.”
“Why?” “Because our application runs on WebSphere in a Mainframe environment, and we can’t set up auto-deploy until it’s migrated to a Linux environment.”

Here we have identified the primary bottleneck – the environment on which our application lives in Production – by asking 3 “Why”s. Expect to ask as many as 5 “Why”s before getting to root cause.

Next, we need to time box the bottleneck. This basically means you’re going to work with what you have for the time being and basically “deal with it”. This is a temporary phase until you are able to eliminate the bottleneck. You should have a timeframe for how long it is acceptable to manage a given bottleneck and hold yourself to that timeframe. You may not always meet your goal, but time boxing is the first step in giving the bottleneck some form of finality.

Last, we need to eliminate the bottleneck. The easiest solution is to just do away with it – stop doing it outright. This is also usually the least feasible. The best solution is usually automation, simplification, or combination. If you can automate it, automate it! This way you’re not diminishing the task, you’re making it take less time. If you can’t automate it, see if you can apply Lean thinking and simplify it somehow. Can you get what you really need with less? Agile encourages just-in-time and just-enough to limit the amount of waste we allow in the software development process. One of the backing principles to the manifesto states “Simplicity – the art of maximizing the amount of work not done – is essential”. Finally, if you can’t automate or simplify the task, see if you can combine it with another task to “kill two birds with one stone”. Pair Programming, an XP practice, is a great example of this – you’re essentially rolling your development, code review, and knowledge sharing all into one activity that typically doesn’t take any longer than development normally would.

Once you’ve eliminated one bottleneck, repeat the process indefinitely. Kaizen mindset tells us there’s always room for improvement and it’s always urgent that we improve. By all means, take the time to acknowledge and celebrate your improvement, but don’t get complacent.

Agile: The Book vs. The Movie

I’ll be the first to admit that I’m a pretty big bookworm. I also love to go to the movies, which is less and less frequently now with young children at home. It’s an all too often occurrence for me to read a book and, as I see the images play out in my mind, think, “This would make a great movie!” Of course, that sentiment occasionally becomes reality and I find myself leaving the theater thinking, “The book was so much better than the movie!” The movie may even be good. It may be the best movie I see that year. But the book is invariably better.

I see teams, both inside my company and out, that struggle with making Agile work. Too often they get some basic knowledge, get really excited, and start forging onward without taking the time to continually research Agile best practices and innovations. It’s a stripped-down version of Agile, usually built on the roles and ceremonies only and not the principles on which Agile is founded. They’re taking all the action, but cutting out sub-plots and character development. It’s the movie version of Agile.

Over the past year, I’ve had several people express how impressed they are with how “by-the-book” my area is running Agile. And it’s true; we stay very true to the published recommendations that are widely accepted by the industry. We’re able to do this because the team has changed the way they approach software development. They have changed their mindset to one that aligns with Lean and Agile principles. They are flexible and embrace change because they know if something doesn’t work they can dump it after 2 weeks when the Sprint ends. This paradigm shift is essential for teams to be successful with Agile. It’s also the Scrum Master’s greatest challenge.

A team can run Scrum without a dedicated Scrum Master, but they are largely secretarial. They ensure the ceremonies are held and time-boxes are respected, but not much else. A dedicated Scrum Master is also a mentor and coach, with much of their time spent removing impediments; resolving conflict, hopefully in a productive way that results in learning and compromise; evangelizing Lean and Agile principles; and advocating XP and other technical excellence practices. This helps the team obtain and retain their “High Performing” status indefinitely. This is all made possible not in spite of all the change that is inherent in Agile, but because of it.

When it comes to Agile, I’ve “read the book” and “seen the movie” and, as with all other cases, the book provides a much richer experience. It might take longer to get through; it might take some imagination; and you might have to read it more than once. But the book is invariably better.

I'm back - and Agile!

I've taken a bit of a hiatus from blogging for quite a while, and I'm wanting to get back into it. To be honest, I've been blogging quite actively for quite some time, but it's been on internal blogs on my company's intranet. However, I've got insights that I want to share outside just the scope of my company, so I'm taking my thoughts that don't expose any trade secrets and publishing them here!

In the past, my blog posts have been pretty technical, and they will continue to be - to an extent. My role has shifted over the past several years from Software Developer to Agile Coach and Scrum Master. If you're not familiar with those terms, I basically am trying to improve the way we deliver software by changing the way we approach the work. You can read a little by Googling "Agile Software Methodologies" or "Scrum Software Methodology", or you can check out the Agile Manifesto or the Scrum Alliance websites.

So that's about it for now. I'm going to be doing some housekeeping on the blog and will start posting next week! I can't guarantee how frequently, but I'm shooting for at least once a month. Please leave your comments to let me know what you think!