For all the under-18 DevOps fans out there, The Agile Admin is now available via Tumblr too at http://theagileadmin.tumblr.com/! Get your parents’ permission…
Category Archives: General
I thought I’d take a minute for a teambuilding tip from Management Corner and share a winning teambuilder from here in Austin that I’ve used a lot and has always been a solid success. We call it “Meat, Guns, and Booze.” Steal it and use it with your teams!
Coming up with good teambuilders for an engineering team is pretty difficult. You have a mix of introverts and extroverts. Going to a movie doesn’t really allow for much personal interaction. A group meal lets you talk to the 3-4 people next to you, which in large groups isn’t a large percentage, and even getting everyone seated together can be a challenge. Not everyone drinks and may not appreciate hanging out at a bar. Messing around in the office is fine but sometimes you want to get out of there so that people aren’t continually distracted by work. Not everyone is active enough for something like paintball (especially in Texas weather!). Well, back some years ago while I was at National Instruments we were mulling over what a good field trip/teambuilder could be given all these limitations, and happened across a winning combination that never fails to deliver!
First, head out to Lockhart, about an hour from most places in Austin, for a lunch of barbeque. Austin BBQ is good, but for the truly top tier stuff you have to go out to other locations (we love Franklin’s/LA Barbecue but going and standing in line at 10 AM to get some isn’t really a team activity). You can have internal debates over whether you go to Black’s, Smitty’s, or Kreutz’; try them all out over time as everyone will passionately defend the one they think is best. For vegetarians, there’s good sides, but also there’s a cafe right across the street from Smitty’s Market with salads and whatnot. Smitty’s also has a “no utensils” rule; eating meat with your hands definitely switches the mood to informal and friendly quickly!
Pro Tip: Bring cash. Some of them – Smitty’s for sure IIRC – don’t take credit!
Besides the great BBQ, many folks haven’t seen old style rural Texas – even folks living in Austin, but especially people from other countries. I remember once we were headed into town, and it has a traditional town square with raised boardwalks and all – and the two guys from Ukraine in the back seat started wriggling around like itchy bear cubs and talking rapidly to each other in Ukranian. “What’s up?” I asked from the driver’s seat. “It looks just like Fallout!” they breathlessly exclaimed. I had to laugh. It’s worth a brief stroll around the town square and courthouse. There’s a western-stuff store for the greenhorns, too.
If it’s raining, you can fall back to Red’s in Austin, they have several locations. But they’re small and cramped for groups. Right near Lockhart is the Lone Star Gun Range. They have rifle and pistol ranges, outdoor but with shade. You just need a driver’s license (or passport for the foreigners) and you can rent anything from a revolver to an AK-47 for a reasonable fee – you mainly end up paying for ammunition. (You can bring your own guns and ammo, but have to buy their ammo to use in their rental guns.) They give a quick safety briefing and off you go. As long as you have one or two more gun-savvy people to help folks who are having trouble figuring out how to reload or whatnot, you’re good to go; I’ve been there many times with groups of 10-20 composed of mostly noobs with no problems. And don’t worry – everyone gets into it. I’ve had people who were initially intimidated but once they get hands on for a minute they always take to it with gusto.
Even in Texas, gun owners usually don’t go out to the range all the time, so it’s a treat even for those who are more into it, and a novelty for those who aren’t.
Pro Tip: Don’t drive a super-nice car – the road to the place is not paved, it’s shell. If you have a sweet hand-waxed Porsche you should ask someone else to drive. Also, it’s outside in Texas in (whatever season) – bring sunscreen, hats, and a cooler full of water. There is an air-conditioned store with a bathroom and all if someone gets overwhelmed by the heat.
Sad Note: They used to have a Barrett .50 out there at Lone Star but they sold it. The rounds were super expensive but no one wanted to fire more than 1 or 2 anyway! But they have revolvers, automatics, rifles from .22 to ARs to AKs…
After shooting, you’re usually hot, and so stopping in at a watering hole on your way back to Austin is a good thing to do. Anywhere that’s convenient for you is good – I’ve done the Whip In as that’s uber Austiny, has an outdoor patio with picnic tables for good social mobility, and has a lot besides just beer (food, wide non-alcoholic drink variety). You got out of the office (and out of town), had the team nourish itself on food, then have an exciting activity, and now they get to interact with the ice already well broken. People don’t drink a lot because it’s already been a long day, as opposed to a “let’s go drink” teambuilder where people are more tempted to overindulge. But they have plenty to talk about. Non-drinkers – or if your entire company doesn’t like sponsoring events with alcohol – can just drink sodas and have an appetizer or two to unwind.
And yes, to all the wags out there who inevitably respond with “but don’t mix up the order!”, you do want to do it in this order – there’s the wisdom of no drinking before gun handling, but also because this sequence of events is carefully constructed to provide a cadence of icebreaking and interaction. You “break bread” together, which is a universal signal of togetherness, and sit by some people to eat, by others in the car, interact with others while doing a stimulating activity, unwind with others after, etc. And since it’s multipart, if someone really does have to come late or leave early there are multiple natural breakpoints. We also like doing three-round K1 racing as teambuilders but that’s more disruptive if people come and go.
I’ve used this teambuilder with multiple teams, multiple companies, and it’s always a hit. It’s especially a hit with international teams – folks from Malaysia, Ukraine, etc. see all of this as a special treat; it’s very common to talk to them a year later about their trip to Austin and they’ll immediately volunteer that this was their favorite part of their visit hands down. It’s relatively inexpensive and just takes a long afternoon (we usually leave at 11 and start wrapping up at 5). It’s maybe $1000 for a full day of fun for a dozen people.
Not In Austin?
Well of course the luridly titled “Meat, Guns, and Booze” specifically evokes Texas and is tuned to our location. But consider the same kind of event cadence and think about what’s distinctive in your area. You just want the team to share a meal, then participate in an activity that everyone can easily participate in, and then have an opportunity to relax and talk with each other afterwards.
Today I’ve been treated to the about 1000th hour of my life debating whether something someone wants is a “bug” or a “feature.” This is especially aggravating because in most of these contexts where it’s being debated, there is no meaningful difference.
A feature, or bug, or, God forbid, an “enhancement” or other middle road option, is simply a difference between the product you have and the product you want. People try to declare something a “bug” because they think that should justify a faster fix, but it doesn’t and it shouldn’t. I’ve seen so many gyrations of trying to qualify something as a bug. Is it a bug because the implementation differs from the (likely quite limited and incomplete) spec or requirements presented? Is it a bug because it doesn’t meet client expectation?
In a backlog, work items should be prioritized based on their value. There’s bugs that are important to fix first and bugs it’s important to fix never. There’s features it’s important to have soon and features it’s important to have never. You need (and your product people) need to be able to reconcile the cost/benefit/risk/etc across any needed change and to single stack-rank prioritize them for work in that order regardless of the imputed “type” of work it is. This is Lean/Agile 101.
Now, something being a bug is important from an internal point of view, because it exposes issues you may have with your problem definition, or coding, or QA processes. But from a “when do we fix it” point of view, it should have absolutely no relation. Fixing a bug first because it’s “wrong” is some kind of confused version of punishment theory. If you’re distinguishing between the two meaningfully in prioritization, it’s just a fancy way of saying you like to throw good money after bad without analysis.
So stop wasting your life arguing and philosophizing about whether something in your backlog is a bug or enhancement or feature. It’s a meaningless distinction, what matters is the value that change will convey to your users and the effort it will take to perform it.
I’m not saying one shouldn’t fix bugs – no one likes a buggy product. But you should always clearly align on doing the highest leverage work first, and if that’s a bug that’s great but if it’s not, that’s great too. What label you hang on the work doesn’t alter the value of the work, and you should be able to evaluate value, or else what are you even doing?
We have a process for my product team – if you want something that’s going to take more than a week of engineer time, it needs justification and to be prioritized amongst all the other things the other stakeholders want. Is it a feature? A bug? A week worth of manual labor shepherding some manual process? It doesn’t matter. It’s all work consuming my high value engineers, and we should be doing the highest value work first. It’s a simple principle, but one that people manage to obscure all too often.
Well I know it’s been quiet around here lately. Two of the agile admins, myself and Peco, have switched jobs and have been crazy busy.
Peco has moved to Opnet as a SE – he always loved their APM tool Panorama and we got a lot of mileage out of it at NI. Notably, this included getting some of our suppliers, like Vignette, to buy it and use it on their products to find the performance problems before we did… We were having Vignette V7 performance issues and used Panorama to identify exactly what they were, and when we fed it back to Vignette engineering they were like “how the hell did you do that…” Opnet’s never had great marketing, they’ve been doing what New Relic and AppDynamics have been doing for a long time but aren’t as much of a recognized name. It’s an interesting move for Peco, he went from long time Ops guy to a Java dev, working on system automation like PIE, and now an SE because he wants trigger time on customer interaction. He’s a renaissance man! And working on his own stealth startup on the side of course.
I have moved to Bazaarvoice, a SaaS startup in Austin (well, are you still a startup when you’re up to 400 people?) to be their Manager of Release Engineering. They have been increasing their dev and ops forces by a very large margin (P.S. We’re hiring!) and wanted someone to run the “middle third” of their DevOps teams. There’s one team of DevOps embedded into all the product teams, kind of a matrixed organization; then there’s my team to do the build and deploy automation and cloud and data center stuff; then there’s a support team to wrangle the pages and tickets.
I was there for a week doing new hire training when they said “So we have moved to agile doing two week sprints, and that’s going OK except we realized we can’t release every two weeks safely. Get that going. We start biweekly releases in three weeks. Zero customer impact each time!” Therefore I’ve been in a little bit of a frenzy doing that. It was definitely on the fine line between “I like a challenge” and “Oh shit.” I lucked out and got a week of slack because we decided to IPO on the date that the first release was supposed to go, and we decided that doing both on the same day was just a wee bit too ambitious. The first biweekly release slipped from a Thursday till the next Tuesday and only had two minor issues that needed fixing after, and the next one is coming up! We should have it tamped down to regular in a sprint or two and I hope to return to more regular blogging.
On the side of course I continue to help run the Austin Cloud User Group and the Agile Austin DevOps SIG and put together DevOpsDays Austin and do other random stuff, so sadly when the overcommittedness hits the blog has to give.
James is doing great, and just had a new baby! So he’s been out of pocket some too. He’s still at NI, and now large and in charge of all operations for their SaaS products. They are fighting the brave fight to get PIE open sourced and out the door.
We are all going to SXSW Interactive this weekend and will regroup and decide how we’re going to bring you all the latest in hot cloud/DevOps/tech stuff going forward!
Sorry all, it’s been a crazy busy month around here. But the Agile Admin is back, and we’ll be talking about the latest fun stuff in DevOps, cloud, and cloud security on a regular basis!
Some fun developments:
- We delivered another NI SaaS product, the 1.0 version of the FPGA Compile Cloud
- We’re working hard on another, the Technical Data Cloud
- NI just hired Lars Ewe, former CTO of Cenzic, as a security guru, and he sits over here with our group.
- Agile Austin has started a DevOps SIG
- Work towards open sourcing PIE, our Programmable Infrastructure Environment, proceeds apace!
So we’ve been busy, but I know we need to take more time to discuss and engage with everyone else out there, so it’s back to posting! Hope to see you all in the comments.
Hey all, sorry it’s been quiet around here – Peco and I took our families on vacation to Bulgaria! Plus, we’ve been busy in the run-up to our company convention, NIWeek. I imagine most of the Web type folks out there don’t know about NIWeek, but it’s where scientists and engineers who use our products come to learn. It’s always awesome to see the technology innovation going on out there, from the Stormchasers getting data on tornadoes and lightning that no one ever has before, to high school kids solving real problems.
There were a couple things that are really worth checking out. The first is the demo David Fuller did of NI’s system designer prototype (you can skip ahead to 5:00 in if you want to) . Though the examples he is using is of engineering type systems, you can easily imagine using that same interface for designing Web systems – no ‘separate Visio diagram’ BS any more. Imagine every level from architectural diagram to physical system representation to the real running code all being part of one integrated drill-down. It looks SUPER SWEET. Seems like science fiction to those of us IT-types.
A quick guide to the demo – so first a Xilinx guy talks about their new ARM-based chip, and then David shows drill-up and down to the real hardware parts of a system. NI now has the “traditional systems” problem in that people buy hardware, buy software, and are turning it into large distributed scalable architectures. Not being hobbled by preconceptions of how that should be done, our system diagram team has come up with a sweet visualization where you can swap between architecture view (8:30 in), actual pictures and specs of hardware, then down (10:40 in) into the “implementation” box-and-line system and network diagram, and then down into the code (12:00 in for VHDL and 13:20 in for LabVIEW). LabVIEW code is natively graphical, so in the final drilldown he also shows programming using drawing/gestures.
Why have twenty years of “systems management” and design tools from IBM/HP/etc not given us anything near this awesome for other systems? I don’t know, but it’s high time. We led a session at DevOpsDays about diagramming systems, and “I make a Visio on the side” is state of the art. There was one guy who took the time to make awesome UML models, but real integration of design/diagram to real system doesn’t exist. And it needs to. And not in some labor intensive “How about UML oh Lord I pooped myself” kind of way, but an easy and integral part of building the system.
I am really enjoying working in the joint engineering/IT world. There’s some things IT technology has figured out that engineering technology is just starting to bumble into (security, for example, and Web services). But there are a lot of things that engineering does that IT efforts look like the work of a bumbling child next to. Like instrumentation and monitoring, the IT state of the art is vomitous when placed next to real engineering data metric gathering (and analysis, and visualization) techniques. Will system design also be revolutionized from that quarter?
The other cool takeaway was how cloud is gaining some foothold in the engineering space. I was impressed as hell with Maintainable Software, the only proper Web 3.0 company in attendance. Awesome SaaS product, and I talked with the guys for a long time and they are doing all the cool DevOps stuff – automated provisioning, continuous deployment, feature knobs, all that Etsy/Facebook kind of whizbang shit. They’re like what I want our team here to become, and it was great meeting someone in our space who is doing all that – I love goofy social media apps or whatever but it can sometimes be hard to convey the appropriateness of some of those practices to our sector. “If it’s good enough to sell hand knitted tea cozies or try to hook up with old high school sweethearts, then certainly it’s good enough to use in your attempt to cure cancer!” anyway, Mike and Derek were great guys and it was nice to see that new kind of thinking making inroads into our sometimes too-traditional space.