You Do Not Understand Agile

Agile is not a proper noun. Agile is not a person, place, or thing. You do not do agile. You are agile.

What Is It?

My simple explanation of agile is: You have a vision of what you want to accomplish and the ability to make decisions. Assemble a group of smart, dedicated, and capable people to start figuring out how to do it and validate your assumptions and outputs along the way.

It’s as simple as that. That is agility. The understanding and acceptance that you will not know everything in advance but as long as you have a team of capable people with a set of top level goals and a single voice that can make decisions, you’ll figured out the rest as you go.

But What About Enterprise?!?!

When you throw the word “enterprise” in the mix, everyone loses their mind. “What about portfolio management?” “What about the PMO?” “How much will this cost?”. “We need a 6 month roadmap!” “WE NEED KPIs!!!”

The basic tenet of agility does not care about any of those questions. That’s all corporate generated noise and a relics from the contractor control model days from yesteryear. The primary goal is to add value as quick as possible and to incorporate learnings from fast feedback cycles.

The enterprise has caused all of their own problems and has institutionalized practices that make themselves slow. This short video Coordination Chaos does a great job illustrating how we inventively get ourselves into that mess.

Keep Calm, Agile On

There are no magic bullets. All you can do is recognize what the top level goals of being agile are ask yourself “am what I doing consistent with agility?”. If the answer is no, rethink your approach. If you continue to take small steps in the right direction, you’ll eventually get there.

Great article about monitor setup and eye strain

I’ve been having an influx of headaches and migraines recently and i’m trying to eliminate as many causations as possible. I am on a computer at work all day and probably a few hours at home too. Multiple screens, multiple devices, multiple settings. Some I can control, some I cannot. I wanted to research a bit on monitor setup and eye strain and configure things correctly that are under my control.  I’ve been following the advice from this Wired article I came across while doing some research.

KEEP YOUR COMPUTER FROM DESTROYING YOUR EYESIGHT

Monitor Position

I might have had my monitor slightly too high. I wanted to try and correct my forward head posture and thought if I put my monitor slightly higher, it would force me to keep my head back. Apparently I never factored in eye strain.

Color Temperature

If you’ve ever been in my house, you’ll know all of my lightbulb temperatures match in every room. I’m a little crazy like that and from being hobbyist photographer, one thing I’ve learned over the years is temperature matters. If I’m at work, I try to match my monitor the the ambient temperature of the room. Sounds simple, but I work in an open environment. There are light sources everywhere and people do not share my enthusiasm for consistency. To make matters worse, I have a dark section where I sit.  About 25% of my area has no lighting and the other 75% is too bright.

I’ve attacked this problem by getting a desk lamp with adjustable brightness AND adjustable color temperature! The kicker is, we have bright white LED bulbs in the ceiling, but I sit directly next to a tan wall, which gives off a “warmer” profile when reflected. I still haven’t settled on what color to use consistently, but I’m contemplating putting up a big whiteboard just to bounce white light off. We’ll see how that goes.

Monitor Brightness

The brighter the room, the brighter the monitor. It’s a pretty simple rule and my office is bright. We have LED lamps that face the ceiling and they reflect the light back down to the floor. This creates a very hard light source given how bright they are and how close they are to the ceiling. Being in an open office, they’re hard to ignore. If I look 3 inches above my main monitor, I have 6 rows of super bright lights directly in my view. To compensate for this, I’ve had to set my monitors to almost their brightest settings.

For my newer, low end monitor, it can handle it. However, my 27″ 2560 workhorse can’t hang anymore. It’s clearly not as bright as the newer kids on the block and it breaks my heart. I’ve never had an issue with it at home because I can control the lighting in my home office, but out there in the wild, it can’t hang anymore.

Faced with the dilemma of either turning down the brighter monitor or blasting the brightness on my 27″ so much it blows out the contrast, I chose neither. For now, it’s sitting under my desk until I can establish the MVB (minimal viable brightness, I made that up) and make an ultimate decision.

Email Workflow for Making Work out of Email

I receive an average over 100 emails every day and most of them go unread. I try to keep up, but it’s a losing battle. Every 5 minutes a new emails shows up. In a meeting, at lunch, on the phone, trying to answer a previous email, trying to get real work done. Doesn’t matter. It’s non-stop. Ding. Ding. DING. I’ve turned the email notification sound off completely. I’m starting to drop the ball though. Now come the follow up emails, or reminders, or worse…schedule meetings for things that should be emails. I was stuck and needed to find a better way. I came up with an email workflow to combat this issue and so far so good.

Continue reading Email Workflow for Making Work out of Email

Code Coverage vs Test Coverage

When organizations mandate “code coverage” numbers, like 95%, they’re barking up the wrong tree. Just because a line of code has been touched during testing, doesn’t mean it’s been tested; you’re only fooling yourself. Every time I tell someone the last product I created had 93% test coverage, they say “wow, that’s great!”. Then my follow up statement is “Yeah, it sounds great, but bugs still crept into covered areas”.

Continue reading Code Coverage vs Test Coverage

I was wrong about tracking actual hours in agile

I once made a statement about closing out project management tickets that went something like “The actual hours a story / task took are the only metrics that matter”. At the time, we had a ton hoops to jump through to close a story out due to our tooling choices. We ignored most of them, but the actual hours field was something I told the team I valued. My thinking at the time was this would definitively show us if we’re coming up with accurate estimates and if we missed our estimates, where did we spend that time. This would give us solid data points to use across sprints and act as a spring board for future planning sessions. In reality it ends up being fruitless and does little to build a better team.

I generally follow Scrum when doing agile with teams, but I’m not prescriptive about it in any way. “Whatever works for the team” is another sound byte you’ll routinely hear me say and along those lines is where I had my epiphany. Just like the agile process itself is about enabling the team, estimation and time is all about the sprint. “How many stories can get done this sprint” is the real question around how long something will take. That’s it. It’s a scheduling exercise to maximize effective use of planned time. It’s just an estimate! Where that time went during the story / task completion is immaterial. Sure, it makes for a good conversation during the retrospective and leads to a fancy spreadsheet some dude in khakis can email around, but tracking actual hours in agile does little improve the estimation process of the team and certainly doesn’t increase the teams productivity. If neither of those things are happening as a result of tracking actuals, then I submit it is a pointless venture.

 

I was wrong about tracking actual hours in agile

I once made a statement about closing out project management tickets that went something like “The actual hours a story / task took are the only metrics that matter”. At the time, we had a ton hoops to jump through to close a story out due to our tooling choices. We ignored most of them, but the actual hours field was something I told the team I valued. My thinking at the time was this would definitively show us if we’re coming up with accurate estimates and if we missed our estimates, where did we spend that time. This would give us solid data points to use across sprints and act as a spring board for future planning sessions. In reality it ends up being fruitless and does little to build a more predictive team. I’ve learned through trial and error that tracking actual hours in agile has no value in Scrum.

I generally follow Scrum when doing agile with teams, but I’m not prescriptive about it in any way. “Whatever works for the team” is another sound byte you’ll routinely hear me say and along those lines is where I had my epiphany. Just like the agile process itself is about enabling the team, estimation and time is all about the sprint. “How many stories can get done this sprint” is the real question around how long something will take. That’s it. It’s a scheduling exercise to maximize effective use of planned time. It’s just an estimate! Where that time went during the story / task completion is immaterial. Sure, it makes for a good conversation during the retrospective and leads to a fancy spreadsheet some dude in khakis can email around, but tracking actual hours in agile does little improve the estimation process of the team and certainly doesn’t increase the teams productivity. If neither of those things are happening as a result of tracking actuals, then I submit it is a pointless venture.

Which Ruby Iibrary for a Static Website

I’ve been toying with the idea of taking on side projects, specifically helping people bring their web application ideas to market in the form of a minimal viable product. I have become very efficient at taking white board concepts and turning them into working software in a short amount of time. Production quality at that, not just prototypes or throwaway code. I’ve talked to a lot of people with good ideas that have similar problems, “I could get this going if I could only code!” Well, I think I can make that happen. First stop is standing up a static website for marketing.

Continue reading Which Ruby Iibrary for a Static Website

MadCow 5×5 Week 3 In Review

General

I keep having to have the realization, epiphany, or whatever you want to call it that I’m only in it for strength, not size / mass. The only thing I should care about during this 12 week MadCow 5×5 program are numbers, specifically the numbers in my spreadsheet that put me at an estimated 1000lbs+ total. Continue reading MadCow 5×5 Week 3 In Review

Switching to a week in review format

I jumped the gun a bit with that last post. For a 12 week program that has 3 workouts a week, that would be 36 entries, way too many. Once a week is fine, basically a “week in review” of my progress. These posts are for myself really, a way to force me to reflect on my goals, my progress, and serve as a basic gut check. What’s special about this mesocycle is the calculated total at the end is 1000+ lbs, which I’ve been saying for a while is my target, but I’ve had a few set backs and lost focus more times than I would like to admit.

MadCow 5×5 Week 2, Workout A

I’m still not 100% and coming off a head cold. Regardless, I felt pretty strong. It was my first time working out in a sweatshirt and realized real quick why you have to had your hood up…you can’t squat with it down! I made all of my lifts without a problem, nothing really too eventful other than my return to the basement and trying to figure out the accessory exercises.  Continue reading MadCow 5×5 Week 2, Workout A