The Michigan Agile and Beyond Conference brought 450 people together this weekend in Dearborn, Michigan to teach, learn and debate the broad subject of agile software development. The “beyond” part of the theme bothered me a little, for the same reason that it irritates me when I hear companies explaining that they do “practical agile”. Both statements miss the point that agile is about nothing more than delivering valuable software frequently and regularly. What can be more practical than that? Why do we need to move “beyond” that?

Ron Jeffries & Chet Hendrickson offered the best advice I heard all day in their opening keynote. Namely, to go beyond, you must travel through. Their point was that if you’re not in the “agile space” now, successfully using the core practices, then get there before you start tinkering or adapting. It reminded me of the debate in the early 2000s of whether you had to use all (then) 13 practices of XP to claim you were doing XP. Someone (might even have been Ron) responded that you’re doing XP when you’ve mastered all 13 practices and figured out which ones you need and how to use them on your project.

Chet cut straight to the chase when he said it matters what you do, because “agile isn’t any damn thing.” Ron followed that by quoting Emerson Codd: “The truth isn’t like a bunch of puppies running around where you chose your favorite.” Their talk was as casual, funny, and inspiring as always. They shared some of the simple truths about software development:

• Software development is all about people (Funny Ron quote: “When I got into computing, it was not with the intention of hanging out with other people.”) Tools can’t replace or compensate for people.

• Requirements need to get into the heads of the people building the software. Documents are a poor way of doing this.

• If you can’t ship working software every month, try two weeks. If you can’t do it in two weeks, try one week. You learn to build software by building and shipping working software.

• Waterfall doesn’t give you accurate information until it’s too late.

• If your software isn’t bug free, you can’t trust your velocity.

• If you’re manually testing everything your need for testers grows at least linearly with the number of iterations. You’ve got to automate some of those tests.

• If you can’t refactor, you can’t do evolutionary design.

They summarized by identifying the three non-negotiable core practices to being agile:

• Ship software regularly
• Test as you go
• Refactor to evolve the design

While their message, at least to me, was fundamentally one of “don’t forget the basics”, Chet and Ron also addressed the “beyond” part of the conference. They cited relationship to management, human resources, and dealing with projects that don’t fit in a single room as challenges that are still beyond the scope of accepted agile thinking. Ron called out Pillar Technology and Atomic Object as examples of companies pushing the boundaries of agile. They also reminded us that we have an obligation to share our experiments, both our failures and successes, to grow the body of agile knowledge. Chet added that these experiments push agile into new territory, but are still grounded in the simple statements of the Agile Manifesto.

Later this month, Shawn Anderson will be going back to Cali, his previous home, to make back-to-back presentations at two different conferences: LA RubyConf and SCALE (the second time in two years). For both, he is presenting on developing 2D games using Ruby and open source tools (including a library that he wrote).

Read the rest of this entry

Last weekend I had the privilege of attending a UX Agile Retreat at Cooper. The retreat was an informal event where ~33 practitioners from the UX and Agile fields came together to discuss how we can better create effective and successful products. The event schedule was loosely defined and it self organized based on the trending topics. We used a variety of exercises and discussion techniques to voice our experiences, concerns and ideas to help build a vision of a better, collaborative future.

Where We’ve Been

The UX and Agile communities have been flirting with how they could integrate their practices more seamlessly and respectfully. Both groups respected one another yet remained uneasy about having to alter their respective approaches for an integrated vision and process. UX Designers were worried that some of their practices would be minimized or marginalized due to Agilistas’ strong belief of minimal upfront design. Fear existed that quality design would be sacrificed to the almighty iteration once an agile project was underway. Agilistas were worried about designers doing too much work up front without creating functioning software. Developers were ignorant of the UX Design process and the immense value it provides. Individuals, like Jeff Patton and Lane Halley, have been working very hard to increase knowledge and respect between the two groups. Anders Ramsey organized and dedicated himself to making last week’s event happen. He did an outstanding job. The UX and Agile camps are coming together because they recognize and respect each other’s dedication to the craft of creating high quality products.

Where We Are

Most of our discussions during the retreat focused on vision, values and principles instead of outlining a strategy for collaboration. I’m glad the group was able to remain focused at such a high level because good process stems from alignment and a mutually shared vision.

We took a stand that the “Us and Them” mentality is dead and that we have to move forward as “We.” Management and business processes have kept our groups apart in the past due to a focus on efficiency and a misunderstanding of what it takes to create successful digital products. Management often times does not know how to ask us for what they want, nor do they know how to properly manage creative teams. We believe that we can create better products more efficiently by focusing on being effective. We believe that effectiveness is increased by working together closely.

The Future

The new vision is forming. The retreat group is committed to evangelizing and furthering this vision. I left the retreat with strong feelings of alignment, momentum and excitement. We are the makers of amazing, complex things and we are taking a stand on how we’ll bring the dreams of others into the world. We’re building a case for businesses to employ design thinking at all levels, to focus on the satisfaction of their customers and and to let individuals who understand the creative process to manage it for effectiveness.

Atomic Object will be kicking off the Code Retreat 2010 season by hosting a retreat in Grand Rapids, MI on February 6th at Atomic HQ. "What is a Code Retreat?", you ask? Code Retreat was dreamed up by Corey Haines, Nayan Harjatwala and Patrick Wilson-Welsh during some spare cycles at the Codemash v.2.0.0.9 conference. They wanted to create an event that would allow software developers to gather and practice their craft away from the pressures of writing production code and delivering business value. It would be a place where developers could come together and improve their ability to write clean and responsible code and ultimately improve their ability to deliver more business value to customers.

Read the rest of this entry

Last month Shawn Crowley and I attended the Business of Software Conference in San Francisco. This was one of the best software conferences that I have ever attended. It was unique because it brought together a strong collection of software company founders and top management. Most of these companies worked in B2B vertical markets that did not compete with each other. This lack of direct competition helped facilitate great conversations in which conference attendees openly disclosed company success and failure stories.

My favorite part about the conference was a key note talk given by Geoffrey Moore. Moore is widely known for his successful book Crossing the Chasm. During Moore’s talk he discussed a few types of software projects. I believe that the same principles apply to features of software products.

Differentiation – A differentiation project does something different than the competition. If done correctly it gives the organization enormous bargaining power.

Neutralization – A neutralization project focuses on meeting the market norm. It is not about outperforming your competition. The goal of this project is to make your organization competitive by offering a similar feature set.

After describing these project types he went on to discuss how it is very common for both of these types to lead to organizational waste. Moore used a similar image to the one below to describe this concept.

Differentiation Waste – A differentiation project becomes wasteful when it is not taken far enough. Since these types of projects require innovation and lead to high bargaining power they come at a high cost. Moore’s advice for these types of projects is that an organization should be willing to spend twice as much as they anticipated to really make this type of project a success.

Neutralization Waste – A neutralization project becomes wasteful when the project goes too far. Moore discussed that adding additional bells and whistles to a neutralization project will gain applause, but until it reaches a certain level of differentiation the customer will not pay more money for the extra effort.

An example of how a neutralization project can be wasteful could be a simple login feature in a web application. Most modern web applications have the ability to login and reset the password. In order for a product to compete it must invest in login functionality. Once the development for the login is complete it becomes very tempting to improve the feature. Perhaps, adding avatars would be interesting. Before investing the development resources in this additional feature the project team should consider if adding the avatar feature is a differentiation, or if it will take more than just the avatar feature to make the product more valuable to the end customer. If the team is not willing to take the feature far enough to differentiate then maybe it makes more sense to have the team work on something else instead. The area after neutralization but before differentiation is waste.

Understanding the difference between these two project types was very enlightening for me. Knowing what type of project or feature you are currently developing helps answer the question of how much is enough. Challenging our customers on this idea helps us provide maximum business value.

I recently attended JRubyConf in San Francisco. The conference definitely had a strong web presence, but it wasn’t without a few “web neutral” presentations. The JRuby State of the Union, The JRuby Testing Story, and some of the lightning talks were interesting and fun.

Phil Hagelberg gave a brief presentation on Clojure’s Software Transactional Memory and how it can be used within JRuby. He wrote a small library that exposes and wraps the necessary STM components in the Clojure Java implementation. I briefly experimented with library, and it appears to work quite well and could provide immediate value to multi-threaded applications.

Read the rest of this entry

Last weekend I attended JRubyConf 2009. Overall I enjoyed the opening JRubyConf State of the Union, the follow-up JRuby on Rails, and the concluding JRuby Core Team Panel sessions the best. Despite browsing the JRuby mailing list as part of my daily routine, JRuby has a rapid development cycle; these sessions helped me get a clearer view of the JRuby team's current development goals.

I am curious when and how JRuby will take advantage of the invokedynamic and method handle technologies coming with the next Java platform release. After reading John Rose's paper Bytecodes meet Combinators: invokedynamic on the JVM, it sounds like language implementors will need to make a significant development investment if they want to fully utilize the new features. Charles clearly has a strong grasp on the new features. He's already tried out and given feedback on them, so I'm sure he'll be on the forefront of an implementation changeover. Still, I wonder what kind of timeframe we're looking at to go from the simulated method dispatching we have now to a fully fleshed out invokedynamic-backed implementation.

November has been a month of conferences for AO. First, there was GLSEC (Great Lakes Software Excellence Conference), an event put on by SoftwareGR (formerly XP West Michigan) dedicated to improving the competitiveness of Michigan’s software development community. In addition to our involvement with GLSEC, the two weeks leading up to Thanksgiving have seen six atoms attend five different conferences, from JRubyConf in San Francisco to the World Bank conference in Cape Town, South Africa.

Read the rest of this entry

On September 22nd, Atomic Object co-founder and president Carl Erickson will be the guest speaker at the Lakeshore Advantage e2e Series. Erickson, who served as a professor of computer science at GVSU for 10 years prior to founding Atomic Object in 2001 will be presenting "When a professor has to start a company: the story of Atomic Object."

Since its 2001 inception, Atomic Object has continued to grow. Posting a consistent yearly revenue growth, and now employing 24 full-time employees, Atomic Object serves as a model for software startups. By focusing on maintaining a diverse clientele, quality, and the needs of customers, Atomic Object has achieved success and earned a national reputation for excellence.



The e2e Series, which stands for "entrepreneur to entrepreneur", focuses on connecting business leaders of today with the entrepreneurs of tomorrow. Erickson's story and success will undoubtedly inspire and motivate his audience, comprised largely of young professionals, to take a bold step of their own.

The free event starts at 5:30PM (refreshments provided) and is hosted courtesy of Lakeshore Advantage, a full service startup incubator. For more information, please refer to the event website.

Greg and I attended Embedded Systems Conference Boston 2008 a couple weeks ago. We presented an Agile Project Management class and a session on Feature-Driven Design with our friend and colleague Mark Vander Voord.

It was a markedly different experience this year versus last.

Read the rest of this entry

I had the pleasure of attending the IDEA Conference last week in Chicago. IDEA is sponsored by The Information Architecture Institute and is an annual conference about "Information: Design, Experience and Access." This conference was very timely for me as I have been moving into a product development role at Atomic that is more focused on product design than software development. Although IA encompasses only a part of user experience design, I have found that most of my user centered design efforts have been focused on building enough understanding about users to eventually model an information architecture that a client can approve and a visual designer can work from.

The conference was definitely thought provoking. I found most of the presentations rather abstract but there were definitely some practical connections made. Coming from a development background very focused on process improvement and toolsmithing, I was expecting to hear more about experience reports, metrics, and process innovation. I got the sense that day-to-day tools and techniques were covered in the workshop, (I was unable to attend the pre-conference workshop as it had sold out before I registered), and that conference was more of a forum to explore higher order observations.

I was very happy with conference overall. I was able to attend some very interesting talks and network with other professionals in the field. The conference was very well organized and I appreciate all of the hard work done by the volunteers and The IAI.

I had the opportunity to attend Apple's World Wide Developer Conference this past June. I attended the conference to learn about and gain experience in iPhone development. Most of my time was spent in the iPhone Lab and iPhone development presentations and sessions. I thought most the presentations were informative and well presented and I came away with a lot.

My only complaint is that Apple would not talk about or even acknowledge the more complex areas of sample code in their presentations. It was obvious Apple was focusing on making iPhone development look very easy through and through. And compared to other mobile platforms it is easier. However I wish they had spent some time going into the more complex, non-apple abstracted code that actually takes some time and thought.

The development experience is a good one. The language (Objective C), iPhone SDK and the development tools are well done. Objective C is a powerful object oriented language and the iPhone SDK is well abstracted and easy to use. If you need access to the more low-level API's they are readily available. Interface Builder is spectacular and it puts other interface/view building applications to shame. Xcode is still way behind other IDEs but it is very usable nonetheless. Their performance and debugging tools are excellent. Even when your code is well formed and well tested you have the potential to have memory leaks, and their memory leak detection tool is great for that kind of problem.

From a professional development standpoint the platform is ready to go. A developer can test drive their code using OCMock and OCUnit. If you prefer a different testing platform I recommend looking into rbiphonetest.

I was able to successfully create an iPhone application using Atomic Object's Presenter First style of development. However, bootstrapping the application becomes problematic when the application uses a great deal of composition. It would be nice if a dependency injection framework existed and was available for iPhone development. However, it is possible to use Interface Builder to instantiate all of the singletons in the system and inject them, which could be an acceptable alternative.

Video from my presentation at RubyConf 2007 (Enhancing Embedded Development with Ruby) is now available at the Confreaks website.

See the full video

I’ve just given this presentation at Rubyconf 2007. And now you can enjoy it too:

Keynote file: Enhancing Embedded Keynote

PDF version: Enhancing Embedded PDF

Video: Full Video from Confreaks

Atomic and our developers invest a lot of time in professional development. Everyone attends at least one conference or workshop each year. This year we presented at or attended the following:

• Austin Workshop on Test Automation
• Embedded Systems Conference
• Rails Conference
• Dr. Dobb’s Architecture and Design World
• Agile Conference
• O’Reilly Open Source Convention
• Google Test Automation Conference
• Ruby Conference

The October meeting of XP West Michigan featured “what I did on my summer vacation” talks from Atomic Object developers. Five atoms gave short, informal talks on interesting things they learned at recent conferences. Read the rest of this entry