Retrospectives

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.

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!

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.

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!

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?

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?