Monday, July 14, 2014

VoltDB Agile Development - Monthly Releases, Strong Definition of Done

Here's a short overview (2 minutes) video of the VoltDB Development Process, our use of Scrum and our strong Definition of Done (DOD).

I had fun working with VoltDB marketing to make this video, an thanks to my team for pitching in!

Wednesday, March 13, 2013

Football & Business

I had the good fortune to attend the Mass Technology Leadership Council ( Annual Meeting in Boston this week where Robert Kraft was the featured speaker. Mr Kraft turned out to be a great storyteller.  In addition to owning the New England Patriots Kraft is the CEO of The Kraft Group, which is an international paper business. He has years of pure business experience so his stories were full of interesting business-relevant anecdotes. But even when he was talking about running the New England Patriots the lessons were business-oriented and you could see that he has a strong sense of purpose and passion that he has instilled in all of his organizations.

Early into his Q&A session Mr. Kraft stated "Life is about execution, not just dreaming.

This is true in both sports and business.  If you don't execute in sports, you lose the game. Don't execute in the playoffs? Your season is over. If you don't execute in business, you lose the deal.  Continue to not execute, you will eventually go out of business.

Though I could have listened to Kraft talk for days about the New England Patriots (his Vladimir Putin/Superbowl ring story was incredible), the business-oriented nuggets in Kraft's speech were even more interesting.  If you get a chance to hear Kraft talk, do it. He was interesting, often funny and very inspiring. 

"Life is about execution, not just dreaming" 

- Robert Kraft
Owner, New England Patriots
CEO, The Kraft Group

Tuesday, March 6, 2012

Back on the Front Line of Agility...

Sorry that it has been a while since I posted here - my professional life has changed considerably since I last wrote!

Last Fall I join an exciting startup, VoltDB, leaving behind a "Waterfall to Agile" transformation environment, diving head first into the front lines of a pure Agile start-up environment.

It's been a pretty exciting 6 months working with a great team of engineers.  We're delivering a high velocity, scale-out NewSQL relational database. This product fits at the fire hose intake edge of Big Data and is capable of ingesting hundreds of thousands of transactions per second on commodity hardware.   Low latency, high velocity.  Lots of challenges, both technical and process-wise.

Here's an overview of the VoltDB Development environment:
  • Open Source Database.  Because it is open source, anyone can see the our code (see our Git repository at
  • It's a database.  It has to work, can't corrupt or lose data.  Quality is paramount.  
  • We have Continuous Integration system running a large suite of automated tests.
  • VoltDB is in production for a significant number of customers.  There's no dedicated Support team; the Engineering Team provides 24x7 support.
  • We have transparent development: our Product Backlog and Sprint Backlog is hosted (publicly) in JIRA.  We use Greenhopper to plan and track iterations.
  • 3 week iteration.  The product is released almost every iteration!  The Team truly produces a potentially shippable product increment most iterations.
Of course, like every Agile team, we have our share of challenges.  Some of the challenges we experience include:
  • Dealing with unplanned customer support issues as well as pre- and post-sales assistance.
  • Dealing with technical debt.
  • Story sizing: specifically defining small enough slices of potentially shippable functionality.
  • Scaling the team: we're growing fast!
We've adopting Scrum to help us meet these challenges. I'm a firm believer in Agile software development, specifically an Inspect and Adapt framework like Scrum.  Because we're a start-up with a product smack in the middle of a rapidly growing, and evolving, Big Data market, product requirements can change often, sometimes daily. Scrum provides us the framework to adapt to changing business conditions while still regularly producing business value.

It's great being back on the front line of Agility. I hope to find time to blog about these challenges as well as other topics in the coming months, time permitting.

Tuesday, September 13, 2011

Scaling Scrum: The Chief Product Owner

We’ve begun our next phase of Agile transformation - scaling Scrum from single team efforts to larger multi-team projects within our organization.   As part of this phase, we’ll be building and delivering multi-product enterprise-ready offerings, requiring the coordination of many Scrum teams across many time-zones.  

Not unexpectedly, as we’ve delivered the first few product iterations from these larger efforts we’re faced with new challenges.  Among the biggest are coordinating backlogs between teams and resolving dependencies and integration issues.  Both issues are requiring a lot of additional time and effort, over and above the team-level Product Owner and Scrum Master efforts.   

In his book about scaling Scrum, titled The Enterprise and Scrum, Ken Schwaber states “The higher the level is, the harder the Product Owner’s and Scrum Master’s job is.”  This is an important point to recognize and deal with: as you expand the size and scope of a product, as you “scale up”, more work is required for those holding the key roles in Scrum. Though this is a huge challenge, there are common patterns that can be used to help.  One is the Scrum of Scrums, where one or more representatives from each Scrum team meet daily to coordinate Sprint work and Sprint dependencies.  Another pattern, one that I consider extremely important when scaling, is a Chief Product Owner.  

The Chief Product Owner is a new unofficial (to Scrum) “role” that can greatly help with scaling Scrum.  In Scrum-speak, this role is the Product Owner of the whole product.  The Chief Product Owner is a person who is the single point of accountability for the success or failure of the complete project. This person owns the overall single product-level Backlog,  and provides guidance to the group of product owners on the Scrum teams that comprise the complete effort.  The chief Product Owner uses this backlog to coordinate the work, likely in the form of sub-backlogs, between the sub-teams, through each individual team’s Product Owner.

It is important to note that this role is filled by an individual, not a committee.  Without a designated person ultimately responsible for the success or failure of the effort, there is a high risk of “death by committee”.  By identifying a Chief Product Owner you can avoid this and have one final arbiter to order work and accepting results, as Scrum dictates for individual teams.

The Product Owner role is a key role on individual Scrum Teams.  When scaling Scrum, this role takes on even more importance - the success of the entire product relies on deep understanding of the overall product backlog and careful and coordinated roll out of work to individual Scrum teams.   Like the Product Owner role on an individual Scrum team, the Chief Product Owner is a full time role, one that requires a full time focus and commitment in order to be successful.

Monday, August 29, 2011

Scrum: It’s a full-time job.

An adequate ScrumMaster can handle two or three teams at a time...A great ScrumMaster can handle one team at a time.
-Michael James

One of the lessons we learned early in our Scrum roll-out was that the Product Owner and Scrum Master roles required much more involvement than originally thought.  Coming from a Waterfall development environment, where releases were long in duration and milestones spread out, people in the organization were used to having key roles on multiple projects, context switching as needed.   Juggling responsibilities in a Waterfall environment seemed to work well, or at least acceptable.  Our Product Managers, for example, could own several product lines, including associated customer meetings and field interactions, and easily satisfy occasional project touch-points such as requirements definition (at the beginning of the release) and Beta and FCS duties (at the end of the release).  These project touch-points required their full-time involvement periodically, a few times a year, making it relatively easy to context-switch periodically and satisfy the needs of each effort.

With Scrum, however, things turned out a bit different.  Though we “took the training” and “read the literature” which repeatedly said the roles of Scrum Master and Product Owner were full time jobs, we weren’t true believers.  Our “muscle memory” way of working had everyone juggling multiple roles and responsibilities, it was the way we were used to working. During the course of our Agile Pilot projects, however, we got convinced pretty quickly that Scrum roles could not be part-time.

Scrum is more intensive than waterfall development.   

With frequent “potentially shippable product increments” created every 2-4 weeks,  there’s essentially a full product release at least once a month if not twice.   During our Agile pilots, our Product Managers, filling the role of Product Owners, soon realized that creating and maintaining a Product Backlog required a significant amount of time.  Every few weeks a new set of fully-defined “product requirements” need to be ready for the team for the next Sprint. Product Owners found it challenging to satisfying their Scrum PO role and concurrently complete other project work.  Our Scrum Masters, too, found themselves booked full-time, facilitating team interactions, producing Sprint Burn Down charts, working impediments, and delivering frequent product releases at regular Sprint Review.  Team members, often with other-project responsibilities, found themselves spending more time delivering on Sprint Goals, often at the expense of their other responsibilities.  

As we scale Scrum within the organization, we’ve (obviously!) needed to identify new Scrum Masters and Product Owners.  We’ve held fast to the one project per Scrum Master recommendation. Identifying new dedicated Scrum Masters has been fairly easy - our Pilot teams was that the efforts produced several Scrum Master candidates, a nice side-benefit!   Finding full-time Product Owners for each team was more challenging.  Because we’re applying Scrum to large multi-team projects, our mapping of Product Manager positions to Product Owners simply didn’t scale.    Our solution was to look to our lead engineers. Most of our new teams have technical Product Owners, usually Software Architects, and they are dedicated full-time to the team.  Product Managers are involved at either a co-Product Owner (in an outward facing role) or at a higher level in the project effort, via a Product Council-type role that involves them as stakeholders.  

I expect our organization to fine tune (via inspect and adapt) these non-Scrum roles as we mature in our Agility.  But regardless of the organizational “noise” around the Scrum Teams, I believe that participation at the Scrum Team-level will continue to require full-time effort from all members in order to be successful.

Tuesday, August 9, 2011

Why Agile?

We’re at what I perceive to be a major “transition point” in our Agile transformation.  Most of our Agile pilot teams and projects have successfully completed and we are rolling out internal Scrum training throughout the Product Group.  We’re on the cusp of taking a big step forward with Scrum adoption within our 500 person organization.  It’s at transition points like this when I find myself reevaluating our direction: “Why are we doing this? Are we ready for this next big step?”   Our existing processes do, in fact, lead to shipping product and generating revenue, so: “Why Agile?”

Our original goal, defined we began this transformation, still rings true:

The goal is not to release things faster for the sake of it. It is to achieve nimbleness and agility to deliver on the company’s strategy as it moves forward and/or tactically changes.   It is about creating more business opportunities for ourselves rather than being cased into a model that requires our resource commitment for a time window that is longer than what the market we’re competing in requires.

Specifically, the software development group’s reason for moving from Waterfall to Agile is to achieve nimbleness and agility to deliver on the company’s strategy as it moves forward and/or tactically changes.  We want the ability to efficiently deliver strategic products to market in a timely manner.

Today we have challenges delivering on this goal.  As a mature software organizations our development practices have been hardened over many years of delivering software to tens of thousands of customers.   Our processes have been tempered with the successes (and often, the failures) of the past.    Because of this, it’s difficult to change the current way of doing things.  This is an understandable, and completely human, reaction - but it can dangerous over the long-term.  Fortifying the walls, via policies and procedures as well as organizational divisions, has the result of business being less reactive to change, less agile, which ultimately impacts corporate revenue.   New software releases often take longer to get out the door and may not fully meet customer needs.  Entering new markets in a timely manner becomes difficult, allowing younger more nimble companies a market advantage.   It is for these reasons that we’ve embarked on our development process transformation.

As part of our migration from Waterfall to Agile software development, we need to build a new way of working, including a new corporate culture: one that is nimble and responsive to ever changing business conditions. A culture that values responding to change over following a plan.  One that regularly inspects and adapts, and becomes better over time.  Scrum, with its “inspect and adapt” framework,  is one of the catalysts that can greatly assist us in this journey.

Tuesday, July 19, 2011

Technical Debt

Technical Debt  is one of my favorite work-related phrases because it succinctly and metaphorically sums up the obligation we incur when we cut corners during software development.  The phrase was coined by Ward Cunningham, the developer of the first wiki and, incidentally, a major contributor to Extreme Programming Agile methodology.

The concept of technical debt can be thought of as the accumulation of product risk introduced by any number of poor development practices.  Examples include poorly designed code, loose development practices, and, in Scrum terms, the delivery of “undone work”.   The payment terms on this debt can be onerous.  Usually the cost is time or productivity, sometimes both.  Dealing with this debt during the product release can increase the work required before the product can ship, often delaying the release.  Or, if you decide to postpone payment until after the release, the cost may be customer-discovered defects which can cause unexpected maintenance escalations and a higher ongoing product maintenance burden, ultimately reducing productivity and velocity for future development.

Regardless, like credit card interest or the National Debt, at some point in the future the bill comes due - someone is going to have to pay off the debt.
For new teams adopting Scrum, Technical Debt can occur without the team being fully aware that it is happening.    For example, teams with a loose definition of Done can introduce technical debt.  Stories may be accepted by the Product owner without having code reviews, minimal automated testing, or no code coverage or memory leak verification.  Any of which could leave unexposed defects in a seemingly “done” feature.  Another possible cause of debt can be caused by user stories that not properly decomposed such that Sprint backlogs do not yield a potentially shippable product increment at the end of a Sprint.  In this case, more work, either known or unknown, is created for “later” in the release.

As a Product Owner, you should keep track of your accumulating debt.  If the debt is significant, I recommend putting it in your Product Backlog, to be prioritized appropriately.  One way that I have found to identify and track any technical debt your team is accruing is to plan periodic “releases” to customers.  Product early releases, in the form of early access programs or Technical Previews, can not only provide valuable customer input that can feed into your backlog, but it also keep the Scrum team in the practice of delivering potentially shippable code.  When engineers realize their code is going to be used by actual customers, often “forgotten” undone work can suddenly appear.

Note that not all debt is “bad” - there are often valid reasons for accumulating technical debt.  Perhaps the underlying architecture has some scalability constraints, but getting the product to market, in other words, harvesting “business value” ($, customers), is more important to the business.  The key is for the Product Owner and Team to explicitly know that this debt was incurred, and accept that you may have to pay in the future be willing to accept that obligation.

The Product Owner should be aware at all times of work that is needed to release the software, including the technical debt that is accruing.  With a complete and publicly visible Product Backlog, there should be no surprises. Keep an eye on your debt - make sure you know how much debt interest is accumulating...