SCRUM YES/NO

While there’re still discussions and arguments on applying SCRUM, it does exist. One day, you may be requested by your client or your manager to use SCRUM in one project. SCRUM may or may not be a good model, but there are some circumstances you should say "NO" to SCRUM. 

1.       Introduction

This article is to share one project which is failed in applying SCRUM and the lessons learned on it. Because it is an Outsourcing project on new Application Development, this article will so only cover this type of project.

The intention of this article is not to against using SCRUM, but it will provide a checklist to evaluate the factors around the project context to see whether or not we should move on with SCRUM. 

2.       The case study

Paul is Mike’s client. When Paul comes to Mike’s company to outsource one project, Paul only has a list of features which he expects to have in the software product to be built. It will be a B2B enterprise application. Moreover, Paul also wants this project to be run under SCRUM model. Mike builds a team of 6 people, including 4 developers, 1 technical leader and 1 tester. Mike is the SCRUM Master. In the first few weeks, Paul is very happy when he often sees new screens and new features delivered after every two weeks. (the sprint cycle is two weeks) Mike also applies most of the principles of the SCRUM, including product backlog, sprint backlog, burn down chart, Sprint planning, Sprint daily meeting and Sprint retrospective meeting. However, because Paul is often busy, Mike hardly arranges time to talk with Paul about which stories should be planned for sprints. Especially, Mike can’t arrange time with Paul for Demo sections after every sprint. Instead, Paul often reviews the products offline at his spare time and sends back the list of findings (bugs or change requests) to Mike. Sprint by sprint, Mike keeps delivering new products, he also includes high prioritized bugs and important changes into sprints. This makes Paul feel happy as he thinks his system will be ready soon. After 6 months, Dan who is Paul’s manager asks Mike to plan for the first version to go live. Even many features have been built but some important ones are still not available. Looking into the list of bugs and change requests with more than a hundred items, Dan begins worried. Dan asks Mike to give some artifacts such as Architecture & Design, Unit Test reports, System Test reports etc. but Mike couldn’t give sufficient documents and reports because they were not planned to be done. Dan asks his Technical Architect to look into the project in more details technically and he’s got the result: ·         Coding convention is not at level of his expectation ·         Unit test coverage is far low from his expectation ·         The architect of the system (MVC) is not followed strictly and it will be very difficult to enhance in the future. And the worst thing, Dan’s Technical Architect suggests rebuilding the system as it is too late now to modify it.

3.       The analysis

In the above case study, there’re many reasons which have caused the project fallen into a very difficult situation, but in this article I’ll only focus the ones under SCRUM perspective. 

3.1.    Workable product and validation

The heart of SCRUM is to deliver the workable products (the output of sprints) to client as early as possible. Workable means it must be at an acceptance level of quality, otherwise, the product should be cancelled or shouldn’t be delivered.

A lot of products have been delivered during 6 months, but most of them are not workable because they were not validated by Paul, the Product Owner, yet. Without validation, Mike has delivered lots of non-workable products, there is no way to combine non-workable products together to have a complete system. It becomes a mess!

3.2.    Planning

As the nature of the Software Outsourcing industry, the Outsourcing Project Manager who is often the SCRUM Master doesn’t stand in the client’s business. He’s not at the position to make the release plan or decide on which stories need to be done first, which products need to be delivered before the other. Product Owner or someone else from client has this responsibility and the SCRUM Master is only able to commit together with the team on the deliverables of each Sprint. Product backlog and release plan should be client’s mission.

This was not the case in the story when Paul did not really pay too much attention in planning and there was no one else doing this from Paul’s company. Lacking of planning outside of Sprint cycles is like sailing a ship without a compass.

3.3.    Product Owner’s availability

SCRUM encourages communication between Product Owner who knows well on the products to be delivered and the SCRUM teams. The traditional document like software requirement specification will not be used as an agreement between two sides. Instead, Product Owner is supposed to work closely with the team, to answer questions regarding to the features to be done and give feedbacks in time on the output.

Paul didn’t have time for product validation and planning. He also didn’t invest time enough to work closely with the team to tell them what he wants. How the SCRUM team can deliver the right products when the requirement is not written and the Product Owner is not with them.

3.4.    System architect

Not everything can be planned and executed under SCRUM methodology. Even a project is managed under SCRUM there’s still something such as defining System Architecture, creating System Architecture Framework, creating Graphic User Interfaces etc should be done outside of SCRUM cycles.

The team was focusing too much on delivering products and losing focus on a bigger view which is the system architecture. As the result, the architecture was broken. The MVC architecture was assumed in mind of each SCRUM team member, but it needs to be visible and monitored the compliance of implementation.

3.5.    Scope management

Mike was asked to give the Architecture document, the test reports and so on but he couldn’t provide because he didn’t plan for these activities. Paul should have managed this. There’re other expectations of client to be managed beside the workable products such as documents, reports, standards, test coverage etc. Even none of them is required, at least it is agreed in writing. Scope Management is still important in SCRUM typed project.

3.6.    SCRUM Awareness

After all, one major problem which caused the other problems above is about SCRUM awareness of two important stakeholders, the client and the SCRUM Master. Paul didn’t commit time for the project as Product Owner, client didn’t have someone take care of planning because they didn’t have good awareness on SCRUM. Mike didn’t train/coach Paul on the methodology, he shouldn’t have kept releasing products without validation.

SCRUM doesn’t mean undisciplined purely. SCRUM does require the practitioners to follow its principles to manage undisciplined working processes.

4.       SCRUM YES/NO

Ok so you’ve seen the failure and the lessons. I hope if you are starting a SCRUM typed project, make sure you say “NO” if it should be. Actually, the boss will always expect a “YES”, but at least we see which are missing from the checklist below so that we can put them in risk management and look for a mitigation plans.

Item	Y/N	Note
[Product validation] Is it feasible to do validation on products in every sprint?		There must be the acceptance criteria which are used to validate whether the products are acceptable or workable. Something such as  no major defects, unit test coverage, architecture compliance … Client has to commit doing this every sprint.
[Planning] Product vision and release plan must be taken care of.		No matter who does this, it must be done. Normally, someone at client site should be responsible for.
[Product Owner’s availability] Product Owner must have time to stay with the team every day.		It is recommended the product owner co-locate with the team if possible. Besides, he should commit at least 2 hours per day for queries and explanation on stories.
[System architect] There must be some first sprints to do architecture. Alternatively, there must be a non-SCRUM phase for doing architecture.		This is extremely important when the application is big and complicated. Not only doing the architecture but also validating the compliance on the implementation is required.
[Scope management] Scope management must be done before starting SCRUM cycles.		SCRUM doesn’t cover fully scope management. Refer to Scope Management to see what more need to be managed.
SCRUM Awareness		Make sure you have adequate knowledge to be a SCRUM Master, make sure client has good awareness on SCRUM.

5.       Conclusion

Although this article has shared one failure application of SCRUM, it doesn’t have a negative meaning. Instead, I hope you would make the right decision when deciding to go with SCRUM.

Beside this failure, I do see other projects which were applied SCRUM successfully. Look through the checklist, it was almost complied in those success stories. Hopefully, I would have the next post on one typical successful SCRUM typed project.