Caution: Spikes

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

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

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

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

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

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

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

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

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

I Madge I'll - Agile Posers

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

Consultant Speak*

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

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

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

Agile Posers

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

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

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

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

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

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

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

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

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

Being Agile vs. Doing Scrum

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

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

I'm Right!.. Am I Right?

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



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

Descriptive versus Prescriptive

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

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

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

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

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

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

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

Respectfully Real Guest Blogger

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

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

Titles

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

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

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

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

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.

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.

Conversation

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 10^th 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.

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? :)