Matchgrip

Time has flown by and now I have a daughter that is in Pre-K.  Brooke finished her first few days of school  and so far it’s going great.  Heather and I took her on the first day we had about 30 minutes of orientation with Brooke’s teacher and a quick presentation from the PTA.  Brooke’s teacher seems fantastic.  She got emotional while she was talking to us.  I think it was a combination of seeing all the parents in the room that were emotional as well as remembering what it was like the first time she took her own children to school.

One thing I found disturbing was how much the school, teachers, and PTA have to ask for money.  It wasn’t that I found it annoying because it wasn’t.  They try to not be pushy… it’s just sad that the PTA has to raise money to help the school buy supplies for the classrooms and such.  We certainly aren’t in the wealthiest distrcit in the Oklahoma City area, but it’s also nowhere near the poorest.  Our political leaders should be ashamed that they’ve put the schools in such a predictament.

Brooke made it through the first day without crying and by the time Heather picked her up a few hours later she was already talking about going back to school.  She loves it.  So far it’s been mostly playing and story time.  They’ve done one little art project.  Everyday I get to hear about what they had for snack time.  She just loves going to school.

Heather has signed up and volunteered for almost everything.  I think it’s great that she’ll be involved in the school.  I plan to be as involved as I can on evenings and weekends when they have things.  I’ll also take time off at work when they’re doing special activities or field trips.

There are some pictures from the first day on my gallery site.

Go Roadrunners!

I went to see Nine Inch Nails in concert last night and it was fantastic.  My gut reaction when it was over was it was easily in the top 10 concerts I’ve been to (Just for reference I’ve seen Rush twice, Prince twice, U2 3 times, Motley Crue, The Rolling Stones, The Police, Nirvana, Pearl Jam, and lots more).  What made this one standout was the visual technologies the band is using.  It’s WAY more than just a group of Nine Inch Nails songs being performed by a great band.  They use layers of screens that move up and down throughout the show and give depth to the visuals.  They do things like giving the illusion the band is playing in a remote landscape and then it starts to rain Then there is a tear in the rain and you can see the band performing in the rain.  When’s the last time you saw that at a concert?  Oh yeah, never!  Some of the screens were interactive.  At one point a guy with a large spotlight “wiped” away the blue color (watch the end of this video to see the effect - right as they’re going into ‘Pinion”) of the front screen to reveal the band.  During the beginning of ‘Echoplex” the drummer walked across the stage interacting with big boxes he could turn on and off.  It was just amazing stuff.  Nathan and I kept looking at each other like “whoa!”. (NOTE: All the links above point to YouTube clips where you can see the effects. They’re worth watching).

Then of course the music and performance of the band were excellent.  It would be easy to assume that since Trent relies heavily on technology and drum machines and keyboards and such to make his albums it wouldn’t translate well to a live show.  And that would be a WRONG assumption.  It works great.  Tons of energy being put out on songs like “Wish” and “Gave Up” and “Survivalism”.  The new songs from The Slip worked really well live.  The drummer was great.  He got a few spots to show off some skills and he was always doing visuals and tricks to make it exciting.  Trent went through 3 tamborines and I lost count of how many microphone stands he launched up into the sky and let crash on the stage.

One song that really impressed me was “Piggy” off of The Downward Spiral.  They worked into the song from some instrumental pieces which made it interesting.  The basic song was the same but it somehow seemed a little different … almost a smokey lounge type of feel.  It was great.   Oh and all the other songs!!!

I learned a valuable lesson last night.  You see, I almost didn’t go to the show.  Nathan was bugging me before tickets went on sale and I kind of thought “oh I don’t want to spend the money… and I just saw them on the With Teeth tour a few years ago”.  But Nathan kept on me and my friend Justin pointed out I’d be a giant idiot if I didn’t go.  They were right.  Whatever it ended up costing… 60 bucks or something, was totally worth it.  Trent is breaking all the rules for concerts with the video technology he’s using.  So the lesson learned is if you like a band, and they come to your town, you should go.  There aren’t that many opportunities to see bands you like and you should take advantage of them when they present themselves.

Our seats were great.  4 rows up from the floor just a tiny way back from the stage.  No one around us hit us or threw beer on us or blew smoke in our face.  If you get a chance to see this tour, you should do it.  Here’s the setlist

On July 11th Heather spent the evening and early morning hours with some of Oklahoma City’s biggest nerds. Why? To get each of us a new Apple iPhone.

So far Ive been really happy with it. It has a gps device that integrates with Google Maps which is really neat. It serves as an iPod touch, it’s a nice pocket Internet device, and I can even use it as a phone! My only complaint would be the touch screen keyboard. I can’t type as fast as I could on my old Treo or my Blackberry.

There are neat applications coming out daily for the iPhone like this one that allowed me to write this entire post and publish I’d from my phone. It also allows me to attach photos that exist on my phone.

My friend Matt Smith has released a free application Quicksend, and he has a password management app on the way that I’m eager to try.

June was an exciting month for me and the future looks to be exciting as well.  I had a few interesting things happen to me in my professional life.    Early in June I went through an interview with a potential new employer.  I wasn’t anticipating that it would go so well and I would be ready to leave Hertz.  Not long after my interview I received a promotion and became an Applications Consultant which came with a raise.   I was even more unsure if I should leave for a new job with the raise, but I was eventually made an offer and it was a great offer and a new exciting opportunity - so I accepted.  It’s been an interesting couple of weeks.  I’ve been with Hertz for 9.5 years and have made quite a few relationships that will be challenging to walk away from.  However, I’m completely at peace with my decision and can’t wait to get started.

I also got a new car!  I’ve been driving the car Heather got when we were in college, a ‘95 Saturn.  Last Friday we purchased a silver 2007 Honda Accord.  It has working air conditioning which is pretty freakin’ exciting!  It’s a basic LX model, so not a lot of bells, but it rides nice, low miles, nice stereo, and should last me a good long time.

I recently joined a book discussion group with some colleagues at work.  We get together once a week and use The Art of Agile Development as a starting point to talk about Agile Software Development topics.  A lot of the  people that are doing agile development are passionate about it.  They can even be dogmatic when they talk about it.  Over the years “Agile” has grown to include alot of practices.  Things like TDD, daily stand-up meetings, story points, iteration, sprint, continuous integration, colocated teams, XP, Scrum, are all part of the Agile space now.

We were talking in our book group about a pattern I think all of us that are passionate about Agile development have seen.  When you are talking to someone and you mention words like “sprint” “tdd” “acceptance criteria”, often people that aren’t “into” the whole Agile thing will immediately discount what you’re saying.  You can almost see it in their body language : “Oh great, more Agile whooey”.  Even if you are labeled around your co workers as “one of those Agile guys” you can get the eye rolling and body language no matter what buzzwords you are (or are not) using.  As we were talking about that issue in our book group I coined the phrase Agile eye rolling.  I believe a good definition would be - “Giving the indication of an immediate discredit of someone’s ideas on software development by the rolling of eyes.  Often the presenter of an idea is using Agile concepts or is known as someone who believes in Agile software development“.

You heard it here first!

It’s been awhile since my team had a (Sprint/Iteration) Retrospective.  I’ve been grumbling about it on my team for several months, but after my Certified Scrum Master training I was reenergized to try it again.  It went better than I think most of us expected, and I think it was the most productive Retrospective we’ve had.

I started out asking people if they thought we should have a retrospective.  There were a few team members that voiced honestly they didn’t want to take the time to do it.  The explanation they gave was that they’d participated in many before, often listing the same things that needed improvement, and rarely ever seeing any changes.  And as you would expect it doesn’t take too many rounds of that for people to write retrospectives off as something useful.

I also learned that my previous way of facilitating the meeting was an issue with some team members.  In the past I would ask each person one-by-one during the retrospective to list things that went well and things that need improvement.  There are team members that take that as being “put on the spot” and they feel pressured to come up with things that need improvement.  (As a side, I explained to them that my way of thinking if people can’t come up with any things that need improvement then the team is perfect and we coudln’t do better.  The reaction to that from the same people was a “OH GOSH!  No way, it’s far from perfect” type of reaction.  Hm!  ).

After some discussion everyone decided they were willing to at least give up one hour and to try this retrospective.  I came in with one major goal, pick ONE thing to improve.  Make it visible to remind people what the one thing is.  And build a list of real action items to help improve the one thing.  We built a good list of things that are going well and things that could go better.  The team decided they wanted to pick off two things.  Since one of the things was a pretty easy improvement, we all felt we could take on two things to improve.

The first thing to improve was making our burndown chart more visible.  Another team member suggested that (at least for now) we take a few minutes at the beginning of our daily standup to talk about the burndown.   Some people aren’t familiar with all the different things we communicate through the burndown, and what all those lines and dots really mean to the team.

The next item we took was to build a definition of “Done” for a Sprint and build action items to help us get there.  Currently our team defines done as coded.  As you can imagine it can get messy when things from a previous Sprint are being tested in a new Sprint.  If things need tweaked or bugs are generated it can throw a new iteration out of whack.  We decided as a team that “Done” to us for a Sprint means Coded, Tested (by BA role), QA Scripts pass, and the task in our tracking tool is marked as closed.  Next we brainstormed about ways to achieve that definition of done:

• Organize our Sprint Backlog in such a way that larger or more complex stories are checked in to give testing plenty of time.  We’ll move little cosmetic changes or simple fixes to later in the Sprint, because those should be easy to test and generally won’t introduce new bugs.
• Developers working more closely with QA members and BAs to help test.  It sounded like developers would even be willing to quit coding for a day or two if need be to help the BA’s with any testing issues they may have.
• Developers taking ownership of getting code changes deployed into our testing environment.  Currently developers are monitoring CI for bad builds.  When a build goes bad developers will quickly get the build fixed, but we wait for the overnight deployment process to move the new code base to our testing environment.  Now developers will make sure that things get deployed in the middle of the day if overnight the build breaks.  This ultimately boils down to a little more communication between the ba’s and developers on our team : “Hey BA Jones, our unit tests failed last night.  I’ll get it fixed within the hour and once the build is good we’ll get the new code deployed to the test box”

I captured our TWO big things on a cling sheet and stuck them to the wall where we have our daily scrum.  It should be a good reminder, and when things get off track we can talk about it.  Everyone on the team was engaged in talking about the things we wanted to fix.  It wasn’t just a person or two doing all the talking.

As the meeting concluded one of the team members that was honest about not wanting to do the retrospectives said she enjoyed it and thought it was productive.  I was reminded of an important concept that everyone loses sight of from time-to-time : just give it a try. I got feedback from a few other team members over the next day.  Everyone seemed really positive about the retrospective, and excited that we had concrete ideas on how to address things we want to do better.  And now at our next retrospective we have a jumping off point - how did we do our communicating around our burndown and achieving our definition of “Done”.  I’m looking forward to the next one!

Pair programming is a software development practice where two people are working behind one keyboard/monitor to accomplish a task.  One person is driving (typing) and the other person is navigating (not getting bogged down in syntax, but thinking how things fit together, where the next piece of code belongs, etc.).

I’ve often spoke out against pair programming.  I can admit that’s based on not much real experience, but just thinking about all the potential pairs in my environment, there are going to be people that don’t like each other being put into a pairing situation.  Which will make coming to work a real drag for those people.

However, I’ve just recently seen the value in pairing.  It’s something conceptually I knew, but it just hit me in the face this week.  It turns out, if two people are pairing on something the whole time, neither person needs to ever “ramp up” the other person.  You don’t need to fill them in on the problem.  Or explain to them all the things you’ve already tried or investigated.  You don’t have a need to give someone a UML artifact and then explain it for 30 minutes because that person wasn’t around for the discussions when that artifact was created. All of that goes away when you’re pairing.

I recently had a bug I was working on.  It was one of those bugs that is hard to track down.  I spent about a day going through the scenario in the debugger trying to capture each little piece of data as it moved through our code base.  Yet at the end of that exercise still had no idea what was going on.  I asked a teammate come over to pair with me.  After a few minutes I realized he was going through all the problem solving steps I had already gone through.  Fortunately the teammate is a sharp guy that picks up things quickly so it wasn’t too long before we were on the same page.  But still, how valuable would it have been for us to take the bug and start going through it together.

Then today I went to see if a teammate needed any help getting her task done as our iteration is wrapping up this week.  She gave me a part of a rather large and requirement-rich deliverable.  Lots and lots of steps and links through all sorts of requirements documents.  She had a different teammate over earlier in the development process and they spent several hours over the course of a few days ironing out the requirements and determining what we had currently and what needed to be built to address the new requirements.  When I came in they had some UML artifacts written up, but I still had to go through the excercise of familiarizing myself with the requirements and the current code.  And even though they had some diagram for me to look at, I missed all the conversation that lead to that diagram being created (which for me is where the real meat is.  The discussions with other teammates and the users is where you’ll learn alot about a task).  Again, had we just had a pair working on it from the beginning that would have been avoided, and even if the pair would have decided “hey we can split up for 4 hours and you do xxx and I’ll do yyy and we’ll get back together after lunch and put our stuff together” it would have allowed us to divide and conquer, but all the while two people understanding the design.

I might be becoming more of a believer… maybe.

This week I was fortunate enough to take a two day course to become a Certified Scrum Master. In a nutshell, Scrum is a framework that teams can use (and build on) to become higher performing. Scrum provides teams with techniques to help with planning, organizing, and estimating work.

The instructor of the course was Mike Vizdos (of Implenting Scrum fame). I found Mike to give just the right mix of textbook Scrum and real world Scrum. Mike makes sure that he doesn’t spend all his time in the classroom, but also working with teams from all sizes of organizations that are implementing techniques from the Scrum framework.

My class was made up of 9 people. Two of us were from larger corporations, two guys were from a small product company (including the owner of the company), and the other five were all from a small consulting company in Oklahoma City. The group was mostly software developers, but we did have one person that performed a business analyst + project management role. It was a great mix from all different backgrounds and all of us had different levels of experience with Scrum and wanted to get different things out of the course.  Everyone in the room was energized and engaged.  We had a healthy mix of optimists and skeptics, but neither type dominated.  Everyone actively participated in the simulations and we even got behind on some of the prepared material because of all the good questions and conversations.  We even decided that we all wanted to create a Google Group (or similar) to keep in touch and exchange questions and information with each other and we take Scrum back to our companies.

I have found the subject matter interesting for quite some time.  How can you take a bunch of people that have different skill levels, interests, and backgrounds and get them to gel as a unit and perform at a level they didn’t think was possible.  That’s the basic goal, but it takes alot of work and constant improvement.  My major complaint is that it’s only 2 days.  Some of the simulations we did would have been more interesting I think if we had a little more time to remove some of the canned feel to them.  Example, let the Product Owner on the team actually pick something for us to work on.  I found that to be most challenging, when we would need to question our product owner often they didn’t know any more than we did or really care.  I think if the person playing that role were allowed to pick the product (for example maybe I’d say “I want to build drumsets”, they would know more and care about the results.  There were some exercises that aren’t necessarily part of Scrum (team communication and such) that would have been interesting to do but we just ran out of time.  However, the time we did spend was quite fun.

So what did I come away with?  As my friend Barrett says “I drank the Kool-Aid”.  I’m convinced that the techniques from Scrum (Agile) are the best way to do software. I’m also more convinced that ever that if you have a Scrum Master that can give the management and other stakeholders whatever they need, the team can be shielded from all the outside noise and with some guidance will figure out the best way for them to perform at a high level.  We currently do some things core to Scrum at my current job which is great.  The big area where I would like to see improvement is getting the team to a point where they are focused on a goal and constantly looking for ways to do their job more effectively.  Things like having a definition of Done, Sprint Reviews (Demos), and Sprint Retrospectives. I even learned things not part of Scrum, but part of being able to work on teams and communicate effectively with team members and management. I learned how to give and receive feedback and how to deal with certain team dysfunctions.  As I slowly migrate into a Scrum Master role on my team, I want to introduce (or in many cases, re-introduce) techniques that I think the team can handle, and continue inspecting-and-adapting to improve our performance.

Woof!

About a year ago my company had a consultant come in that was tagged as being a person who could help our teams with process issues. He helped us implement several things that help our teams develop software more effectively. One thing that he often suggested to us was we should be doing iteration demos at the end of every iteration. Most people, including myself, couldn’t see the benefit. What’s the point? How’s that going to really help us get more done? How is that going to help what we develop be better designed of less buggy? Crazy consultants!

Well I still haven’t participated in any end-of-iteration demonstrations. But after observing my current team and reading more resources about effective software development, I’ve changed my opinion. I, Jason McIntosh, wish that my team did a demonstration at the end of every iteration and here’s why :

FOCUS!

I think the biggest win I can foresee would be helping the team focus. More often than not our iteration lines and goals are blurry. Sure, we get together and plan an iteration worth or work, but often it will change. Sometimes we don’t finish things and the attitude is generally “well that’s no big deal, we’ll just move it forward to the next iteration”. Every iteration I have been a part of we turn in things that don’t get tested. We don’t have a sense of commitment and a sense of urgency that I believe you would get knowing that stakeholders and other outsiders are going to be coming down in 3 weeks to see what you’ve accomplished. All the engineering practices we know we should be doing but sometimes cut corners on would become more important, and I believe in the long run make our code better designed and less smelly (unit testing, integration testing, etc.). The team would have a real pressing reason to make sure that not only did they finish what they committed to doing, but that it was done well enough to be demonstrated to managers, other teams, product owners, etc.

About a year ago our older DirecTV + Tivo Receiver in the bedroom died. We were sad to discover that DirecTV and Tivo had discontinued their partnership and DirecTV was now making a generic DVR receiver so we had no choice. We read around on the web and the reviews of the new receiver were not good.

The reviewers were 100% right. It’s a piece of junk. The interface is terrible. Often it will hang when you’re fast forwarding at a certain speed and you have to speed it up or slow it down to get it slapped back on track. Often the audio and video channels get out of sync when just watching live tv and you have to switch channels back and forth to get it synced up. There is no easy way like our Tivo unit at the end of something to go back to the list and have the receiver prompt if you want to delete what you just watched. You have to watch the entire thing (who watches the last minute of a recorded thing if you’ve already seen the “next week on The Young and The Restless” segment?). It’s decided to not record stuff before, or it’s decided to only record half of what it was recording. On and on… it’s a turd.

One of the things we get with DirecTV is the MLB Extra Innings to feed my love of the New York Mets and Major League Baseball. The other night I was watching the Mets game and I noticed a little notice popped up on the screen that said “Press the red button at any time for MLB features”. (We’ve never known what the red button was for, the yellow, green, and blue all have functions, but not the red except in one menu). What happened next was pretty awesome. A screen came up overlaying somewhat the game (it was semi-transparent so I could see through to still see the game). From that menu I can see all sorts of cool things. I can get the box score of the game I’m watching. Every stat updated as if you were looking at the box score online. I can see a run down of all the scores of games going on at that time. From the score rundown I can move the cursor around and if I select one of the scores it will pop me over to that channel/game. I can hop to the MLB Mix channel. The Mix channel is really neat. It has 6 boxes on the screen showing different games going on. You can move the cursor around the boxes and the audio will change to the audio for that game. So you can see all the games but listen to the one you’re most interested in.

I was super impressed and thought it was a really neat usage of software in our tv receivers. So everything else is no good, but from April - October I can enjoy the cool MLB features.