Archive | Agile RSS feed for this section

Come to KCDC 2010!

26 May

So I’ll be one of many fine speakers at the KCDC this year. JPeck also got the nod. We will both be imparting our wisdom con mucho gusto in the “Agile Track”.

I’m probably the millionth person to liken KCDC to ACDC, but I’m probably the only speaker who has gone to the trouble of making a rockin’ KCDC logo using…you guessed it! PowerPoint! Looks amazing, huh? Yep, I thought so too.

I hope people stick around to 4:30 PM to hear my schtuff. They should; a good time will be had by all.

(FYI, I tried to get free beer for all audience members, but it just wasn’t possible this time)

Advertisements

A Call To Share

12 Apr

I was asked to speak at the upcoming Kansas City IT Symposium. I’ve attended the event before and found that most of the sessions are geared toward upper IT management. My session will target middle managers and I’ll discuss some of the anti-patterns of management I’ve seen while working for and with different IT people over the years.

I’m really looking forward to the event and I had a blast creating my slide deck. Here is the opening slide:

I even have some props: a pair of drumsticks and a U.S. Robotics 56k Modem. We’ll see how it goes…

Bruce Schneier Looks Like Fred Armisen

9 Mar

Stop at 0:22

My Take On JPeck’s TDD Example

9 Mar

I had some spare time today, so I caught up on my friend James’ blog. He recently posted a real-world example of TDD taken, I assume, from his real-world job of developing software for a bank.

In the comments section of this particular post, someone named Darren made a case for using interfaces and mocks in the design of the tests and the resulting software. James stated that he would probably try that approach next. Well, the original post is about one month old now and I happen to have T.A.D.D. (Technical Attention Deficit Disorder). So, I’ve posted my version of James’ real-world TDD example. A few comments about my design:

  • I changed the design of the HumanResourcesService. I renamed it to “IEmployeeService”, extracted and renamed the methods and created a criteria-based lookup.
  • I renamed the “HumanResources” class to “EmployeeManager” and made it work against the IEmployeeService abstraction.
  • I exposed the GetEmployeeById as a public method in EmployeeManager. I figured this would be a good thing to provide consumers.
  • I used Rhino Mocks and SpecUnit as the mocking and TDD frameworks, respectfully.
  • I generated a report (HR.Specs.html) showing the different specifications the test code is exercising. The report looks nice, but to get it I had to use underscores in the spec class names (yuck). Was it worth it? Probably.

In general, I tried to follow the AAA (Arrange, Act, Assert) pattern in the spec code. I’ve included James’ very-slightly-modified code in the solution for reference (I renamed a couple of variables I found offensive). Click here to download the code. Rename it to a .zip file to access the contents.

Reaction Time: An Agile Management Metric

14 Nov

I was recently on a nature hike on the side of Superstition Mountain in Scottsdale, AZ. The hike started out as a gradual ascension up the rocky grade and culminated with a stop near the base of one of the more sheer faces of the mountain. As we reached the trail summit (I really wanted to use the word ‘apex’ right there…I knew a guy in high school who wore Apex football shoes and I think of those shoes every time I hear that word…anyway…), we enjoyed a very beautiful scene as we looked down at the surrounding desert and countryside.

Then came the fun part: the descent. I was sucking some serious wind as we went up the trail, so having gravity help us down the trail was a small, yet welcomed reward for our hard work of getting to the top. So, because I didn’t have to work as hard to come down the mountain, my mind started to wonder. As we came down, you had to really bend your knees and watch where you were stepping in order to keep your balance and avoid big holes and rocks on the trail. The act of doing this quickly sort of made me feel like I was a contestant in some sort of obstacle course. Or, in a video game of some kind where you have to react very quickly in order to avoid harm. Two examples of games like this immediately popped into my head: Kaboom! on the Atari 2600 and Mike Tyson’s Punch Out! for the NES.

kaboom nes_tysons_punch-out_tyson
Kaboom!
(I would still have this game, but as a kid I loaned it to my neighbor and his dumb dad stepped on it and broke it. What a mook…)
Mike Tyson’s Punch Out!
(Seriously, I have beat Tyson before. 007-373-5963 proves it, sucka…)

 

Remember these games? They both require a quick eye and fast reaction time in order to win (or get a really high score). The more I thought about these two games the more I realized the same was essential for a good manager. This made me wonder how what I was doing might apply to software development somehow. Then it hit me: removing impediments.

As their manager, my teams present the impediments they face but can’t resolve on their own to me. Some examples might include team resource allocations, change processes (or lack of), or perhaps poor project participation from business users/beta testers. I try to resolve most of these issues as quickly as I can. However, at times some of them go on the lower half of my priority list. Obviously, those items that are critical to the team and perhaps the department should be dealt with as quickly and efficiently as possible.

Measuring the amount of time it takes a person to remove these impediments could be very telling of their effectiveness as a so-called impediment remover. In many cases, this could also indicate the organization’s tolerance for change and agility. I’m not sure if this particular metric has already been discussed within the agile world, so the only name I could come up with is Reaction Time: the amount of time it takes for impediments outside of a software development team’s control to be removed.

In his book “Agile Portfolio Management”, Jochen Krebs describes how to measure team morale as a metric for project performance. He suggests polling team members on morale, and then plotting their average morale vote on a line graph he calls a “Morale Barometer”. I would suggest that in addition to tracking team morale, charting either the ScrumMaster’s or the eventual “impediment remover’s” Reaction Time to removing impediments would provide a team a better idea of their overall agility. Just an idea…

Good product owners talk, b.s. walks

19 Aug

James sent me this link to a rant called “Business Requirements Are Bullshit”. This is the best blog post I have read in a while, and he makes some very good points about product owner selection.

One thing I took from the article is that you’ve got to have a product owner that knows what features they can get immediate value from. And if they don’t know, they should be able to tell you exactly who does know or who to ask. The more requirements “gathering” you have do on the onset of the project, the more it shows how little the collective project team knows about what features the users need to get value out of the system TODAY. Get the right people with the right knowledge on the team, put them in a room, and ask them what they need to make their lives easier.

The Squeaky Wheel

19 Aug

For a while now, I’ve been bothering the facilitator of the Kansas City IT Leadership Forum about leading a discussion on agile software development using Scrum. He must have been fed up with me asking, as I’m now on the schedule to talk about agile at the September meeting. The feedback I got was that the group might be more interested in agile from a conceptual level, rather than deep-diving into the specifics of Scrum. I suppose I’ll have to tailor my presentation a bit to make sure the content is appropriate for viewers of all ages. The other point he made was that this really isn’t a presentation as much as a discussion I will be leading. This might be challenging depending on the group’s collective knowledge of agile, so I’ll try to not dominate the conversation with ramblings of manifestos, principles, and practices.

I’ve also been grumbling about the AgileKC user group. So, at the last meeting I brought up some ideas for discussion topics, like “how does your company prioritize IT projects?”, and “who initiates IT projects, and what is the process they have to go through?”  Well, I managed to get myself on the hook to present our IT governance and PMO approaches at the September meeting. I’m actually looking forward to both the KCITLF meeting, and the AgileKC discussion. Both groups are well endowed with people much smarter than I am, so there should be some intelligent discussion and exchange of good ideas, most of which I will totally steal and pass off as my own.