Symptoms to Identify Failures in Scrum Project
Posted on December 9, 2010
Filed Under Scrum Basics | 1 Comment
Though Scrum is seen as most successful in delivering a product, often Scrum itself fails due to various reasons. The Symptoms and Root Causes are discussed in this article. As per Wikipedia, failure generally refers to the state or condition of not meeting a desirable or intended objective. so what is failure in the context of Scrum? As per the Agile Manifesto’s Principles, our highest priority is to satisfy customer through early and continuous delivery of valuable software. So a failure in context of Scrum can be defined as – Unsatisfied customer because of late or sporadic delivery of valueless artifacts.
Large parentage of organizations are believed to fail in Scrum due to the following reasons:
- Not implementing the whole process
- The team is not co-located
- Compromise on the Product Owner / Scrum Master roles
- Compromise on the size of the team
But how do you identify that the Scrum project is failing? There is no one single cause but a combination of problem areas that are dependent on each other like. Broadly the problem areas an be classified into:![]()
- Emotion
- Culture
- Reflection
- Adaption
- Collaboration
In each of the above area, there are different symptoms that can indicate that the Scrum Project is failing. when you encounter such symptoms its easy to jump in and do a quick patch but it will not last longer if the root cause is not addressed. So, we have divided into two categories i.e Symptoms and Root cause under each problem area to help you clearly differentiate between symptom and root cause and fix the problem.
- Emotional
- Symptoms: Individual opposition, Confusion, Subversive Behavior, No Discipline, Apathy
- Root Cause: Fear, Influence, Preference, Superiority, Ignorance, Indifference, Position, Comfort
- Cultural
- Symptoms: Micromanagement, Mini-Waterfalls, Finger-Pointing, Revoking team discussions, detailed reporting, scrum master is seen as accountable for the team
- Root Cause: Heroism, command & control, bad values, limited accountability, hierarchical thinking, individual compensation, blaming, compliance
- Reflections
- Symptoms: Process at sprint n same as Sprint 1, no known Sprint velocity, no hands-on customer demo, no code reviews, stand-up monotonous, test and run before check-in
- Root Cause": Misleading metrics, no group reflections, missing self reflection, missing commitment, non-learning, wrong value definition, comfort zone
- Adaption
- Symptoms: Retrospective without actions, no time for change, do things that do not work again and again, no refactoring, sprint review without consequences, still no tests
- Root Cause: ineffective scrum master, cookie cutter process, imposed process, group pressure, invisible product owner, no empowerment, no adaption, too frequent changes.
- Collaboration
- Symptoms:Task handover, many loose ends, only business analyst talks to the customer, no team planning, not slowing down for teammates, deciding for customer, check-in race
- Root Cause: Segregation, hard-coded communication paths, push-systems, no shared responsibility, separation, turf wars and politics.
Benefits Of Continuous Integration In Scrum – Best Practices In Scrum
Posted on October 26, 2010
Filed Under Scrum Basics | 2 Comments
Traditional Software Development such as in Waterfall Model, programmers often code in isolation for days or even months before integrating different modules developed by the team. Code shared between multiple people and frequent changes often introduce lot of integration complications, dependent bugs etc. In Scrum, team is in hyper productive mode and usually churns out code at a faster pace. Often, Scrum team spends time in debugging conflicts resulted in integrating software modules and it is very time consuming. This is one of the reasons why Scrum experts recommend using CI – Continuous Integration. Continuous Integration allows us to have several clean builds in a day. There are several tools such as Apache Continuum, CruiseControl etc are capable of automating compilation, unit tests etc activities to ensure that the code submitted is always consistent and with good quality.
-
Always use a Software Revision Control – A code repository is a must to manage software development project. Revision Control software such as Subversion, CVS, Rational Clearcase etc are industry standard software that manage your software efficiently.
-
Automating the build – Single command should run the build – using tools such as Ant, Maven, MSBuild etc. This is very essential as it avoids manual build process/conflict/dependency issues and successful builds can even be emailed or SMSed to the concerned people. Build errors/stats could also be documented.
-
Every commit should trigger the automated build – This will ensure the integrity of each commit automatically.
-
Automated tests on built binaries/load (Self Test) – As soon as the build process completes, the sanity test cases are run – automated. Again, the test results can be broadcasted via email or SMS or via a Build Portal. This automation will avoid doing mundane tests on the build. This will give more time for the team to do more serious work.
-
Latest Builds Get Deployed automatically - There is no other better way to please the customer to send the build or deploy the load automatically to their environment as soon as the build completes. We may decide to do this every end of sprint. Customer need to put any effort to get the new load.
Benefits are priceless but the main challenge is to build the CI environment and it requires some time and expertise. There are tools available for developers which could make life simpler.
List of CI Tools:
-
CruiseControl – Java based framework to setup CI
-
Apache Continuum – Continuous Integration Server and Build server
-
Bamboo – Bamboo is used for continuous integration by over 1100 organisations in 53 countries around the globe
-
Cascade – Faster, Smarter Software Development
-
Rational Team Concert – Tool from Rational to improve build process.
Many tools are out there, please try and chose for your Scrum development work. Do let us know your feedback.
« go back — keep looking »

