Fostering Innovation in an Agile Scrum Organization

This post originally appeared on VoltDB.com on 7/17/2017
 

What is Innovation Week at VoltDB?

Recently we held our Q2 Innovation Week, culminating in presentations and voting on the innovation projects created by our engineering staff. VoltDB engineering is a Agile scrum organization, with two week sprints, and product releases every other sprint. Innovation week occurs one week every quarter. During this week engineers work on a self-directed project, such as exploring a new technology, learning about technology (such as R or Docker), or just something technological of interest. At the end of this week, engineers present their project to the whole company, including marketing, sales, and the executive team. At the end of the session, the entire company votes on which project and presentation they thought was the best, with the winner receiving an iPad. This creates an interesting presentation environment, because people may vote on what is the most technologically impressive, or the most marketable project, amongst other things.

Innovation Week work is not isolated from our product. Many projects seek to improve VoltDB in some way, and some projects make their way into production. For example, one Innovation Week project in the past was work on user-defined functions, which is being fully developed and added into product. So while engineers may be working on something esoteric or in an entirely new space for us, if it’s good enough, it might just end up as a part of VoltDB.

The Q2 innovation week was exciting for an addition reason – summer interns. All of our summer interns participated. In the past, interns have won the competition, which again happened this year. Tianhe Wu, interning from CMU, and his project on data visualizations won by a big margin. Congratulations to Tianhe, and we look forward to future Innovation Weeks

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  https://github.com/organizations/VoltDB).
• 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.

Scrum Cadence

It’s unfortunate that the the Scrum product iteration increment is called a Sprint, implying that each increment is delivered by the team in a mad rush, full throttle.  The image I have in my head is a 100 yard dash, everyone running as fast as they can to reach the finish line.  Developing software is more like running a marathon than it is a back-to-back series of 100 yard dashes.  In order to successfully complete a marathon you have to find a one mile pace you are comfortable running at, and keep running at that speed for 26 miles.  Sprinting hard for the first several miles often means you are walking (or even crawling) the last mile, if you even make it that far.

Me, still running at mile 26, in the 1998 Boston Marathon

One of the challenges many new Scrum teams face is developing a sustainable pace, sometimes called cadence, over multiple sprints over the course of a project.    

New to Scrum, teams often struggle to find a sustainable cadence for delivering potentially shippable product increments.  What I’ve observed happens is this:  Early in a new Scrum project the teams is (I hope) excited to adopt a new way of working.  They understand the Scrum principles and the time-boxed Sprint iteration, and more importantly, they feel a strong commitment to succeed on their newly committed Sprint deliverables within the first few Sprints. After all, at the end of the Sprint they will be proudly demonstrating their work to their stakeholders, which usually includes there boss and department head.  However, since everyone is new to this different way of working, it is inevitable that certain work, usually that requiring specialized skills such as QA and documentation writing skills, ends up being delivered late in the game.  Undeterred, the team works extra hours, heroically delivering the Sprint goals.  This extra effort delivers a much needed early success, builds organization confidence, and can kick-start viral adoption.  However, this type heroic effort doesn’t scale - after 2 or 3 Sprints the team starts feeling burned out and may fail to deliver Sprint-committed work.

In an ideal situation, the Team inspects and adapts, and, over the course of several sprints, build a sustainable cadence.  However, many teams will continue to struggle, and can fall back to the “old way of doing things”.

While every team, project and environment is different, here are some points to consider to help get to a sustainable cadence:

• Work, as a full team, on only one story at a time.  Make sure that story is DONE before starting the next story.  In other words, implement stories sequentially.
• Avoid picking stories targeted for one individual due to their specialized skills.  Make sure the whole team is involved in delivering each story.
• Develop an “in it together” feeling among the team.  If you aren’t feeling this, your team isn’t operating as a true TEAM.  
• Commit to less stories to make sure your Sprint backlog really is DONE at the end of a Sprint.
• Become more of a generalist. Scrum certainly favors “jack of all trades” type of developers.  Coming from a Waterfall environment, where there are separate groups for QA and documentation, work can fall to those with that domain specialization.  As a team member, don’t look at work as “that person’s”, view it as a team deliverable. Learn a new skill to help a team member (and thus the Team) out, be it coding, QA or documentation.
• Be honest and innovative during your Sprint Retrospectives.  It’s your chance to change how you work together to deliver software.
• Get additional training or coaching.  Read Scrum blogs and ask questions on Agile forums.  Likely you are not the first team to run into the issues you are experiencing.
• If you are manager reading this, realize that team cadence, a predictable velocity, is key to delivering on corporate objectives.  Work hard to remove team obstacles and allow them to focus and succeed.  This is the true value of a manager in an Agile world.

Developing a sustainable cadence is one of the keys to the success of the Scrum Team and project effort.  Remember, running a marathon full throttle is unsustainable, unless, of course, you are an ultra-elite runner.  I know I’m not one.

Cycling and Scrum

Every year I join a group of friends and ride a 100K charity bike ride.  This ride takes about 4 hours and has turned into a fun yearly tradition. This year, as I was battling my way up the hills of Chilmark (the ride covers most of Martha’s Vineyard), it occurred to me that there were a lot of similarities between the cycle ride I was a part of, and a Scrum team.

Some of the similarities I came up with were as follows:

• Once you know the basics, you can ride a bike a long distance, or participate on a Scrum team.  However, having solid training for each makes doing them much easier and more efficient.

• Developing a regular cadence is valued in both Scrum and cycling.  Going to hard and fast early on can quickly burn you out, making it hard to finish the job.

• Buying a Scrum tool doesn’t make you a better Agile organization, just like buying a new carbon-fiber bike doesn’t make you a better, faster rider.

• I’m a long distance runner, and not a great cycler.  However, riding with my friends, many of whom are serious cyclers, makes me a better rider.  As the ride progressed, I rode smoother, tighter and faster.  Working on a Scrum team has a similar effect for team members.  Knowledge readily spreads to the teammates through frequent communication via daily stand-ups and backlog grooming activities, making them stronger, better engineers.

• Due to the fact that the ride occurs mid-Spring, each member of the team arrives with a different level of fitness, depending on how much training we put in on indoor trainers during the long New England winter.   As such those of us less capable rely on help from the stronger riders. With cycling, teamwork is core to the effort.  Riders work together, take turns leading the group, breaking the wind for the rest of the team,  pulling the group, allowing others (slower, tired riders!) to draft behind them.    Similarly, Scrum is focused on teamwork and less about solo achievements.  Sprints (and thus product releases) can only efficiently succeed if the team works together and arrives at the end together.

• There was a strong team commitment to finish the full 100K. During the ride there were several opportunities during the ride to cut it short - to quit early.  Additionally, the event offers 2 shorter rides, of 10 and 30 miles. But we, as a team, committed to completing the 100K ride regardless of the weather or any other adversity that came our way.    Scrum teams develop a similar strong focus and commitment to delivering potentially shippable product increments and overcoming impediments.

My friends and I had great weather and a fun ride.  We reached the 100K mark, the “finish line” together with a team velocity of 17 [mph] story points.  I’m looking forward to next year’s ride.

What does “Done” mean?

It starts with a team conversation...

One of my favorite team conversations that generated by the Scrum framework is one that occurs at the beginning of a Scrum project.  It’s the team discussion and subsequent agreement of what the word “Done” means.

A Scrum Team is supposed to produce potentially shippable code at the end of every Sprint.  This means that any stories (requirements) that the team commits to must be full implemented, documented, tested, etc within the time-boxed Sprint.  The stories must be DONE. Done can and often is defined differently by each team.  Minimally, Done means that the story committed to is coded and fully tested.  A story really can’t be potentially shippable if it isn’t coded and tested.  

Done is demonstrated during the Sprint Review, where working code is demonstrated the business owners and everyone else in attendance.   A story isn’t complete unless it satisfies the definition of “done”.  In fact, Scrum will not credit the team with story points unless a story is, in fact, “done” (and accepted by the Product Owner).  

Each Pilot team that I observed went through similar discussions about “done”.  Because Scrum was new to the teams, the initial definition of “Done” was a bit loose:  there was general agreement that a story was “Done” if it was coded and tested.    Over the course of the first Sprint Planning and the start of the Sprint 1, it often became apparent how loose that definition of Done actually was.  

The Product Owner and Team conversation for story acceptance criteria was one of the main catalysts for Done refinement.   As each member of the cross-functional team discussed the stories they were committing to, it was quickly realized that the initial definition of done left many questions unanswered.  Product areas such as documentation (what kind? what level?), training (again, what kind?), automated tests (how much should be automated? what platforms should be tested? what web browser? what about performance testing?) and bugs (should all be fixed?  just blockers? more than just blockers?) all had questions that needed answers.  

Over the period of a month or so, the teams each refined the meaning of Done.  The process of discussing, debating, and ultimately answering these questions helped the group grow into a high performance team.  This was very important to the success of the effort, as with Scrum the commitment to delivering a story is a team commitment, rather than an individual one.

A Great Habit

I think most would agree that it’s great to get in the habit of fully completing work, versus completing 80% of the work and leaving the remaining 20% for some time “later”, during the release end-game, or perhaps never (thereby wasting effort).  With Scrum, producing done work is essential to the process. In the pilots, I’ve noticed a tendency for teams to commit to too many story points during a Sprint, ultimately leaving one or two stories partially finished, though the team put in often heroic effort to meet the original commitment.  The unfinished stories were fortunately completed in the next sprint, but the fact that they were not complete often defeated the “potential” from the potentially shippable product.   One way to deal with this is for the team to sequentially complete stories within the sprint, never starting a new story until the current story is Done.  This isn’t always practical, or efficient, but the team should be aware of the story bleed and velocity drag that partially implemented stories create.  Alternately, it is perhaps better to commit to fewer story points per sprint and fill in any capacity with product maintenance or backlog grooming or architectural spikes.    These are team decisions that can be considered during Sprint Planning or during the Sprint Retrospective.

Agility

For me, the concept of Done is the key foundational principal that  makes Scrum agile.  At the end of a Sprint all stories are fully completed, thus potentially shippable.  This fact, coupled with a short development iteration, offers the business frequent predictable time windows in which to re-prioritize work or introducing completely new requirements.  Scrum allows an organization frequent opportunities to, in contemporary terms,  pivot.  Easily and readily shifting priorities with minimal impact to productivity is one of the primary mechanisms through which an engineering organization gains agility.