Home » Uncategorized » Field Trip: Epiq Systems
May
13

Field Trip: Epiq Systems

This week I got a chance to do one of my White Light Computing Field Trips. This time I was invited to spend the day at Epiq Systems in Kansas City. I was in town to present a couple of sessions at the Midwest FoxPro Users Group, and Doug Carpenter was kind enough to share his office with me on Thursday.
 
Epiq is a company developing software solutions for the bankruptcy industry. They are using Visual FoxPro to develop both Web solutions and workstation solutions, and do some .NET too. I was interested in how a large team developing with Visual FoxPro successfully implements the Agile methodology for software development.
 
Each developer has their own office where they can isolate themselves. This initially looked contradictory to the typical agile environment where collaboration is so important. Each office is designed so developers can do pair programming. In fact, Doug showed me something I have never seen before on a desktop computer: two keyboards. This is very cool because both developers can be involved in the development. I am a fan of pair programming when working on difficult code, debugging a sticky problem, and doing design. One of the things I dislike about pair programming is one developer usually hangs out over the shoulder of the other developer. It is my experience that the developer on the keyboard is usually doing more work and the sidekick can lose interest. I think the dual keyboard forces both developers to remain engaged.
 
The team invited me to sit in on the “scrum” or “sprint”. This is a daily team meeting. I really like this concept. This meeting is very short, which is real different from the normal team meetings I have been in during my career. The team includes developers, program managers, and quality assurance. Each member reviews what they have done in the last day, noting accomplishments and road blocks. A spreadsheet with the tasks are updated live during the meeting to show completed tasks and remaining work. Program managers can determine where they are in the big picture, understand accomplishments to meet the next release, what remains, and can address the roadblocks after the meeting. The quality assurance team can bring up concerns with the latest build (done daily or more frequently as needed).
 
It reminded me of my days at EDS when I worked with a team focused on delivering products for GMAC. We did not use the Agile methodology at EDS, but we used many of the concepts now recognized as best practices in the Agile methodology. This meeting reminded me of the importance of teamwork and the fun one can have working on a team focused on the same goal.
 
The other observation I had is how well the team works together. The quality assurance folks help the developers, and the developers help the quality assurance team. Management works to make the team successful. The Visual FoxPro developers and the .NET developers respect each other.
 
Epiq Systems is run smart, at least from an outsiders perspective. I learned a couple of things I would like to implement at White Light Computing as it grows. It was another day well spent on the road.
 
It was a great day in the windy city (yeah, KC was windier than any day I have spent in Chicago). Thanks to Doug Carpenter for all the hospitality and for the team inviting me to lunch and to the “sprint”.
 
Also a special thanks to Lou Harris for loaning me his Staples Easy Button for my presentation at the user group that night. Lou attended one of my Help Made Easy sessions at Southwest Fox last year and was the recipient of one of the Easy Buttons I gave away. Little did I know I was planting one in KC so I could borrow it six months later {g}.

2 Responses to “Field Trip: Epiq Systems”

  1. Anonymous
    May 15th, 2006 at 12:10 | #1

    Rick,

    You should take a look at a fairly recent MS Webcast about playing the TDD game. The idea was to keep both members of the pair interested by context swaping. For example, one would write the test, the other would write the code.

    Then after a user story is implemented or perhaps at some other interval they would switch. This keeps both guys engaged in the process at all times.

    Bob Archer

  2. May 15th, 2006 at 16:25 | #2

    Enjoyed both Rick’s article on the Pair Programming at Doug’s company (sounded very cool, neat and effective!) as well as Bob Archer’s comment, which sounded like a great idea as well.

    One day perhaps I’ll be lucky enough to be in a similar environment.

    –Michael

Add reply