Filling Spaces

When did good enough become ‘enough’?  The more clients I work with, and more teams I encounter- the more I think complacency has become the new norm!  Enter Parkinson’s Law.  For those of you not familiar, Parkinson’s law is nothing more than an adage first noted by (surprise!) Cyril Parkinson in 1955.  It has little scientific founding; rather, it is an observation based on experience, and can be correlated to numerous situations and environments.  It goes (for our purposes) a little something like:

Work committed to, tends to fill the time frame allotted.

Now this seems like an axiom that we all could agree with.  I mean, we try not to take on too much work- right?  Consider the outcomes:

  1. We take on just the right amount of work.  Check.
  2. We take on too much work.  We remove some to fit.  Check.
  3. We take on too little work.  We catch up on other stuff, technical debt, etc. (and we try not to let on about it!)

To put a fine point on this, I would offer up 3 thoughts.

First, don’t take your foot off the gas.  It’s called a sprint for a reason.  I often see teams get ‘ahead’ on the burndown, and then relax- only to fail in delivering the full commitment.  And if you are delivering your full commitment, but quality is in question- you may need to reexamine your definition of done to satisfy both the needs of the business, as well as the quality of delivery that you want to represent your team.  Please don’t misinterpret what I am saying here- you do need to consider what is a sustainable pace for your team!

Second, if you are finding yourself in position #3 above, and there is true value to that work (other stuff), shouldn’t someone be lobbying for it in your sprint?  Technical debt should be considered first-class work as well, and you may need to employ a technical product owner (TPO) to represent this to your Product Owner (translation = get it in your backlog!  That whole visibility thing?). If this isn’t happening today, consider bringing it up in your retrospective.  If this is hindering you to a point of inefficiency, consider bringing it up today!  Yes, you can bring up a ‘done well’ or ‘not done well’ in advance of the retro (remember, the retro is simply a tool to create a forum to voice things like this- not a hardened rule that it’s the only place to do this!) J

Lastly, and many of my contemporaries would disagree with me on this point- stretch yourself.  Sometimes you don’t know what you can do until you try.  Kind of like not being able to get better at (insert sport here) until you play a better opponent.  I’m not saying to stuff your sprint to 150%, and I’m not saying to not manage your load along the sprint either.  I am saying that there is value in understanding the potential of your team, as well as understanding the dynamics of the team- and sometimes, stretching provides that perspective.

Search your feelings, you know it to be true.

Posted in Agility, Coaching, Culture | Leave a comment

Personal Responsibility

I recently heard a tale of a complete lack of personal responsibility, that I am a bit ashamed to say, made me chuckle.

At a house next to my folks, there lived an elderly couple.  They had at one point, not so long ago, desired to replace their carpeting.  Like any consumer, they called around, found a seemingly reputable company, and engaged with their services.  A year or so later, one of those nice old folks died.  The other, moved out of the home, and in with one of their children.  The child, acting upon dear old dad’s wishes arranged for the house to be sold.  In doing so, the furniture and ‘stuff’ had to come out, in order to prep for sale.

Did I mention that this nice old couple had a bit of a relic in a console television, that they still used?  Mammoth in size, a piece of furniture in it’s own rite.  Anywho- in moving this behemoth out of the room, an oddity was discovered: a patch of the old carpet!  That’s right, the carpet installers installed new carpet everywhere, except for the patch that this television was sitting on.  Congratulations, new winners of the ‘Not my job’ award.

While you take a moment to regain your composure, consider the fact that lots of us do something similar, every single day.  Kludges, workarounds, band-aids, etc.  It all adds up to technical debt.  We all do it for varying reasons- and there can be some good business reasons (very rarely) for doing something like this.  However, in doing so, you have to take the personal responsibility of:

  • Informing someone else about it- that’s right, a conversation
  • Noting what is required to ‘make it right’
  • Setting a goal of when you are going to make good on it

Anything but this, is simply short-cutting, taking the easy way out, copping out.

In taking the above steps, you might actually uncover a more simple, elegant solution.  Remember, agility is all about causing conversations!

[Update] – Okay, so on my way into work this morning, I see a fender bender on the side of the road.  Still mulling over hitting the ‘publish’ button on this article, I felt my sense of personal responsibility tugging at me- and had to stop.  An ’emotional discussion’ was taking place between the two parties, so I inserted myself.  No altercation, good conversation and relevant information [and a focus on personal well-being] , and all was good, save for that poor Hyundai.

Stay ‘chatty’, my friends.

Posted in Agility, Culture | Leave a comment

Yesterday’s Weather

It’s funny how things evolve in this world. Consider for amoment, the whole philosophy of project management. This started, from what I have read,with a guy trying to forecast how much pig iron could be effectively mined by a labor-force in a given week. A lot of this was based on getting guys with very strong backs motivated to accomplish twice as much work, with only a 50% increase in pay, in the same amount of time. Think on that one!

Fast forward quite a few decades. Now we are in the land of the lost. Sleestacks? Nope, Project Managers! The Waterfall process was documented (officially) in 1970 by a gentleman named Dr. Winston Royce. He wrote a 9 page paper on how to “Manage the Development of Large Software Systems”. He outlines it initially, before diving into the details. Right there on page 2, he provides the following disclaimer: “I believe in this concept, but the implementation described above is risky, and invites failure”. Holy cow! I’ll go ahead and give you all a few minutes to recompose yourselves and get back into your chairs. But seriously, did everyone just Sharpie out that line and press on? Almost like news headlines approved and not approved to be read in Good Morning Vietnam.

Think on that. Almost every major effort over the last 40 years to standardize a ‘prescriptive’ project management approach and methodology has been stacked on this premise. And stacked. And stacked. Now, don’t misconstrue what I’m saying. I’m not saying that all of those methodologies are junk and should be chucked. For, without them, a few folks whose names we have seen might not ever have gotten together on that fateful ski weekend in February, 2001. Frustration is the mother of invention? Or something. I could be wrong. But probably not.

Let’s switch gears for a minute. In Agile circles, there is a concept called “Yesterday’s Weather”. This concept was published in the Journal of the Royal Statistical Society in 1979, as a means of predicting- you guessed it- weather. It’s absolutely brilliant in its simplicity. Look at yesterday as a barometer (bad pun, but well placed!) for tomorrow. Boiled down to, look at your past successes and failures (recent) to map your path for future successes, and hopefully, fewer failures. Yes, this in turn becomes a Retrospective.

Another implementation of Yesterday’s Weather is to forecast how much work you can get done. Sidebar. When did estimation become a commitment? It used to be that someone would ask you, “how long do you think it will take to…..?” You give a rough estimate. 3 days later, someone is standing at your desk looking for delivery. Back to forecasting. This was the evolution of the story point. Moving to an objective scale, so that time wasn’t the primary measurement. So to forecast how much work you can complete, we simply look at the last completed iteration, assess any changes to our development team, time off, holidays, etc.- and adjust. This leads to a velocity calculation and … anybody still reading?

Last bit of profound thinking. Think about ‘those guys’ back in the 90’s, and what led up to February 2001. If they hadn’t been continually inundated with failing projects that couldn’t cope with scope and requirements change, we’d (you know, the royal, Agile ‘we’) all be staring at Gantt charts and Detailed Project Plans. And we probably wouldn’t think twice about it.

Challenge. If you are in an Agile development group, or even not- what are you going to do to improve the performance and successes of your team?

Grab an umbrella!

Posted in Agility, Culture | Leave a comment

Back to Basics

I recently taught a Certified Scrum Master Course to 5 co-workers. In preparation for this, I spent countless hours over many late nights developing course material, slide decks, and exercises that were replayed many times on my family!  I even approached it with some agile methods- I used daily iterations, a card wall to guide me, and a backlog to keep me on track, working toward my goal.

The class couldn’t have been any better laid out- I had a PM, a BA, 2 Developers, and a Quality Engineer. Upon learning this, I had a moment similar to the crowd, as the moment Rodney Dangerfield hit the water at the end of his Triple Lindy attempt in “Back to School”. I was set. What I wasn’t prepared for was the imbalance of pre-existing knowledge. A couple of the attendees had lots of practical experience (some good, some bad) actually working in ‘agile’ teams. Others had mostly theoretical experience.

Training Day 1. I love the stage. I love teaching. I love agile methods. This is my moment! With very little fanfare, we started. Late. I’ve already blown my time contract, which was just the beginning of a recurring theme. “(Dang), where is that kid?!” The first thing I realized was that everyone in the room was there because they REALLY wanted to be there. That makes this different from a lot of training sessions! The next thing I figured out was that my agenda was going to be a very loose guideline, ‘adaptable’ 🙂 It’s all good. The class showed me some grace, worked through lunch, ran some exercises at break-neck pace, and got us to my day 1 goal…sort of.

Training Day 2. Catching up. The team was very flexible, and managed the content that we HAD to get through very well. Result of ‘gelling’ as a team? Additionally, they helped scrap half of the ‘extra that I was going to speak to, and injected their own. Quick decision making as a result of training together and learning how to gain consensus? This was a fabulous ad-hoc, adaptable means of fitting the training to the time box (we changed scope!).

While this was all a good set of contributions to my knowledge base and experience as an instructor, the real meaty stuff came from the retrospectives (like usual if you run in Agile Circles). Remember that we had a few veterans in the midst of the training? Can you imagine what the overwhelming feedback was from them? Reviewing the basics! I felt, in that moment, that I just fired up Windows 3.1 for the first time and developed an appreciation for drag and drop copy & rename, versus command line wizardry! How refreshing- Agile Veterans walked away from my class thanking me for the material, and that it was important to get a refresher on the basics! I felt fully validated, and I walked away from that feeling really good about what I originally felt really disappointed about starting early on day 1! It also cast light on the fact that you could, and should retrospect pretty much anything that you put stock in!

I just want you to know- we’re all counting on you.

Posted in Agility, Culture | Leave a comment

It’s Not Just For Breakfast Anymore!

Remember this sales campaign for orange juice?  It started back in the early 80’s, as an attempt to boost sales.  It was almost stating the obvious or giving permission to drink orange juice at anytime of the day.  Imagine that!

This is how I see the world of Agile, especially in an enterprise context.  “It’s not just for small projects or pilot projects anymore!”  We as Agile Evangelists need to get the word out, and give our clients and employers permission to ‘agilify’ most any project!  I would correllate this to non-software projects, as well.

Let’s tackle the enterprise first.  Technology has bridged gaps that Ken, Mike, and the boys wrestled with that fateful February back in 2001.  The ability to work with distributed teams almost as if they were working at the next cube over is upon us.  The scaling ‘nut’ has been a tough one to crack too- but we’re there.  Multiple teams, multiple projects; multiple teams, single project; dozens of teams, 2 projects- you name it, it’s out there and working.  Scaling is often misunderstood to be representative of taking the agility out of agile projects.  More clearly, we understand today, that if we are going to scale agile projects successfully, we need to keep the same virtues in view as we do with one team.  Visibility, Collaboration, Trust.

Let’s switch gears to non-software projects.  ‘We’re a manufacturing shop.’  ‘We’re a service provider.’  ‘We don’t necessarily do software.’  I’ve heard them all, and I would offer back- the agile roots that we understand today weren’t always nurtured in a software environment.  In fact, you could say that the earliest documented instances of agility were cited back in the late 40’s in Japan, while rebuilding their infrasturcture.  Talk about a situation where you had to make the most of the labor you had, and prevent the stockpiling of waste.

Coming back to our virtues.  Visibility will always remove the fear of doubt from agile pundits.  Collaboration will prevent long stretches of time with incorrect information from elapsing.  And trust, while it is developed, is the cornerstone of highly functioning team, in a mom n’ pop agile shop, or otherwise.

I’m making waffles!

Posted in Agility, Culture | Leave a comment

Morning Joe…

I am nearsighted- have been to one degree or another since I was a teenager.  All I’ve ever thought of this term was as a defect in vision.

More recently, I had a take on the term that was slightly out of the norm- corporate approach to strategy.  Case in point: Global Chain, neighborhood coffeehouse.  I recently stumbled into my coffeehouse of choice, and ordered up my usual.  The barista, much to my surprise, asked me if I would be ‘okay’ if they used a different type of coffee.  After pondering this most important of decisions, I decided to challenge the point.  When asked, the barista responded, “The grinder is broken, and a repair guy is coming out today, so we are pulling [already ground] coffee off the shelf to satisfy our orders.”

The following week, the coffeehouse was still pulling coffee off the shelf.  I asked about the repair to the grinder, to which the barista divulged the following:

  • $600 grinder to replace
  • $6 screw to fix existing grinder
  • $15/bag (cost offset), to utilize shelved stock in lieu of grinding beans
  • 3 bags per day

In the end, it took 6 weeks to get the grinder fixed.  Doing simple math…

  • ($3 * 15) = Daily cost of not addressing the problem. (not much, right?)
  • (Daily Cost * 42 Days) = Total Cost incurred (that’s gonna sting!)
  • Yes, that’s right- $1,890, to wait for a $6 screw…

In hindsight, it would be easy to say, “Gosh, we should have just put a new grinder on-site, and taken the broken one back for repair”.  The Barista knew how much this was costing on day 2 of this adventure, AND conveyed it to his superiors.

Now, I’m not saying that making coffee and making software are the same thing- but I’m not not saying that either.  There is a process.  There is management. There are the folks that are in the trenches everyday, slugging through that process, with oversight from their management.  And, there are customers who depend on all of the above for a product.

Nice story, but cut to the chase- right?  Fine.  There are times when management doesn’t see the whole picture, much like when you are getting agile methods off the ground for the first time at your company, or at a new client, if that’s your thing.  It is your duty as an agile coach to caution your boss, client, team, etc. that change is hard, and that (not to sound cliché) it’s going to get worse, before it gets better.

Remember, Agile isn’t going to solve your problems- it will expose them!

Is it time for a coffee?

Posted in Agility, Culture | Leave a comment

Sustainable Pace = Realistic Load

In 1876, at the urging of Samuel Plimsoll, the British government passed into law the requirement for maritime vessels to have established, and displayed, a ‘Plimsoll Mark’. This is a visible indicator on the hull of aship that the harbor master can verify that the ship is not overloaded, forseaworthiness. You can imagine the number of fatalities that were incurred over the previous several hundred years as a result of ship overloading.In much the same way, we as agile teams, work diligently to understand and establish our ‘Plimsoll Marks’. This comes by way of many of the interactions, artifacts, and methods we employ.

The daily scrum: a subjective barometer reading of sorts; allowing everyone on the team to understand if ‘new cargo’, or surprise cargo has been found.

Burndown chart: an objective barometer reading that discerns the difference between the course we are on, and how far until we ‘reach port’.

Sprint planning: a good understanding of the ‘what’, with the ability to take a deeper look under the covers before finalizing your ‘bill of lading’.

Velocity: a record of ‘successful deliveries’, to set the mark against for future trips.

Sprint Review: a process review the condition of, and the delivery of the cargo (ensuring it’s the right cargo).

Sprint Retrospective: a process review on how the voyage went, and how to make it smoother sailing next time.

Without these measures in place, for decades, project teams have been a casualty of their own planning, projects, and expectations. It is for this fact alone, that makes Agile a successful endeavor; by putting planning into the hands of the team, and conveying realistic expectations (clearly displaying their team-based Plimsoll Mark) to the business and customer.

Who needs a paintbrush?

Posted in Agility, Culture | Leave a comment

A Dirty Word

When did ‘Estimate’ become a dirty word?  Think about it- in school, our kids are being taught in their various math courses, right this very moment, how to estimate in certain situations:

Estimate:  304 x 29

The kid will say, “about 9,000”, right?  Will you hold it against him if the actual answer isn’t 9,000?  (It’s 8,816- Fortunately, life isn’t ‘The Price is Right’, and if you are over, you just plain lose.)  The point is, and I hope you agree with me here, is that you don’t hold it against him, because he was told to estimate.

Fast forward that kid’s career 10 years, and he finds himself to be a jr. software developer for a respectable organization.  One day, while happily working on his committed tasks for the sprint, he gets a visitor at his desk.

“Hey Joe- remember that report we were talking about a few weeks back?”, asks the sly Product Manager.

“Sure, I remember- the one with the roll-ups by account type.”, says Joe.

“Yeah- How long do you think it would take for you to do that?”, the Product Manager asks.

Now Joe is surely stuck.  He’s new with the company, and has developed a relationship with the Product Manager (for better or for worse).  Joe offers up “6 hours”.   Satisfied, the Product Manager walks away.  Where do you think he’s going to be in another 6 work hours?  That’s right- at Joe’s desk, looking for that report.

I know what you are asking yourself- “How can that be?  He was asked for an estimate about a feature they discussed weeks ago.”  That’s because, somewhere along the path of projects and software, estimate became commitment.  We as contributors to development teams were no longer able to have an error percentage in our estimates, and the byproduct of that, was even worse.  Padding.  Doubling Estimates.  Sandbagging.  Playing it safe.  Getting ahead and not telling anyone.  It all happens.

And that my friends, is why we like to use a method, abstract of time, objective in nature, relative to other work, to measure our efforts.  Story Points.  That conversation from earlier looks a lot different if Joe’s response is “3 points”.  Undoubtedly, the Product Manager will attempt to clarify for a time scale, and this is where the Scrum Value: Courage, comes into play.  Stick to your guns Joe!  It’s 3 points!

I won’t go into the other bad behaviors around the Product Manager grabbing a junior developer for a side conversation around estimates today…

Set your phasers to Scrum!


Posted in Agility, Culture, Estimation | Tagged | Leave a comment

The Evolution of the (Agile) Tester

I once attended a conference and listened to Michael Bolton (no, not the singer, and definitely not the guy from Office Space) untangle a thought stream on the validity of the QA profession as a whole.  He talked about the difference between “Testing” and “Checking”.  Consider that for a moment.  Checking is the process of following a prescribed checklist and verifying certain data or function points, typically well after something has been delivered, reactively.  Testing, by way of exclusion here, is then understanding what you are going to receive and then thoughtfully considering the actions of the client, and working on their behalf, proactively.  This is a fundamental change in the mindset of the “traditional” tester.

In the same way, a mindset change is required for Testers to be successful in an Agile Environment.  Consider the composition of an agile team- it is referred to as a Delivery Team, or more recently, a Development Team (Scrum Guide update 2011).  All members of the team are charged with developing a product increment, as a team.  This means that you can toss the traditional titles in the circular buffer- if you have the talent and can step up for the team, come on down!  Testers, you are a part of this team!  No more silos!  Get over your degrees or lack thereof people!

Another agile change that testers should consider is how they can effectively jump in with the rest of the team at the front end of each sprint.  This means that you are going to have to engage the team, have a voice, and be the Assurer of Quality, not just the Quality Assurance representative.  How is this accomplished?  Well, as a Development Team, (now, don’t panic!) your QA folks are going to have to learn to code, and learn to code well.  Here comes the bucket of cold water:  The days of the traditional, manual only tester are over. Take a minute and soak that in.  (Consider it- Offshore resources can be hired for 1/3 your rate.)  The thing that is going to bring value to your position as an Agile Tester is going to be your ability to communicate technically with the rest of the team, engage and develop solutions, as well as your ability to……Test Early, Test Often.  I’m not sure who was credited with saying that first, but Good On You, whoever you are.  This phrase has changed the landscape for a subject that wasn’t really broached head on since the signing of the Agile Manifesto- how does QA fit into Agile?

Test Early.  This means engaging your developer teammates before and during the coding process, selectively working through the appropriate layers of test, providing direction in terms of Quality for the team, and prioritizing your work to test the increment.

Test Often.  This means automating as many of your test scenarios as possible, engaging your developer teammates as co-developers, and approaching your test automation as a coded product.  Make no mistake, the Testing Developer or Developing Tester or whatever you want to call it, just saw their stock go sky high recently, and there‟s no recession in sight.

In conclusion, as testers, to stay effective in this business, we need to work more proactively, get in the game earlier, and sharpen our development axes (and that doesn’t just mean blowing the dust off that VBA book or your “Command line for Dummies” book- C# is hugely valuable, uses modern techniques, and works as the underlying language for many tools [including Selenium, TestComplete, and M$ Coded UI]).

Stay Classy, San Diego.

Posted in Agility, Culture, Testing | Leave a comment