I recently rotated through a different management position for a weekend. It was still in IT, but I walked home late on Sunday realizing I learned a heck of a lot.

As a long time professional services guy I often miss the freshness of the new client. Just some of the clients I got to work with in a single year:

• Fortune 500 pharmaceutical company
• Multiple app server vendors
• Online learning business
• State of California licensing agency

Managing within a corporate IT arena you do get different challenges and you have a variety of internal business customers, but it’s still centered around the same business context.

I’ve been with the new company for about 6 months now and I’m still stumped by a fair bit of acronyms. I have gotten comfortable operating within the development sphere and a pretty constant set of business customers. Working as the weekend manager for a different IT group gave me some perspectives I wouldn’t have gotten any other way.

The most valuable part of the weekend was talking to various folks on other teams about how they saw the work they were doing and what they’re value proposition was. They were all tired. (This was weekend work) A lot of them were a bit down on morale. They all were trying to do the right thing. I made a few of them laugh when I asked basic questions about things they’d been doing for years. Like, “don’t you just reject a patch if the install instructions are all wrong?” The answer turned out to be no.

Taking a dive into a different area especially an area of the business works out your brain. I thought I’d be tired coming in this morning after working 12-14 hour days over the weekend, but I came back recharged and doing a bit more strategic thinking. And I can bring what I learned back to my team.

Getting DSLs to be business readable is far less effort than business writable, but yields most of the benefits.

— Martin Fowler

Software transparency to business experts is a great goal. I’ve met plenty of sophisticated business users who at least could do some basic SQL and whip together lots of nice reports in Excel. Those same users when presented with Java code lean back in their chairs and wait for the developer to show them a screenshot. Getting a DSL they can actually read and give feedback on means higher quality software.

I can’t claim to have reached this goal despite some attempts. So far the closest was a Fitnesse implementation validating business rules in some vendor software. The testers really took on creating scenarios after it clicked for them, but the business analysts still found it a bit to rough around the edges. Baby steps.

Fowler nails the point of DSLs from a business perspective. It sounds great to talk about business users writing the rules for the software. Every rules engine vendor makes this claim. In practice I’ve never seen it happen. Developers end up writing the business rules in the syntax of the particular engine.

Creating readable DSLs is great if you can communicate with the business experts. And even if you fall short the developers/testers get clear concise code out of the exercise.

Flipping through the Google Chrome documentation my brain was screaming–“This has to be Scott McCloud“. Turns out it was. Scott was a big deal back in the dot com days with his book on “Understanding Comics” and it’s applicability to designing web sites. I actually saw a great talk from him back at the Web 99 conference in SF. (That would be 1999). Nice to see him crossing back into the web world again.

The Chrome documentation is one of a number of new documentation styles I’ve seen recently. Screencasts are also becoming a popular way to do documentation and not just for high profile Web 2.0 frameworks but small internal IT apps. One consultant told me he had started doing all the documentation for their custom IT apps as screencasts. The customers love it because they can figure out how the app works quickly without running painful conference rooms of training sessions. And the flashiness of it is a bonus as well. To top it off it generally only takes a few hours for the developer to put it together. He mentioned the Peepcode screencast by Geoffry Grosenbach on Screencasting on the Mac was one of the best investments he’s made in a while.

As a developer, especially a developer who is comfortable building servers and slinging code in vi, you don’t want to hear the no word from the sysadmin. You want to be agile and install your own app. You want to configure the extra JNDI settings yourself. And you’re wrong.

I’ve worked in environments where sysadmins ruled with an iron fist on their environments and never let developers on production even to grab log files. Other places developers had wide open access. Wide open access is a bad, bad thing unless you’re still a small startup. Here’s the best model for a corporate IT shop.

• Developers own development for the most part. Sysadmins may backup the server on some filesystem, but that’s about the extent of it. Source control, wikis, continuous integration all run here. Developers are the primary users and everyone else is just visiting.
• Test is all about the testers. Testers should have access to tools like bug trackers and automated testing tools or servers. All the test servers should be locked down with developers and testers given read access to things like log files. Here the sysadmins begin to exert more control because test is the first step formal step in moving an app to production.
• Staging is a pure environment and developers are locked out here.
• Production is a no touch environment. Sysadmins have full control and troubleshooting issues means the developer sits with the sysadmin and doesn’t do the typing.

Developers need to stay focused on quality and not jump around troubleshooting environments. Good sysdamins will say no to developers touching production, but they’ll work closely with them to automate deployments and configuration. Remember they’re saying ‘no’ for your own good.

Keeping you backlog in order doesn’t tend to happen in isolation. My past experience is the backlog drifts because of a concentration on completing day to day Sprint tasks. You can tell when the backlog has drifted, the planning meeting goes long. Kane Mar suggests an approach of using a Story Time meeting.

A Story Time meeting should be held at the same time and location every single week and involve the entire team, including the Product Owner and ScrumMaster. The sole intention of these weekly meetings is to work through the backlog in preparation for future work. This may include adding new stories and epics, splitting up overly large stories, and sizing.

At my past company this often came up as an issue since backlog items wouldn’t get estimated or explored much until the Sprint planning meeting. The idea is to have the product owner keep up with these items and follow up with people to get estimates as new items show up. In practice that just didn’t happen.

I like the idea of blocking out time to make sure it gets done and it helps ensure the planning meeting is smoother and over sooner. You wouldn’t need to use it with every team since some teams are just naturally better at making the time to keep the backlog in good shape.