Tuesday, November 19, 2013

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?

Tuesday, November 12, 2013

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.

Monday, November 4, 2013

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”.

Thursday, October 10, 2013

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.

Friday, October 4, 2013

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.

Thursday, September 26, 2013

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.

Sunday, September 15, 2013

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?

Monday, September 9, 2013

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!

Thursday, September 5, 2013


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?

Tuesday, August 13, 2013

Taming the Wild West: the Differences between Agile and Cowboy Coding

One of the strongest arguments for Agile is that it’s not Waterfall. However, not everything that isn't Waterfall is Agile, a fact that’s not always understood. This misunderstanding hurts the Agile brand when people familiar with only Waterfall begin associating all other methodologies, including a lack thereof, as Agile. I want to be very clear about this: Agile is not Cowboy Coding, and Cowboy Coding is not unique to Agile teams. It is important both to understand how Agile and Cowboy Coding are different and what Cowboy Coding looks like so that you can identify it on your teams (yes, even Waterfall teams).

The Loner

One of the easiest signs of a Cowboy Coder is that he’s a loner. He may be working under the name of Agile, but there are no Agile methodologies or frameworks I’m aware of that support such behavior. In fact, the backing principles of the Agile Manifesto state, “Business people and developers must work together daily throughout the project”; “Build projects around motivated individuals”; “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”; “The best architectures, requirements, and designs emerge from self-organizing teams”; and “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The manifesto, its principles, and all Agile methodologies and frameworks I know of are very human-centered with an emphasis on collaboration.

If you have a loner on your team that insists on working in a silo, there’s a possibility that you have a cowboy in your midst. Try to rein them in using mandatory meeting/ceremonies that promote meaningful conversations and practices like Pair Programming. If they absolutely refuse then you will likely end up spending considerable time managing the work around them – holding ad hoc conversations, formal code reviews, knowledge transfer workshops, etc. – with diminishing returns.

Straight to Production

Working directly with Production code or with a source code repository that isn't versioned is a bad idea. Don’t get me wrong, I love Continuous Delivery and working off the trunk, but a software development team must be very mature and disciplined to make this work. They use feature toggles and branching by abstraction to protect code that isn’t ready for Production. They build test suites around the code so that each commit is verified against regression. They do their due diligence to make sure that a change isn't going to blow up if it’s pushed to Production. Cowboys, simply put, don’t.

If you find yourself consistently in a situation where the same person or people are making changes directly to Production without due diligence then you might just be working with Cowboys. Have them read up on DevOps and Continuous Delivery so they can learn the right way to get changes to Production quickly. Emergency situations that require quick, non-vetted changes to Production should be avoided at all costs.

Wastes of Time

The Cowboy will often refer to Testing and Documentation as a waste of time. They may even commit the cardinal sin of Agile, reciting the Manifesto blasphemously: “‘Working software is the primary measure of progress’; anything else is just a waste of time!” To those people, I would ask them to define “working”. Does it pass the Acceptance Criteria associated to the work (or did you even bother to ensure you had Acceptance Criteria)? Can anybody actually use it, or is it too buggy or complex? Is anyone other than yourself aware of the assumptions made around input, output, workflow, etc.?

Without proper testing and documentation, you can’t prove your software works nor can anybody understand how it works. With that being said, if your tests and documentation don’t contribute to the value and usability of the software then they are, in fact, a waste of time. Focus your testing efforts on tests that actually stand a chance of failing and finding vulnerabilities. Don’t spin your wheels creating “write-only” documentation. This is the approach that Agile espouses; anyone who says tests and documentation are altogether useless is operating with a Cowboy mindset, not an Agile one.

“Emergent Architecture”

One of the backing principles to the Agile Manifesto states “The best architectures, requirements, and designs emerge from self-organizing teams”. There are those who believe this means “just make it up as you go.” That’s not entirely accurate. There still needs to be intelligent design, and that design needs to make the software as easy to comprehend and maintain as possible. As another principle clarifies, “Continuous attention to technical excellence and good design enhances agility.” This means having a thorough understanding of the latest design patterns and practices. It means taking the time to refactor working code into something better. It means taking a little bit of time up-front to design what you think will work and adjusting as you go.

Agile developers do not shoot from the hip. They take pride in their applications; they have a sense of ownership. They will throw research spikes, read books, build proofs-of-concept, attend conferences – do what it takes to build the right thing in the right way. You’ll spot a Cowboy by their purposeful lack of direction, sticking code wherever they please with the sole purpose of “getting something to work” so they can move on to the next thing. If they do it in the name of “emergent architecture” then call shenanigans. That’s not architecture, it’s just reckless.

Somewhere to Hang their Hat

The good news is that cowboys can be tamed if they can come to appreciate the practices, tools, and frameworks that Agile provides. Cowboys won’t jump on the bandwagon just for the heck of it. There will always be some that refuse to be tamed, but many will see the benefits and forsake their wandering ways once you give them a safe place to hang their hat.

One of the great things about reformed Cowboys is they are used to developing quickly and cross-functionally. If you arm them with XP practices, Agile tools, a Kaizen mindset, and continued training and development, they can become model developers that contribute quality software time after time.

Just don’t make the mistake of trying to get them to do something for which there is no tangible benefit. They don’t take too kindly to that.

Friday, August 2, 2013

Normalized Story Points

UPDATE: 18 months later, I've reflected back on this topic in my post "Revisiting Normalized Story Points".

I was recently involved in a discussion on LinkedIn on the topic of Normalized Story Points and whether or not it was a good idea. What I noticed was that, despite what I think is a very clear explanation by the Scaled Agile Framework (SAFe), many people misunderstand both the process for normalizing Story Points and the intended benefit to be gleaned from this practice. If you have not yet, I encourage you to read the explanation in the “Iterations” abstract on the Scaled Agile Framework before reading on (the section entitled “Relative Estimating, Velocity and Normalizing Story Point Estimating”). That will provide the proper context for my thoughts, as a Certified SAFe Program Consultant and active Release Train Engineer, on what this means (and what it doesn’t).

First, how do we normalize Story Points? The gist of the process is this:
“1. For every developer tester on the team, give the team eight points (adjust for part timers)
2. Subtract one point for every team member vacation day and holiday
3. Find a small story that would take a about a half-day to code and a half-day to test and validate. Call it a 1.
4. Estimate every other story relative to that one.”
That’s basically it. The primary problem that teams run into is that they ignore step #4, along with the advice that follows these steps: “There is no need to recalibrate team estimating or velocities after that point.” This is a tool that has very specific benefits; it is intended for one-time use that allows for long-term benefit.

This means that teams within a SAFe organization are using a common practice to determine a baseline from which to begin relative estimation and, as such, will have Story Points that are roughly the same size. This will enable “just good enough” Story Point estimation of cross-team Features and Epics, which allows for more precise road-mapping and budgeting than we would otherwise have.

This does not mean that teams are estimating using Ideal Man-Days. They should still do relative estimation using the modified Fibonacci sequence. This also does not mean that roadmaps will be 100% precise; they will simply be more precise than what’s been available before. Budgeting will be precise in the sense that we float scope, not cost; however, the Epic Owner should only expect the Minimum Viable Product (MVP) and not necessarily every requested feature when the Epic has been initially estimated and not yet broken-down.

This means that teams establish how “big” a Story Point is early and don’t have to spend as much time figuring that out as a team. When I first became a Scrum Master, my team ended up having to re-baseline several times as they learned how to better write and slice User Stories. The alternative would have been either User Stories that were smaller than one point or multiple one-point Stories that were considerably variable in the amount of effort they actually required.

This does not mean that all teams will have exactly the same Story Point “size” or estimate exactly the same way. Every team is still unique and has their own dynamic that works for them. You will find, however, that the “size” of each team’s Story Point is close enough to allow for Program and Portfolio level estimating and planning.

This is not intended to take the place of established Agile practices for planning, splitting, and estimating the work that teams deliver. It is intended to get teams started in such a way that planning, splitting, and estimating can be done more simply and effectively across multiple teams. Once you establish your baseline, throw Ideal Man-Days out the window – it then becomes only a part of the criteria for relative estimation, along with complexity and uncertainty. Once you establish your initial velocity, throw the 8 Story Points per person per Sprint out the window – instead, use “yesterday’s weather”, current circumstances, and team growth to determine the number of points the team will commit to each Sprint.

Just like any other tool, metric, practice, meeting, or role that we use in Agile, the practices used for Normalizing Story Points have a stated benefit. We do not do things for the sake of doing them. Normalizing Story Points can have a tremendous positive impact on an organization practicing Agile at scale; a misunderstanding of Normalized Story Points can have a significant negative impact on that same organization.

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.

Friday, July 26, 2013


Many Scrum practitioners don't realize that Scrum did not invent the idea of User Stories - XP (eXtreme Programming) did. They are, however, often familiar with Ron Jeffries' "3 C's of a User Story", namely Card, Conversation, and Confirmation. The more I train teams on User Stories, the more convinced I am that the Conversation aspect is the most important of the three, and it is applicable to all things Agile, not just User Stories.

I recently facilitated PSI Planning for my area's Agile Release Train (Potentially Shippable Increment). I’ve noticed that, with each new PSI, the teams become more concerned with extensive pre-planning. They try to get more out of the meeting by doing as much of the actual planning before arriving at the meeting. Unfortunately, they do not understand that the primary reason for PSI Planning is not to generate a plan as much as it is to have conversations. Teams must communicate and align with each other and their customers. They must examine their work to determine what dependencies and risks are inherent in the work so that they can communicate, manage, and mitigate them as much as possible. This process happens to produce a better plan, which is why we do it. However, those who come to the event with pre-determined plans often find they must be reworked or scrapped altogether.

Rework manifests itself as delay, and delay indicates waste. Agilists hate waste. In fact, an Agilist’s views on waste and rework can be found in the 10th principle that accompanies the Agile Manifesto: “Simplicity – the art of maximizing the amount of work not done – is essential.” How do conversations help prevent rework? If we talk before acting then we get a better sense of the truth, established in an environment of shared context. Conversations mean multiple perspectives, which bring difficult questions and challenge our assumptions. They force us to produce something as a group that is better than could ever be produced in a silo. They reinforce the paradigm of “just enough, just in time” instead of “big up-front”.

Once I realized that conversations are integral to Agile, I began to review the tools and practices within Agile, specifically Scrum, for conversations. All of the prescribed ceremonies – Daily Scrum, Sprint Review, Sprint Retrospective, and Sprint Planning – center on team conversations. Pair Programming and Test-Driven Development are XP practices that rely heavily on communication, both within the development team as well as between the developers, testers, and customers. A good Scrum Master helps the team most by facilitating conversations, and the Product Owner’s backlog is meaningless if they don’t ensure the team understands the work. There are conversations baked into literally every aspect of Scrum!

Conversations are often overlooked because people do not view simply having the conversation as an objective in most cases. They focus on the stated outputs: plans; acceptance criteria; status updates; confirmation of stories completed; etc. Consequently, it is not uncommon for teams to find alternative means to deliver these results without the “overhead” of the conversations. They rely heavily on tools and individual efforts to maximize their time without hindering the team with human interaction. They may, at first, feel an increase in productivity as the perceived burden is lifted. Yet, inevitably, they find themselves struggling to deliver quality quickly and do not understand how Agile could betray them so. Hopefully they have a good Scrum Master or Agile Coach watching them adapt in the wrong direction that can have them take a step back so they can see the error of their ways. If not, it becomes easy to blame their frustration on Agile and revert back to their comfort zone of more “traditional” methodologies.

As a safeguard, I recommend teams, and especially Scrum Masters, go back to their roots frequently to make sure they’re staying true to the founding principles that make Agile methodologies so great. Remember that “business people and developers must work together daily throughout the project,” and that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Don’t just blindly follow a framework or practice; instead, try to understand why you are asked to do things a certain way. If the purpose that you perceive is not aligned with the Agile manifesto and its accompanying principles, you’re probably wrong. Acknowledge your failure, “Fail Fast”, and change your approach so that it fits the Agile paradigm. It may seem counter-intuitive at first, but it will pay off in the long run.

Monday, June 24, 2013

People != Resources

Within my area, I've become famous for correcting people when they say "Resources" and mean "People". I work hard to get people to think of each other as human with a unique skill-set and personality, not interchangeable cogs in a machine. When people start complaining about a "lack of resources" I ask them to make a shopping list and I'll pick some up from the store.

Apparently, my message is getting through.

The other day I was in one of the rooms our teams work in and saw this on the whiteboard.

I thought, "Wow, I really got through to someone!" Then, I saw this underneath that:

So not only do they understand that people are not resources, they point out an example of what would be considered a resource. Then, to drive the point home, I found this:

It's true, they're not! What I love most about this is that I didn't write any of this - members of my team saw the opportunity to share a message that they had bought into because they saw the value in treating each other as people, not just resources!

Finally, a bit of nerdy humor to finish this off. What else would you expect of a bunch of geeks? :)

Tuesday, May 28, 2013

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.”

Wednesday, May 1, 2013

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.

Monday, March 25, 2013

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.