Agile Challenges – Big and Small

I had the opportunity this week to spend a couple of hours talking about agile processes with several people from Sundog .  Sundog is a local consulting company with about 20 developers.  They help companies by developing solutions for system integration, process improvement, HR, and sales / marketing tools.

The visit is part of an ongoing effort by Microsoft, my team, and me to spend more time interacting with the development community.  I’ve led a handful of ‘customer visits’ where a small group will go to a company to learn about how their developers are using Visual Studio to develop business applications.  While this meeting was focused on Agile, we are planning a second meeting involving more Microsoft people to learn about Sundog’s development experiences.

Going into this meeting, I wasn’t sure how well my experiences would translate.  I’m working on a large team developing a product with a multi-year release plan that will be used by a large customer base.  Sundog is a comparatively small organization developing point solutions over a few weeks for a single customer.  While I have experience in smaller scale environments, it still was mostly product development.  But I also have enough experience working with consulting companies to have a decent feel for their typical projects.

It turns out that we had a really interesting visit and the time literally flew by.  We do share some similar challenges in implementing agile practices, particularly with engineering practices and team level project management.  What’s the best way to do code reviews?  Have you tried pair programming?  What’s your unit testing environment?  How do you test UI’s?  How do you share knowledge across team members?  What happens at a Daily Meeting?  And the list goes on…  Our two hour time together just scratched the surface of comparing notes.

One of the more interesting challenges that we share was one that I hadn’t thought about.  We have a big challenge in our agile implementation balancing Big Design Up Front with Emergent Design.  When you have several teams across multiple sites collaborating to build a product, you can’t leave system architecture to chance.  You have to do some level of design up front, and we have Software Architects and Senior Software Engineers writing up design documents laying out the high level design.  On the flip side, there are proven benefits to letting detailed design emerge iteratively over the life of the development process.  Finding that balance is difficult.

It turns out that Sundog has a similar challenge regarding design, but for different reasons.  They are usually required to do a fair amount of design work up front as part of the process of acquiring a customer job.  This design work is typically fulfilled by a System Architect role.  Once the consulting job is acquired, the System Architect will work with the development team to implement the design.  The bottom line is that Sundog needs to know what they are getting into and the customer needs to know what they are getting.  This will continue to be the case until customers are willing to sign up for an emergent agile process with less upfront definition and incremental funding for the project.

It’s great fun for me to visit with customers to talk about processes, architecture, and other development issues.  We invariably find a lot in common even if our domains might differ significantly.  So I guess I shouldn’t have been surprised about the common ground that I found talking to Sundog.

Skip to main content