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

Thank You, Inspiration

I was recently engaged with a client that works in an industry where heavy-weight processes are like a security blanket when it comes to project management. I was helping out as a “traditional PM”, but anxiously looking for “an in” to get some agile influences injected through their seemingly impregnable armor of committees, change control requests, and governance review boards.

My first meeting with the client was to review: a) what was going on b) what projects where in progress, and c) what their goal was. Almost immediately (call it 2 hours into the engagement) I lept out of my chair and said, “Mr. Client, what we need here are some agile processes- you simply have too much that ‘has to get done’, and too little time to do it, following your current processes.” Much to my delight, we spent the next 2 hours talking about the visibility of a backlog, and the flexibility of adopting it.  Fast forward a month, and you’ll see me working on data management via their clumsy collaboration system, if you want to call it that; generating reports; and attending regular, drawn out 3 hour meetings. Very “non-agile”.  What was more readily apparent to me than it had been in the past (I was very fortunate at prior clients that they really wanted to change!), was that agile isn’t a project management methodology- it’s a people management and cultural shift- that you have to “want” in order for it to take hold.  You see, while the client saw value in the exercise we went through on my “Day 1”, it wasn’t familiar, and the rest of the folks that would be impacted didn’t share that brief, wonderful, “a-ha” moment.  From then on, it would be business as usual.

Critical mass was quickly approaching: an immovable deadline, which all the work we had in flux rested upon- with legal ramifications.  You could almost see this coming like background music playing for the last 2 months, and someone would turn up the volume 1/4 of a point each day- slowly building.  It came to a head, and I was notified on Thursday, that I would be flying out to a project coordination meeting on Sunday.  I was also tasked with making sense of all of this mess, above and beyond the narrow scope of things I was working on.  My first 3 attempts to map, graph, and articulate the situation were rejected. The problem was that I was thinking like them, not like me.

Do you ever notice how inspiration has her own schedule, and that you are simply at her mercy? I was sweating out a creative deadline, and the hands on the clock were accelerating.  In a moment of sheer desperation, almost like Ralphie in “A Christmas Story”, while dazed, sitting on Santa’s lap and feeling the moment slipping away, I blurted out “Kanban!” (in lieu of ” I want an Official Red Ryder Carbine…”).  It was digital nirvana- I blasted out a Visio version of blocks and swim lanes that represented everything that absolutely had to be done as a first pass.  Thank you, inspiration.

Giving up security blankets. I felt like I was going to have to have a heart-to-heart with the client representatives, one at a time (like Michael Keaton in Mr. Mom- weaning his kid off of his security blanket, telling him that if he doesn’t give it up now, he’ll be twenty-something, and will find himself strung out on bed-spreads).  Not so- I showed this to the corporate guy, “Sr. Project Manager”- his first words- “can you mail that to me right away?”  I did, and do you know what we spent the next few days doing? That’s right, building a task board.  Fast Forward 6 weeks.  This gave visibility to all the ‘stuff’ that had to get done. This gave flexibility to the plan.  This highlighted the ability for multiple work streams to execute in parallel.  And we did it without ever saying “agile” or “kanban”.  To boot, we even started doing a daily stand-up of sorts, with reference to the task board. Ultimately, we finished what we set out to do, on time. Many folks attribute it to the modified approaches, and this group celebrated a success that is seldom seen.

Who says you can’t teach an old dog new tricks?

Posted in Agility, Culture | Leave a comment


Agile methods have been around for longer than most of us have been with our current job (or 3).  Agile in and of itself has always been about ‘community’.  With that in mind, I would like to welcome all of you readers to ‘Retrospectives’, a blog that will run as frequently as it makes sense, much like the approach to agility.  A year ago, I joined a new company, bringing with me, “Agile Fever”.   Along my journey there, I have dug through file shares, exchanged emails, and unexpectedly run into folks that are like-minded. The consistent theme throughout all of these actions has been to grow agile as a whole, within that organization, as a community.

Some of you might be asking, “What’s this agile thing all about?” Bottom line, it’s a different way of approaching your work, while reconsidering what is most important in completing a project; prioritizing accordingly. Many organizations are already utilizing agile methods, or are considering it- so get on the agile train folks! If you want to learn more, you can ask, or you might find a thing or two in google…either way, you’ll be glad that Agile has a Community!

Stay tuned for future installments, as I am sure they will be like a box of chocolates!

Posted in Culture | Leave a comment