I walked passed my 11 year old son’s bedroom the other day and saw him kneeling down in front of his desk frantically typing away on his computer keyboard. Puzzled where his chair might be, I made a mental note to check on that when I had a moment. Almost two hours later, I returned only to find him still kneeling there. Curiosity getting the better of me, I went in and asked him what he was doing. He answered that he was finishing up Level 14 of a game. Only he wasn’t playing this game—he was designing it!

For a while now, my son has been spending a fair amount of time with a program called Scratch. Scratch is a visual programming language which strives to make programming more engaging and accessible to children, teens and others who wish to learn programming. The concept is quite simple. To create a game program the user snaps blocks together into stacks. Blocks are designed to fit together only when it makes syntactic sense. The result is a program that controls and mixes graphics, animation, music and sound. And then, to top it off, creations can be posted to the Web site so that others can sample or even collaborate on each others work.

Scratch also allows users to learn important computation concepts such as iteration, conditionals, variables, data types, events and processes. Besides being a lot of fun, many kids take it to the next level by moving on to actual text-based scripting languages. Several research papers have been written about this.

The program is built on top of the Squeak programming language and is an open source—but closed development—project spearheaded by a team of researchers at the MIT Media Lab.

Download Scratch.

Last night was our first ever Ann Arbor Software Development Study Group and it was a lot of fun. The group was split into pairs and given non-programming problems to solve using specific problem solving techniques. They gathered at multiple white boards and had to show their work. The problem set came from a K-12 Problem solving curriculum, so although not hard, they still challenged some of our smartest people in ways I wouldn’t have imagined. All in all it was a perfect kick off to what I think is going to be a very successful group.

Next week, Andy Seidl will be leading us in XLS. Study group is strictly 1 hour and takes place from 5:30 - 6:30 every Tuesday. Please check our Syllabus for times and topics.

I recently started attending monthly meetings of a group called Michigan Agile Enthusiasts. Because of this I’ve been reminded again about the benefit of spending time with like minded professionals to discuss methodology, useful practices, and cool agile stuff!

The current President of MAE is Chris Beale who is a Vice President for Pillar Technologies and is also a highly respected agile professional. Chris and the MAE team do a good job of providing quality speakers, great networking opportunities and tasty hors d’oeuvres.

At my first meeting the speaker was Elisabeth Hendrickson whose business card reads, and I quote,

“founder, president and
Test Obsessed Agile
consultant and trainer.”

She is a founder of Quality Tree Software, Inc. in Pleasanton, CA. She was, apparently, passing through town and accepted our invitation to speak. She presented some interesting ideas on expanding Test Driven Development (TDD) beyond standard unit testing to include Acceptance Test Driven Development (ATDD) and exploratory testing. It was a great talk and really got me thinking about enhanced testing practices.

At the most recent MAE meeting some MAE members, Nayan Harjratwala and Aimee Keener, presented a comparison of agile methodologies Scrum and Kanban. As an agile software professional I am, of course, familiar with Scrum. And, as a former auto company employee, I had at least heard of Kanban. But I’d never seen Kanban applied to software development projects before. Kanban is one of the lean methodologies originating in the world of discrete manufacturing. It takes the agility of Scrum and refines the granularity to the point where each individual task/story/backlog item has it’s own development path and velocity. Very interesting!

What Nayan and Aimee demonstrated is that all methodologies have strengths and weaknesses. If your software development practice is very process oriented and more or less discrete, Kanban may be an excellent choice to enhance control and “lean out” your work.

What does all this mean? It means if you’ve got a free Monday evening and want to get in touch with your agile comrades, you should find out where the next Michigan Agile Enthusiast meeting is and head on down! The two meetings I’ve attended were held at Bastone Restaurant and Brewery in Royal Oak. However the meeting spots change so check the MAE site at agileenthusiasts.ning.com to be sure of the time and location before leaving home. Also be sure to follow our user group calendar for other interesting meetings at http://bit.ly/StoutUGCal.

I have to admit that I used to love Microsoft Project. And I have two project managers on my staff who still love it (or at least like it). They both tell me that I would love it if I took some time to get some training on the application.

Okay, I believe them.

But before I take of a few days for training, I ask this question: Is there any other software development project management tool out there that people love? I mean REALLY love! I want something that’s easy to use, intuitive, and Web based so that I can run my distributed teams. I’ve tried a couple of Web based tools, and they had features I liked, but performance (speed) was poor because of unoptimized AJAX implementations and other similar issues.

If you have a favorite tool, I would love to hear about it.

I’ve always been confused by the artistic movement known as post-modernism. “If modernity is the state of things at their latest,” I would think “how could anything be post-modern? Is that like being post-today?” But lately I’ve been thinking in “post-modern” terms about software development methodologies, specifically Scrum.

We all know about Scrum – the software development paradigm where the team, rather than the project manager, sets the direction and works closely with the product owner to prioritize the work. It is one of the agile methodologies that takes software development back from the pencil pushers and places it squarely in the hands of the techies. At its best it provides a flexible, iterative platform for high quality collaboration between developer and customer. Why, then, would I think about anything “post” Scrum?

To answer that question I need to go back to the origins of Scrum. It was originally a response to other, more antiquated methodologies. We all remember the days of waterfall projects where months (if not years) were spent gathering requirements, writing project charters, and creating massive projects plans before a single line of code was written. In fact, many such projects are underway today. We also remember how those projects often delivered solutions to problems that had evolved into something entirely different—in essence answers to questions no longer being asked.

Iterative methodologies like Scrum were seen as a way to keep project teams from going whole sale in the wrong direction. The close relationship between team and product owner, along with shorter development cycles and focus on production ready code, would guarantee the solutions were always a direct response to the most pressing current business problems.

And it works! Scrum has proven that software developers desire to and can produce excellent results when unburdened by management intrusion and needless paperwork. A high-functioning Scrum team can produce chunk after chunk of production ready code that is a direct response to customer needs. Product role out meetings often include tear filled eyes and group hugs as product owner and team bask in the glow that is their mutual creation. What could be wrong with this?

Well…it’s not that anything is wrong, per se. It is just that Scrum, like the earlier methodologies, has its own … um … issues. First, Scrum requires that a development team be co-located to maximize team collaboration. This, alone, is not a show-stopper. However it is increasingly improbable in the age of distributed teams working via online collaboration. Is it really a daily Scrum when coffee and donuts have to be shared through Live Meeting?

A second, thornier issue is that Scrum requires real personal fortitude from the management ranks—something not easy to come by. For example, programmers are supposed to work without interruption during development cycles. That means production support be damned! Or at least re-assigned. Also management has to get comfortable with the idea that a team can’t say exactly what will be delivered or when—only that the customer will be included along the way and will be thrilled with the results. Try selling that to your CIO as he or she wants to review your earned value in detail while demanding that your team get “more agile” (real world example).

All of this takes on new complications in the consulting arena. If internal management isn’t big on fuzzy delivery dates and functionality, try selling them to a prospective customer. Software consulting companies absolutely cannot adhere to a methodology that precludes accurate estimating and reliable delivery. This says nothing of the distributed nature of most companies today. For example, I recently worked on a proposal project with team members in the Midwest, the Southwest US, the UK and Hong Kong. Not only were we not in the same place, we were not in the same time zone! If co-location is required for Scrum, how can this model ever work?

These are just some of the issues we face implementing Scrum in today’s consulting environments. So, am I recommending we forget about Scrum? Not at all! I believe in iterative development and Scrum is the best I’ve seen. But I wonder how Scrum can evolve to meet my everyday reality. How can this flexibility be combined with accurate up front estimating? How can we realize the increased customer satisfaction of Scrum and still deliver on our original promises? Is team collaboration still effective when done virtually? And how can this type of project ever be managed?

I have some ideas of my own on this. But I’m also interested in what others have to say. Any takers?