Success Story: Implementing "Scrum Lite"

The Challenges and Rewards

15 January 2014

Dasha Moskalenko
Europeana


Over the past year, we have experimented with running business projects using Agile/Scrum. I introduced Scrum in three business projects, aiming to improve interaction and collaboration between the team members and the product owner, streamlining everyone's efforts to boost productivity and results and limit frustrations.

Very early into the first project, we found that the traditional Scrum approach was too time-consuming for the business team, blurred the boundaries of responsibility among team members and the product owner, and included performance indicators not suited for a diverse business project team. To overcome these problems and still reap the key benefits of Scrum, we made some adjustments to introduce "Scrum Lite."

Forming a Scrum Lite team

The product owner identifies what knowledge is important for the success of the project and selects a team member from each department to contribute.

A Scrum Lite team is a group of noninterchangeable specialists needed for that project.

The importance of time allocation

Once the team is picked, each team member sits down with the product owner, ScrumMaster, and department manager to agree on how they plan to contribute to the project and the time they need to spend on it per sprint.

By committing to spending X amount of time working on a project, a team member permits him- or herself to set manageable and reachable sprint objectives. In turn, the manager can, in a timely fashion, reprioritize or reassign their other responsibilities within the department for the duration of the project.

Setting objectives

At the start of the project, the product owner sets a general project objective and identifies the key tasks and performance indicators to evaluate its success.

Presented with the main project objective, the team advises the product owner on how to break it down into individual sprint objectives, and further into collectively exhaustive department-specific sprint objectives. These are then further broken down into tasks.

Meetings

A Scrum Lite team should meet as often as necessary. We opted to meet once every week, to limit the amount of meetings in the organization. One week we meet for the review and retrospective meeting and a planning meeting. The next week we meet for a one-minute stand-up to share progress and concerns.

We found that planning a new sprint with the entire team is not the most effective use of everyone's time, since each team member works toward meeting his or her own objective(s). We chose to only combine the sprint planning sessions of team members whose work is related or interdependent.

No Definition of Done

Forming a united DoD for all tasks has proven to be very challenging in Scrum Lite. This is primarily because the team members' tasks are unique, diverse, and cannot be held to a unified standard.

We decided that in Scrum Lite, a task is done if it contributes to reaching the department-specific sprint objective. A team member is also free to discard or reevaluate a task mid-sprint if, due to subsequent changes, dependencies, or impediments, a task will not have the desired result, turns out not to be feasible, or proves too time-consuming for its impact on the objective.

Implementing Scrum Lite

Here I've presented a variation on the traditional Scrum approach that we tested last year. Most of the adjustments we made were to cater for the noninterchangeable business project teams.

The key benefits we took advantage of in coordinating our business projects using Scrum Lite last year were clearly defined short- and long-term objectives and transparency into each other's tasks, challenges, and time frames. This united the team, which was forced to plan ahead, and left room for us to respond to changes in a timely way. The cyclical revision of efforts and results motivated the team to come up with creative solutions to overcome challenges and improve results.

Following last year's success, we aim to run more projects using Scrum Lite and to improve the process further.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Michael Kuesters, CSP,CSM,CSPO, 1/15/2014 6:23:09 AM
Dasha, thank you very much for sharing your insights.

SCRUM is a lightweight, optimized framework intended to provide maximum efficiency with minimal overhead.

I perceive that your initial statement about SCRUM being too time-consuming is not a problem inherent to SCRUM, but to your organization's understanding thereof.

I will give you some examples of where your organization and SCRUM are worlds apart:

First, I wonder why the PO and the SCRUM Master have individual talks with each team member about contribution. In fact, I even wonder how the SM can be appointed before a team has even been formed?
This smells to me like traditional Project Manager and Line Manager roles cleverly disguised behind SCRUM titles.
What I seem to fathom here is not an Agile organization, but a Tayloristic matrix organization with a facade.


Your "setting objectives" section also has a certain aroma attached that we have a traditional Work Breakdown Structures cleverly disguised as Sprint Planning.

Your "meetings" also look like a Classic organization, because either you're saying that people don't work on topics more than once a week, or that there's really not much teamwork going on.

If you have a SCRUM team and they're not meeting daily and don't even see a need to meet daily, then either you've significantly evolved to the point where synergies are obvious and no impediments exist ... or you're losing the benefit!

I would seriously question: What does your SCRUM Master actually do all day?
Can you describe this in a bit more detail?


As for "No Definition of Done" - this is where my head started exploding.
If you can't find a DoD applicable for your specific team, then you're not being more efficient - you're doing something seriously wrong!

The next thing about team members (which I consider "individually") deciding whether to discard tasks mid-sprint looks like one of the first things to touch during the retrospective: Why is this even happening? Doesn't the team properly plan the sprint?
Of course it always happens that stories and individual Action Items get discarded on occastion, but it should happen less and less - and it shouldn't happen anymore at all after a couple of sprints, unless the Team isn't really a Team in the SCRUM sense.


Sorry for the clear words, but I personally really think you're not doing "SCRUM Lite". I think your company really hasn't made the mindset switch towards Agile yet.

Cheers,
Michael
Zach Bonaker, CSP,CSM,CSPO, 1/15/2014 9:50:59 AM
Hi Dasha - thanks for taking the time to write a clear, concise summary of your experiences. You clearly put in some effort and I appreciate your thoughts.

I don't want to invalidate any of your perceptions and ideas, nor do I want to be critical of what you achieved. However, I do have a lot of concerns with your implementation of "Scrum Lite" and statements about Scrum in general.

I share the questions/concerns in Michael's comment, above. Much like an individual who adopts a moral code only in situations where it's convenient, I get the impression that your organization ignores Scrum principles that are not understood and/or "easy" to do.

The concepts of collaboration, self-organizing teams, and discipline seem discarded in favor of easier, laissez-faire tactics.

I think your article sets a dangerous precedent for organizations that are trying to move towards an Agile approach to software. Take a look at your article and, being honest with yourself, compare/contrast to the Agile manifesto. Is your definition of "Scrum Lite" really true to an Agilist mindset?

Regards,
Zach
Aakash Srinivasan, CSP,CSM,CSD,CSPO, 1/15/2014 12:05:54 PM
Good read!.. I think your company’s approach to implement Scrum is definitely a compromise from a lot of the basic fundamentals of the process but nevertheless, it does feel like a conscious attempt to make the best of an imperfect situation (speaking strictly process wise and considering your company's reality of the same).
As a coach, I have often seen this behavior in organizations where the Agile message and encouragement had failed to continuously evolve transparently from top down and hence sets inconsistent expectations at the tactical level. It is nice to know that you were able to reap some benefit from Scrum principles by executing their variations but I agree with Michael on being cautious about branding this process as "Scrum Lite" because it sets a dangerous precedent for others looking for guidance on trade offs/compromises we are forced to make to implement Agile.

Thank you for sharing your valuable experience!

Regards,
Aakash Srinivasan
Cristian Todor, CSM, 1/16/2014 2:51:51 AM
Hi Dasha,

First, kudos to you for sharing your current situation and throwing yourself in the lions pit :). I share the insights above, not as concerns but rather as guidelines towards your next step. I have been in your shoes and I would like to encourage you to take the second step towards the Scrum mindset. And then the third, and then the fourth...
I feel that what you did was the only way you could move your organization towards Scrum. But I think it's only the first step. So far, I did not encounter a real world organization, which worked for generations in waterfall models and then was open to change to Scrum just like that. I think the step that you described is sometimes necessery, as long it is just that: an intermediate step. Try to move more and more towards correcting the points mentioned above, maybe call a Scrum coach, and I think people will start to want to move to Scrum as they will feel the benefits.

Regards,
/Cristian
Gurpreet Singh, CSP,CSM, 1/16/2014 12:33:47 PM
Hi Dasha,

First of all: a very well write-up of your experience. I agree with the people who commented above that applying Agile (/Scrum in particular) that a Classical Waterfall Company have stringent policies, business goals, rigid team members and a STRONG INERTIA to resist the change. These companies want to implement Scrum to get more customers, copying with every competitor or just a Fashion; however, they do not know the Agile Mindset. Trust me: no methodology can make a project succeed or fail; it is the people who will drive the success matrix of any project. I tried to describe such a state as 'Wet Scrum' in of my blogs; please have a look:

http://www.scrumalliance.org/community/articles/2013/december/wet-scrum

Br,
Gurpreet
Dasha Moskalenko, CSM, 1/20/2014 4:29:45 AM
Hi, Thank you for your feedback!

The challenge I faced implementing Scrum in our organisation for non-technical projects is that our team members are not interchangeable. They are all responsible for an aspect of the project e.g. communication & promotion, operations, technical development, event organisation etc. Each team member also works on multiple projects simultaneously. This means that in a two week sprint each commits to working two days on the project.

Do you have any suggestions for how to implement Scrum with these fixed factors without adjusting the elements I mention in my article?

Dasha
Michael Kuesters, CSP,CSM,CSPO, 1/22/2014 2:53:12 AM
Hello Dasha,

I understand your challenge, it is a typical challenge in traditional Matrix organizations.

It's a "known secret" that overall performance significantly drops with multiproject involvement.

I will give you a simple example of this.
Imagine you work on 5 projects which have a completion time of 1 week.
If you complete projects sequentially, after 1 week, you're done with the first - etc. After 4 weeks, you have delivered 80% usable results.

If you slice your week so that on Monday, you work on Project 1 ... Friday on Project 5, here's your statistics:
After 1 week, you delivered nothing useful.
After 4 weeks, you have 0% completion ratio.
In theory, after 5 weeks, you have 100% completion ratio: but what if you get sick? Your company will sit on 0% completion ratio!

Also, the world is turning - fast. If people don't SCRUM (you know, scrumming as in: get close, stick your heads together) but work on different topics, different time of the week, the following happens:

Jim works on the project on Monday, Bob on Tuesday, Tim on Wednesday.
When Jim finishes his time, Bob has to catch up with what Jim did. He either loses information (bad for Bob) or has to disrupt Jim for an update (bad for Jim).
By next week, Jim has no clue what Bob and Tim did - so we need a catch-up meeting where all three lose working time.

If the project had an impediment which only Jim can solve, there are two solutions: Either disrupt Jim's involvement completely or block the entire project for a week.

In practice, this approach usually reduces overall organizational performance by at least 10% (cumulative) per additional project involved!
Yes, think about it: If the organization would reduce average parallel project involvement from 5 to 1, they would increase corporate ROI by over 90% - with no additional investment!

You always need to think "What is 'fixed' in this world, except that one day, we all will die?"
Everything can be changed, if the desire is there - and everything that simply doesn't make sense should be put under inspection for change.

Again, I understand that there are organizational constraints, but you need to see that they are arbitrary. There are organizations out there who are capable of staffing teams to follow 1 topic at one time and bring it to closure - even small, budget-constrained companies.
If they can do it, why can't your organization?
Phillip Stiby, CSM, 1/28/2014 4:22:26 AM
Thanks for sharing your situation and ideas. The use of Agile methods and processes you are adopting is a great indicator of your want to be agile, and the term scrum lite is probably a good move to get executive buy in.

The problem you face here is known as the Split Focus Scheduling Game. Johanna Rothman has covered this in a number of her pragmatic project management books, probably worth a read.
Dasha Moskalenko, CSM, 1/29/2014 8:46:56 AM
Thanks Michael for your insight and Phillip for recommending the book!
Sameh Zeid, CSP,CSM,CSPO, 2/1/2014 7:50:37 PM
There is a ripple effect when we drop one or more prerequisites for Scrum implementation.
Shane Poole, CSM, 2/17/2014 7:06:12 AM
Hi Dasha

Thanks for sharing your experience with implementing Scrum.

Reading your article and the comments above I can't help thinking that maybe you should look at implementing Kanban, but combining this with some of the Scrum techniques.

This will help to manage work priority and provide visibility and transparency. Then you can use retrospective and daily scrums to help with improvements and communications etc.

Just a thought.

Regards

Shane

You must Login or Signup to comment.