Telling our CI story
October 4, 2012 § Leave a comment
I’ll be speaking at the Better Software Conference in Orlando this November. One of the sponsors, techwell.com asked me to share a little more about what led AtTask to embrace a continuously integrated system. When it first came out, I thought our stuff was pretty novel. Now I think it’s just the cost of doing business if you’re selling software on the web.
You can read the whole interview here.
People work hard for money, harder for leaders… but hardest for a cause.
May 8, 2012 § 2 Comments
From my vantage, the Atlanta Scrum Gathering was largely a success. There were a few stand-out talks, but some duds as well. I was surprised by how light many of the presentations actually were–perhaps because agile methodologies tend to be pretty simple in the first place. That said, there were a couple of learnings that will stick with me as I move our organization forward.
Time boxing is not a pre-requisite for effective Agile. The closer we’ve moved to Continuous Delivery, the more the time-boxing of our Sprints has felt like an artificial construct. Lots of people have run into this problem when working on queue-driven activities. One person shared an example of an off-shore team whose entire job was to write regular expressions for website scraping. There was no reason to use a time-boxed release cadence. Instead, the team pulled work from a queue at a consistent pace, delivering the work as it was completed. The ER (Escalation Response) team at AtTask is already doing this, just without a mechanism for observability by external participants, or a formal improvement program. I believe that Kanban solves this problem in an elegant way, and would be a relatively painless model to explore.
“People work hard for money, and harder for leaders. People work hardest for a cause.” This quote was shared during this mornings keynote by a gentleman named Tanner Corbridge. He works with Partners in Leadership, the company behind The Oz Principle. He mentioned it almost as an aside, but it certainly resonated with me. The fire that we instill in our organization should not be about compensation, or about the charisma of those that lead our teams. It should be about building our culture around a common purpose. It’s something we should have laser like focus on in everything we do. I’m very proud of AtTask’s culture, and believe that our adoption of agile has helped us focus on our common cause. AtTask is about improving the work lives of knowledge workers across the world, and we can measure ourselves against that cause. I’m looking forward to discovering ways to accomplish that going forward.
From Scrum to Kanban, doing the legwork
May 7, 2012 § 2 Comments
I’ve enjoyed participating in the talks at Scrum Gathering 2012 in Atlanta. One of the most interesting was Steve Forte’s presentation on Kanban 101. I’ve been exploring Kanban as an alternative to Scrum at AtTask for a while now, but with our adoption of Continuous Delivery and the recent rollout of Feature Toggles, we may be ready to take the plunge.
AtTask has been an Agile shop for several years now… really since we had a team of appreciable size to benefit from the principles. We adopted Scrum as our methodology of choice, primarily because it along with XP was about the only thing that matched our legacy delivery model. While we’re still delivering features into production every 4 weeks, our CI pipeline has piqued the interest of folks within our organization who would like to see even more rapid build-test-learn feedback loops.
Kanban evolved from the Toyota production system, as a model for developing cars more quickly, while minimizing inventory and emphasizing just-in-time delivery. When it comes to software, Kanban is a model that eschews the traditionally time-boxed Sprint metaphor in favor of a pull-based system. Features are sized, and move through phases of production which are carefully limited in order to eliminate inventory (unreleased code) and maximize flow. With Feature Toggles, we’ve gained the ability to deploy virtually anything without affecting the customer experience unintentionally. Because releases are now managed by the business, we can create a Kanban flow which will take us from story conception all the way to deployment.
I think we may have a good first start with our customer bug-fixing team, since their work is inherently request driven, rather than time-boxed. Over time I’d like to see Kanban principles adopted more broadly across AtTask.
The Continuous Deliverist 