Immersed in agile

I started working as an independent contractor for Pillar Technology over 6 months ago (Nov 1, 2010). At the time, I had no idea what was in store for me; looking back now I think I’ve hit a new point from which to grow in my career so it seems time to engage in a retrospective on the last year.

Some History

Prior to working with Pillar I spent just over 2 years working on a number of projects at VendAsta Technologies. I grew a lot in those 2 years but mostly in a technical capacity. Things like continuous integration, build configuration, and (briefly) unit testing were introduced to me. It was enlightening to get a taste of the technical goodness offered by those things but ultimately I felt like there was no one there who could guide me in the underlying principles that necessitate them. At the same time I was introduced to many of the core concepts of this thing people in the software development community call “agile”. Coming out of VendAsta in 2010 I thought I knew what agile was. I thought it was Scrum, XP, TDD, continuous integration and a whole host of other technical terms.

Looking back at where I’ve come in the last 7 months I don’t think I can say I know what agile is even now, because it is an ephemeral thing that seems to be constantly evolving. What I can say is that I know a lot more about the core of what’s important in software development: delivering business value and earning the trust of those you work with.

Trust and Value over Working Software

My first 6 months with Pillar were served working on a client project for Gordon Food Services out of Grand Rapids, MI. I worked remotely for those 6 months out of an office in my basement that Tanys and I built the week before I started. A brief note on working remotely: it opened my eyes up to a key thing that’s required to be successful in life; self-discipline. I had my doubts about how effective I could be remotely but I decided it was worth the challenge and committed to myself that I would do what it took. Getting up at 7 am to make standup in the morning (hello, 2 hour time zone difference), pushing myself to keep lines of communication open, and pouring my heart and soul into building trust with the client; these are the things I did over those 6 months. And it paid off. I grew in my technical knowledge but also in my ability to cultivate good business relationships.

The people at both the client and Pillar have been great, providing much in the way of the mentoring and leadership around the principles of good software development that I had craved for such a long time. In 6 months working for GFS the team I was part of a team that produced software faster, with less defects, and with more value than any other project I’ve been on. The experience was energizing and opened my eyes to the power of building trust and constantly delivering value all while adhering to solid software craftsmanship principles.

Beyond TDD

Prior to joining Pillar I thought I had a pretty good grasp on the technical concepts surrounding “agile”. 7 months later my eyes have been opened to how much more than technicality agile really is. At its heart, agile is a way of thinking that promotes accountability, integrity, quality, and value oriented thinking. I used to think writing tests was something you did after writing production code to verify the behaviour you had crafted. Now I understand that “The fundamental conundrum of software development: I can code fast when I have a good design but I can’t design until I’ve coded slowly.” (Kent Beck).

A good design is achieved by thinking out architecture by writing tests first. I’ve also learned that tests can act as documentation by example, so it’s important to continually curate test code so that it doesn’t grow stagnant. Most importantly of all I’ve seen the power of having a codebase with 95%+ test coverage and how that acts as a safety net to making change. This last point can’t be overstated; the freedom experienced through red/green/refactor makes change cheap and development incredibly enjoyable. At the core of my change here from 7 months ago is a paradigm shift in the way I think about developing: I don’t feel responsible writing production code until I have a failing test.

The Best Way To Learn

Something I’ve always felt positive about is my ability to teach. I feel I have the heart of a teacher, which means that I can empathize with people to understand the pain they feel. (I’ve felt the pain too, which always helps). In the last 7 months I’ve been devoting myself to studying more effective ways to promote craftsmanship in front-end development. One of those ways is to teach more. This has not been easy; front-end development has historically been treated as a second class citizen. (I could write a whole other blog post about that alone, but that’s a topic for another time). Breaking down barriers between front-end and back-end developers requires a certain amount of grace and poise that I didn’t have 7 months ago. Being able to effectively communicate solid engineering principles to back-end oriented developers requires empathy, compassion, and the ability to communicate using language they understand.

I’ve often had to put aside my idealism and promote compromise. I’ve also had to become humble and admit that sometimes the front-end is not the place where everything should live. (But I still think there’s a whole lot of logic on the server that shouldn’t be there. Again, another topic for another post). The benefit to engaging developers across architectural boundaries and striving to teach is that I’ve been able to learn a lot. I’ve learned how to effectively test drive JavaScript (/hattip @searls), how to build scalable, object-oriented CSS/HTML, how to achieve an appropriate separation of concerns on the front-end, and how to translate n-tier architecture principles from the server-side to my client-side code. Being at a company like Pillar has provided a rich environment in which to grow; it’s something I’m very grateful for.

The Path to Agility

Many of my co-workers attended the #pathtoagility conference in Ohio this week. I wasn’t able to attend but I think it’s fitting to end a post about my own personal “path to agility” with some forward looking thoughts that can help you (and me) to continue on that path. Software development is evolving and changing; set yourself up for success by being willing to evolve and change right along with it. Agility is more than process or technical solutions; it involves integrity, accountability and a fundamental paradigm shift in your way of thinking. Continue to look for ways you can shift your thinking. Be open-minded. Teaching is a powerful exercise in self examination and growth; try to spend time teaching those around you, it’s worth the investment.