Thursday, June 5, 2014

Rice Scrum

Hi Everyone! It has been quite awhile since we have posted an entry so I wanted to give an update. Things have been very busy, and there is a lot I could talk about. But I have decided to focus on two topics for the next few entries. Both can be summarized as 'Great Change'! The first deals with change within the team and our process. The second is change with the product itself (KRAD Architecture). As always I look forward to any feedback you have.

On the outside, things look like business as usual. We are working on a patch release of 2.4 (2.4.2), and our next minor version 2.5 which will contain loads of nice improvements. Internally though, there are exciting discussions and planning occurring to improve our value to the community (in other words, to deliver more often and with better quality). You have probably guessed by now this has something to do with Agile methodology, and you would be correct! More specifically, we are working towards implementing Scrum.

Within Kuali, we have always stated we follow agile methodology. Furthermore, on the Rice team we have implemented some Scrum practices already (daily stand-ups, sprints, and sprint planning). While these things have provided value, by not following the full practice we are not giving ourselves a chance to realize its real value: creating high performance teams. In addition to this, Scrum requires not just a process change, but a culture change. Before many of us (including myself) did not really understand the underlying goals of these practices. Fortunately, the Rice team was able to attend Scrum Master training (http://www.michaelvizdos.com/scrum) at the recent Kuali Spring Workshop. This had a huge impact on the team. We now understand the goals behind the Scrum practices and the various Scrum roles. In other words, we understand the why!

We have a lot of work left to define what this all means for Rice, and how we get there. However, there are a few changes I would like to go ahead and mention. These are ones the team feels strongly about and that I think will have the largest impact on the community.

Product Owner(s)

Who sets the priorities for Rice? Who drives a vision? These are very complicated questions to answer currently. It is some (messy) combination of the ARC (Application Roadmap Committee), several smaller committees, project managers, team members, and likely others. In a Scrum team, these responsibilities fall to a single product owner (note this is per team, a project could have multiple teams). The product owner works with all stakeholders to collect and prioritize work. They protect the Scrum team from this 'noise', allowing them to focus on delivering. For more on the product owner role, see Scrum Product Owner.

On the Rice team, we have an incredible amount of 'noise'. Not only do we have a huge code stack to support (and multiple versions), we have multiple stakeholders with many different needs, and we provide support for the wider community. For any given release, I would estimate the amount of work we end up putting into that release is at least 3 times more than the 'planned items'. Many of these efforts go unnoticed, causing the community to only see a missed release date. The product owner will help greatly to make these items visible, and the team can stay focused on the highest priority items.

Definition of Done

Quality vs. Quantity. When a project is in survival mode (always putting out fires, behind schedule, attempting to implement all stakeholder high priorities at once, etc.), quality is often sacrificed for quantity. This might get the team short term praise for appearing to get a great amount of work done in a short period, but will come back to haunt in a big way. In fact, after years of quantity over quality, the project can get to an almost standstill point, and be a candidate for garbage collection. Before it gets to that point, there is vicious cycle. While trying to deliver new functionality, the team is also putting just as much effort 'patching' older versions. This could involve making the functionality work like it was intended to in the first place, or resolving regression issues. This puts the new functionality behind schedule, and pressure to deliver causes the same shortcuts to be taken.

This is where the promise of 'Definition of Done' comes in. It's about setting a line in the sand: We will not trade future quality for quantity. Our team feels quality includes these things (ex. user stories, unit/integration tests, AFTs, documentation, etc.) and new functionality will not be accepted (or considered done) unless it meets this criteria. Sticking to this takes a big commitment from the entire team, but it is the only way to break the cycle. It also takes honesty from the team to consider where things are at, and not continue to over promise or be overly optimistic. The product owner then has the information to correctly set expectations with stakeholders.

Deliver more Often

Wait, deliver more often? Didn't I just talk about the need to put quality over quantity? It turns out, by focusing on quality (and done) you end up getting both: better quality and more quantity.

First, if the items you are delivering are 'done', you will be spending less time 'patching'. So the time that was allocated for new work, can truly be spent on new work. Next, by requiring an item to be done, and limiting the amount of work in process (small batches), you can release more often. Instead of waiting 6 months to a year for any new functionality, customers can get quality releases monthly, or even sooner (in fact, many great teams are now achieving continuous delivery).

Focus on the Customer

All of this change steams from an increased focus on the customer. Besides the items outlined above, there are many other pieces of Scrum that will help in this area. For example, Sprint demos will allow us to verify new functionality with stakeholders sooner, eliminating potential waste. The product owner will help bring transparency, allowing the stakeholders to make better business decisions. Most importantly, our team will gain trust from the community by delivering quality product.

The motivation to make these changes is a great step in my opinion. Of course, the hard part (implementing) is yet to come. Furthermore, Scrum is not a magic bullet. Becoming a high performance team involves many aspects. Personally, I have been on a journey exploring other methodologies and practices to help our team. This includes XP, Lean Methodology, and other leadership practices. In the next entry ("Notes to a Software Team Leader") I will discuss these more.

Jerry Neal
Kuali Rice KRAD Architect
Senior Developer, Indiana University

4 comments:

  1. I agree with what has been discussed here so far. But I would suggest you to take a look at http://www.scrumstudy.com. looks pretty different and their methodoly is really interesting and effective. I personally felt it stands out for the quality of the materials provided..Agile Certification

    ReplyDelete
  2. Thanks for the comment Andrew. I will definitely check that out.

    ReplyDelete
  3. Sprint Retrospective is a meeting convened by the Scrum Master in which the team talks about the previous sprint and decided on how to make the next sprint productive.

    ReplyDelete
  4. Goodly written article it is especially agile certified scrum master the way you have talked about them is impressive and in the light of the fact if see the growth chart through them that is superb too.

    ReplyDelete