8 Lessons From the First Scrum Team

A few years back I received a call from Stephen Denning, an Australian author best known for his books on organizational storytelling. Stephen wanted to talk with me about my work at Easel Corporation in the 1990s for his upcoming The Leader's Guide to Radical Management. Until Stephen called, I hadn’t thought much about Easel. But his interview brought all the memories of the “first scrum team” back, and with it a recollection of the lessons I took from Easel.

Background

I worked at the Burlington-based Easel Corporation for over four years in the early and mid-1990s, joining the company out of school and leaving it after its acquisition by VMARK. I was a software engineer on the team developing Synchronicity, a suite of software development tools based on our proprietary Smalltalk environment. I like to call this period of time my PhD in object oriented technology. Long before Hibernate, Ruby and Eclipse, we were building a modern development environment that included a dynamic object-oriented programming language, visual programming editors, integrated analysis and design tools, platform independent run time, two way code generation, object to relational persistence framework, local object store, and more.

When I first joined the Synchronicity team, it consisted of two other engineers: John Scumniotales, who came from our consulting group at Easel, and Gerd Eisenmann, a recently relocated German engineer from the ENFIN acquisition. Over the first year or two, we went through three VPs of engineering, eventually landing on Jeff Sutherland, who would become an early Agile evangelist and published the first paper on Scrum.

The team grew over the years, but never during my time exceeded 6-8 people. For a while we had Mike Morris from our San Diego office, Dave Hoag from Easel consulting, and Jeff McKenna, an external object oriented consultant. We also had several developers from a Danish consulting firm working with us. But throughout the time, we maintained a motivated and high performance team with a real passion for the craft of software engineering.

Top Lessons

So what did I learn from that first team? Well, during the call with Stephen Denning I realized that many of my instincts in building and running software teams actually drew from these early experiences.

So here are the top lessons I took as a young software engineer from the “first Scrum team”:

#1: Work With Integrated Cross Functional Teams

The Easel team was a tightly knit group that included development, quality assurance, and product management. One day our product manager, Don Roedner, took me aside to tell me how different this was from his previous experience. The tight cross functional integration allowed for a more rapid product development process, increased agility, and eliminated the need for more formal communication.

#2: Engage in Constant Communication

I don’t remember how or when it started, but soon after joining the team we were having daily synchronization meetings (post-Easel called "the standup”). Our team leader, John Scumniotales, facilitated the calls and drove the round table discussion of what we did yesterday and we would do today. These calls almost never lasted longer than 15 minutes, driven by a collective sense of urgency to get back our work. But the constant and ongoing communication maintained tight alignment and cohesion throughout all phases of building our products.

#3: Continuously Demonstrate Your Product

We adopted a ritual of showing demos to each other over drinks every Friday. We also worked in adjacent cubes, so informal demonstrations happened continuously. I remember looking over Gerd’s shoulders as he demonstrated his latest algorithm for graphically arranging an object model, and John’s as he showed his drag and drop prototype. Continuous demonstration are a better way to show progress than any project plan I have ever seen.

#4: Hire Continuous Learners

With good hiring and a little good luck, everyone on the team was a continuous learner. A former colleague told me this summer that some people read Steve McConnel’s Code Complete, but at Easel he lived it. We were constantly pushing the bounds of our learning through experimentation, reading and training. I remember ordering red books from IBM, and directly contacting industry experts such as James Rumbaugh and Grady Booch.

#5: Work Directly With Customers

More than once I flew to customer sites to develop my product. I remember sitting in a cube near the development teams using the product. I wouldn’t take this as a best practice, but I even made real-time modifications on-site that were immediately pushed into production usage by the customer. Building products with continuous and direct customer engagement ensures you never stray far from your core value proposition.

#6: Invest in Code Consolidation

I think it was Jeff McKenna who drove us to rigorously adopt code consolidation into our software development process. After key milestones, we allocated time to rewrite and restructure our code in order to keep it clean, lean and well factored. The investment in time was always well worth the result. I’ll confess: I too infrequently have leveraged the power of this technique in my teams.

#7: Create Mentoring Opportunities

Jeff Sutherland brought Jeff McKenna to the team as a part-time mentor. Since I was the most junior member of the team, Jeff McKenna spent enough time with me to be considered my personal mentor. He challenged my designs, reviewed my code, and prodded me to push the bounds of my skill and learning. Enabling formal and informal mentoring within a team will increase the productivity and effectiveness of engineers, and foster a culture of continuous learning. It is also a great way to advance the skills of your up and coming next generation of engineers.

I think we often dropped the demos from our Friday meetings and just had the drinks. I remember Mike Morris introducing us to the Brazilian drink cachaca, sushi with Jeff and the team, and playing networked Doom with engineers over beers in the late evenings. Granted we were all in our 20s and didn’t have families - but the regular social engagement fostered strong bonds between the members of the team. A high performance software team will often spend more awake time with their colleagues than anyone else, so it beneficial for teams to have the opportunity to be more than just colleagues.

Conclusions

To this day, I think Easel may have had the highest density of talent of any company in which I worked. Almost every member of our alumni group has stayed in the software industry, and many have had very successful careers. We also have many CXOs, VPs and startup founders.

Within this broader talent, the “first scrum team” was a young group of engineers from multiple nationalities that were bonded by a shared passion for building software. Having had the opportunity to work in a team like this at such a formative time in my career has impacted my approach and instincts in building software - something my Stephen Denning interview brought to my consciousness. I joined Easel as a college graduate and left as a seasoned software engineer, and for that I will always be grateful.

If you are interested in following former members of the Synchronicity team from Easel, you can find some of them here: @joekinsella, @jeffsutherland, @scumniotales, @jeffmckenna, @donr52.