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

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!

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.

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.

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.

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...

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.

Inspect and Adapt

“SCRUM assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression.”

-Ken Schwaber, Scrum Development Process, 1995

One of the things that I like about Scrum is that its creators defined it knowing that no development process is perfect.  The Scrum Guide does not tell us how to build software, rather, it openly acknowledges that building software is complicated and unpredictable.  This may seem odd, with Scrum being thought of as a development process (it’s not).  In a recent post to the Yahoo! Scrum Development group, Ken Schwaber stated that “we purposefully constructed Scrum with a lot of holes in which a person or team or organization has to continually figure out the best thing to do.”

So how does a Scrum team “continually figure out” how to do the best thing?   To facilitate iterative and ongoing improvement, Scrum specifies that each Scrum Team hold a Sprint Retrospectives. Further, these retrospectives must happen frequently, occurring immediately following each Sprint Review.  

It is often overlooked when starting out with Scrum, but I believe the Sprint Retrospective is the most important meetings a Scrum team participates in.  While the Sprint Review is a valuable “public” meeting where working product is demonstrated to stakeholders and customers, the Sprint Retrospective is a “private” team meeting, allowing the team to safely discuss what’s working and want could be improved with regards to how they are delivering their work.  In the Sprint Retrospective, anything that relates to how the team operates can be discussed and possibly tuned or improved.  Up for debate could be how the team communicates, technology issues, done-ness criteria, or even choice of tools, as was recently discussed for one of our new Scrum teams in my organization (They reverted back to whiteboard task charts and spreadsheet burndown charts!).

What this ultimately means is that each Scrum team is evaluating, refining, and improving how they work together and build software every 2 to 4 weeks.  Almost continuously improving throughout the life of the project!  Over a 12 month project there can be upwards of 24 opportunities to “do things better” and improve how the software is built and delivered.   Compare that to our our Waterfall-like development model where we generally conduct formal retrospectives twice, once after Beta and once after we release.   In our current model, we, at best, have one predefined opportunity to improve our practices during the release, at Beta when there is usually no more than 3-4 months of (QA and bug fixing time) time remaining before the software is released.  Process improvement is clearly not highly integrated into our Waterfall process.

With frequent inspection and adaptation we can become more efficient at building and delivering high quality software that meets or even exceeds customer expectation.  So my advice is: take full advantage of your Sprint Retrospectives.   As a Scrum team member, it’s your (frequent!) opportunity to make a difference...

kaizen  (kaɪˈzɛn) - n  a philosophy of continuous improvement 

of working practices that underlies total quality management 

and just-in-time business techniques [Dictionary.com]

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.

"Scrum is Like Chess"

One of my favorite Scrum quotes is “Scrum is like chess.”  

Like chess, the “rules” for Scrum are fairly straight forward. But also like chess, Scrum practitioners require continued practice and ongoing learning to be come good.




So why do it?  If it is hard to master, why change our development process?

Ken Schwaber, a co-author of the Scrum Guide, sums it up best:  “Those who play both games and keep practicing may become very good at playing the games. In the case of chess, they may become Grand Masters. In the case of Scrum, they may become outstanding development organizations, cherished by their customers, loved by their users, and feared by their competitors.”

Being loved by users and feared by competitors would mean that we’re delivering highly desired software products which are generating significant sales growth and, ultimately, more corporate value.  This is the state we, as a company, want to achieve, and it is one of the drivers for our transition from Waterfall to Agile.

So what can you do to become better at Scrum?   

Being part of a Scrum team and new to Scrum, you are likely devoted near-full time on learning new ways of working as well as actually delivering potentially shippable product every Sprint.  But this shouldn’t stop you from allocating some time to digging further into the nuances of Agile software development practices, communication and organizational behavior.

There’s a wealth of information, as well as tons of opinions from many of the great Agile industry experts, on two public Internet groups.  The first, and older, is the Yahoo! Group, Scrum Development (http://groups.yahoo.com/group/scrumdevelopment/).  The second, a Google Group called Agile Leaders (http://groups.google.com/group/agile-leaders?pli=1) was recently created and also features some lively discussions, often by the same cross-section of folks on the Scrum Development list.  By just becoming an observer to these lists you can glean many useful tidbits of information on all aspects of Scrum as well as Agile software development. While these are great resources for every Scrum team member, aspiring ScrumMasters and Product Owners should take particular note of these two valuable resources.

There’s also numerous blogs and webinars that can give you insight to different facets of Scrum.  I’d start there before buying too many books (Amazon lists over 300 books for “Scrum” and over 1300 for “Agile”).  There are many formal and informal Agile and Scrum gatherings, such as Agile New England (http://www.agilenewengland.org) that regularly host events and meet ups.  

And finally, as with any discipline, nothing beats practice coupled with an ongoing desire to learn.

Enjoy the journey!

Transparency: Keep it visible!

“Openness is required for Scrum to work.”

-Ken Schwaber, Agile Software Development with Scrum

Openness, transparency, visibility - no matter what synonym you use, it is critical to Scrum.  My favorite term is transparency: Scrum’s openness makes everything that is going on within the project transparent to the world.   With Scrum there are no hidden priorities, no hidden work, everyone should (and generally does) know what is currently being worked on and what will be delivered by the team.

On the surface, it may seem that transparency is more important for management and the business owners rather than the team.  Management primarily cares about when we can actually ship and start selling a product (and of course, that the product does what it needs to do - that it meets market expectations).  Numerous business-related activities such as marketing, support, training, etc,  are coordinated around a product release.  

But transparency is also extremely important for the team and individuals.  Nowhere is this more apparent than in a Waterfall development environment. There have been several instances in my career where a peer has asked me for workplace advice.  The conversation zeros in on a boss who is giving them grief about their productivity.  After listening to them vent, a common thread usually appears:  these individuals often are doing a lot of work, usually juggling many different activities, but their manager is only tangentially aware of the scope of responsibilities this person is shouldering.  The manager is not aware of their employee’s “backlog”.    

My advice in these situations is simple:  make a list of work you are doing, order it according to priority, and discuss the list with your manager.  In particular, I suggest that they work with their manager to help set the right priority of the various work items.  This conversation often opens the eyes of both the manager and the employee, quickly addressing the tension and frustration experienced by both parties.

With Scrum, this communication activity is commonplace.  In fact it is core to the Scrum framework:  the prioritized product backlog and the Sprint backlog are visible to everyone. As a result, the work being done by the team is obvious and very transparent.  Further, project progress is demonstrated to the business owners regularly during the Sprint Review, via a (potentially shippable!) working code demonstration.

The Inevitable New Unplanned “Top Priority” Work

In a Waterfall environment, the impact of new, mid-project “high priority” work is often not immediately felt.  Because the product release can be many months away, incoming hot issues can be dealt with in a timely manner and everyone feels good, at least in the short-term. However, this new work causes the team to accrue a form of “schedule debt”.  The painful balance comes due at some point in the future, usually in the form of a schedule slip.  And often, sadly, that schedule slip is a surprise to management.

In a Scrum environment, transparency is the proverbial Big Stick when unplanned “critical” work is added to the project.  When management (let’s face it, it usually is management) adds new new work to the team’s plate, the impact to the team is immediately obvious:  1) the new work will either displace existing Sprint priorities causing the Sprint to be abnormally terminated, something everyone wants to avoid, or 2) the work will be added to the Product Backlog and prioritized according to business value.  There’s no magic, no silver bullet, and everyone Scrum-enabled, will should understand that!

Surprise!

In software development, we don’t like surprises - we like predicable.  Usually a surprise means new unplanned work for the team or a schedule slip.  Someone is is going to be unhappy!  

Scrum’s transparency helps organizations eliminate surprises or at a minimum deal with them effectively.   Surprises in the form of schedule slips are eliminated because what the team is working on is very visible and demonstrated at the end of every Sprint.  Work, delivered via Sprints, is time-boxed and ends up being very predictable.  Surprises in the form of new, unplanned work is dealt with effectively by adding it to the prioritized Product Backlog.  With a prioritizing Backlog, the team is always working on top business value items.  

Transparency, via a published, readily viewable backlogs allows everyone to understand what is currently being worked on as well as the impact of new unplanned work.    
 

“Scrum keeps everything about a project visible to everyone.”

-Ken Schwaber, Agile Software Development with Scrum