Transparency is a word often used by politicians when one of their own has been caught in a corruption scandal or “fails to serve the public interest”. The offending individual is put out to pasture while the rest of his colleagues go into a spasm of self-righteous openness and transparency. Although it’s a vital concept for any well functioning government, the concept of transparency in public service has been over-used and the promised reforms never seem to arrive. In short, the push for political transparency is often a bit, well, transparent…

Transparency for a software company is an entirely different matter, however. With the relentless flux of technical advances, customer demands, competitive challenges and new business models, it’s often a real challenge to give customers and partners a transparent view of your organization’s plans. Just ask Jim Allchin at Microsoft how easy it has been to manage expectations around the release of Visual Studio 2005 or Windows Vista, for example.

You could argue that Microsoft hasn’t managed the process particularly well at times, but there’s no doubt that product releases are a complex and difficult problem for any software company to solve. That’s why I’m particularly pleased that we’ve made a real breakthrough with the new InnerWorkings product roadmap. This roadmap came together after many weeks of planning and lively debate among the various stakeholder groups in the company, and there’s not a shrinking violet among them. The final version was released only a few hours ago, so it’s truly hot off the press!

The new roadmap spells out InnerWorkings’ commitment to keep our customers, partners, and (most importantly) developers in the know about what technologies we’ll be tackling over the next 15 months. With sign-off from our R&D, client services, sales, and marketing teams, this roadmap is our best attempt to bring some much needed transparency to the company’s future release plans.

I hope you’ll agree that it makes for good reading too, with pending releases on WinFX, Windows Workflow Foundation, Windows Communication Foundation, Enterprise Library Application Blocks, and the Atlas toolkit. We’ve even included some tentative Visual Studio Team System (VSTS) challenges in areas that can be validated by our code-centric judging engine. I’m pleased to say that all this new material will be delivered on top of our existing customer commitments to support ASP.NET 2.0 Web development, Windows Forms, and SQL Server.

Our goal with this new roadmap is to provide fresh visibility into the release process for anyone with an interest in the company. It’s also intended to allow us considerable flexibility to respond to burgeoning technologies (like Atlas) based on emerging market demand. For these reasons, we’ve defined 3 primary release categories for all InnerWorkings Drills in the new roadmap:

• Expected Release Date (0 - 3 months)
• Estimated Release Date (3 - 6 months)
• In Planning (6 - 15 months)

If you’d like to receive a copy of the new InnerWorkings roadmap, please send an email request with “Roadmap” in the Subject line to roadmap@innerworkings.com. You’ll notice that there is a customer feedback loop built into the new roadmap, so please send your thoughts directly into our Product Marketing team.

Although it’s a bit nerve-wracking to open out our 15 month release schedule in this way, there is a true commitment among all groups in the company to this transparent release process. And unlike the politicians, we plan to keep it that way!

Add this post to:             

Writing about muffin morning was fun, perhaps because our current sessions are very enjoyable.
As I will gain more understanding of the forces at work and the wide implications of this simple practice, I will update the pattern with the new findings.

By the way, if you are implementing it (or considering putting it into practice) within your team please share your thoughts!

For my future reference, I want to add a few points that I haven’t covered in my previous post, mainly because a pattern should be based on observations rather than speculations.

So what did I leave out? Many things for sure, but for now I only have this list:

• Environmental factors conducive to this type of activity
• Relations/interactions with other practices, for example daily stand-up meetings
• Higher management perception/acceptance
• Pressure/deadline handling
• Basic financial support and equipment
• Team size/composition/roles and correlation with volunteer availability
• Finding engaging topics on a regular basis (experiences on the job, technology/product/process, dept vs. breath of coverage)
• Format (lecture, open discussion, study group, etc)
• Time management (preparation phase, delay, overtime, rescheduling, recurrence)
• Session/topic follow-ups
• If/why/how-to involve other teams

In all the cases I just mentioned, I either don’t have the problem or I don’t have conclusive data, solutions or suggestions.
At least, not yet :-).

Add this post to:             

At the software architecture workshop held in Cortina last February, JC Oberholzer mentioned that he has been doing a special meeting on a weekly basis for the last three years, with the aim of sharing technical information and improve the morale of his team.

In the past, I thought several times about doing something similar but I was never quite sure it could work out in a sustainable way; JC’s example, however, inspired me to try it here at InnerWorkings and, after successfully testing it for almost three months, I can certainly announce that not only it works for us, but it's becoming part of our DNA!
Would you like some details?

Ladies and Gentlemen let me introduce you a half-baked (bun…oops…pun intended…ok stop!) pattern that you will never forget:

Muffin Morning

Software developers mature distinct experiences and learn technologies and techniques that can be relevant to others in their team.

How can I share technical information across a team/organization and encourage a healthy self-learning culture?

The most effective developers generally invest a significant amount of their own time researching new technologies, seeking optimal solutions to problems and continuously improving their skills; this is hardly surprising given the rapid transformations that the software industry imposes.

What is needed is a way to encourage team members to share technical information with others.

Volunteer to illustrate and debate a technical topic relevant to the team on a regular basis. Encourage others to do the same by keeping things simple and very informal. Meet for an hour every Friday morning without exceptions, and provide muffins, doughnuts, coffee, etc.

The most important thing to keep in mind with muffin morning is that if presentations become too formal, too long or elaborate, few will be able to contribute as it will require too much preparation; a team deadline could easily break the regularity of the event and muffin morning would become nothing more than a failed experiment.
As a consequence, PowerPoint slides should be absolutely banned and the urge to show live code examples on a projector carefully considered.
I personally find that the most successful presentations are the ones that use a whiteboard only, as they encourage a greater dialog and instigate curiosity to find out more about a particular topic.

One of the biggest attractions of muffin morning is its capability to involve several team members in a communication and self-development exercise.

Independently from their presentation skills, volunteers are almost invariably cheered and supported by the rest of the team since they earn the respect of their peers for their courage and effort.

While volunteers have usually enough interest and understanding of a topic to be able to illustrate it to their peers, it is not expected for them to be experts on the subject. Indeed, often some other team mate may happen to have more experience or knowledge about the subject and consequently play a supporting role for the event.

Add this post to: