One of the things I enjoy the most about being an industry analyst is that I've spent the past six years meeting some great developers. Personally, I’m not sure I could cover any other technology area then application development. The reason is simple: I see developers as a worldwide force for good (It's almost axiomatic, as the bad apples become "hackers"). Developers innovate, they create, they push technology forward — and they are fun to go have a beer with at the end of the day.
While writing for developers is fun, it’s not always easy. For the past few years, my topic coverage areas have sometimes felt a bit disjointed — almost as if there are two different developer communities out there that I deal with. In the past, I've referred to these groups as the "inside the firewall crowd" and the "outside the firewall crowd." The inquiries I have with the first group are fairly conventional — they segment as .NET or Java development shops, they use app servers and RDBMSes, and they worry about security and governance. Inquiries with the second group are very different — these developers are multilingual, hold very few alliances to vendors, tend to be younger, and embrace open source and open communities as a way to get almost everything done. The first group thinks web services are done with SOAP; the second does them with REST and JSON. The first group thinks MVC, the second thinks "pipes and filters" and eventing. I could go on and on with the comparison.
To pick up the narrative from my last post, we're currently one week into the First Robotics build season for 2012. Team 811 is busy working away on an initial sprint. The goal is to get a minimum viable product (a drivable robot) up by the end of sprint one, which will then be used as a base to move toward a competitive robot that can play this year's game, Rebound Rumble.
So how did Team 811 get from "huh?" to full-speed prototyping in 4 days? How does anyone get 40+ teenagers moving in the same direction when the number of unknowns is significant and the problems to solve look insurmountable? For team 811, the key was starting with a 3-day process called "Collaborative Problem Solving (CPS)." Think of it as a pre-sprint process to build team buy-in and reduce downstream back-biting and second guessing.
So what is CPS? It's a technique that starts with a problem statement and then encourages divergent thinking to brainstorm creative solutions to that problem. Criteria that allow evaluation of those potential solutions are then applied by the entire group. This starts a process of combining divergent ideas into stronger overlapping concepts and identifying those ideas that have the strongest combination of feasibility and ability. The result would be recognizable to many agile teams: a burndown "punch list" of items and strategies to drive early prototyping and the team's first sprint.
Does this same sort of thinking apply to software and systems development processes? I'll tell you why I think it does. For the past three years I've been a mentor for a US FIRST Team (Team 811, the Bishop Guertin Cardinals). During this time period, I've seen high school students with little to no technical experience instinctively adopt many principles that experienced Agile teams would recognize. For these kids, Agile development is like using an iPad - they take to it naturally because it just makes sense given the context of what they are trying to do.