Why Scrum sometimes fail

The organization is not ready to adopt Scrum
Maybe the most common way for Scrum to fail is that organizations are not ready to adapt agile development. The Product Owner continues to work controlling instead of facilitating, doesn’t empower the team, and won’t let them come up with their own way of working. This fear of loosing control is seen when requirements are over-specied and the team has lots of constraints. It is therefor essential to have an experienced Scrum Master who can help the Product Owner write requirements more abstract and to make sure that management knows what is needed in order for Scrum to work in their organization. In conclusion, for Scrum to work, a change of mind-set is necessary.

The Product Owner can’t prioritize
Another thing that is guarantied to wreck a Scrum project is if the Product Owner is unable to prioritize the work. One major benfit is that the development team always should work on what gives the most business-value. This can of course only be done if the Product Owner know what he or she is doing, make good decisions, and is able to effectively communicate and collaborate with the team.

The teams are not ready to work cross-functional
Traditionally there arefixedxed roles within the team; designer, programmer, tester, CM etc. In Scrum, everyone in the team should work cross-functionally.
The benefits of this is that everyone feels much more responsible for quality and the overall success of the project.

The team are not willing to improve their engineering skills
Much like some organizations and managers can have problems adapting to a new method, so can developers. A common problem is that developers doesn’t work in an Agile fashion when it comes to method and technique. They have to use the power given to them and react to upcoming problems – otherwise the project is doomed.

Already existing problems become obvious
The problems that will arise the first time you try Scrum will probably not have anything to do with the method itself. Instead, it causes problems that are already there to become obvious.

  • Every day you might find out that the people in the team didn’t do what they were suppose to.
  • Only one team member knows how to build the system.
  • By looking at the Burndown chart, you will early see that your project is not on track.
  • At the end of every Sprint you might find out that the team are not progressing as marketing (project management) has hoped.

On the bright side – you will find this out while you still have time to fix it.

Advertisements

SCRUM – Advantages

SCRUM – Advantages
Short iterations (Sprints) :  By having these short iterations and daily meetings, the team will always know exactly where they are all the time. For example: every day you will know which features remains to be completed, if the team members did what they were suppose to, and by looking at the so called Burndown chart (visualizes estimated remaining work) you will see if the team is progressing as the marketing (project management) has hoped.
No waste of time:  Because you only work on a few, top-priority, features at a time, Scrum makes sure that the team is not spending time and money developing stuff that no one will use. As a result, the development speed is likely to increase
Cross-functionality: Scrum wants to avoid the barrier between different rolls and make everyone work together towards the same goal. Everyone is responsible for the whole product and by working together the team will join their skills to create better software with higher quality.

According to two of the principles behind the Agile manifesto

  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The best architectures, requirements, and designs emerge from self-organizing teams.

Characteristics of Successful Projects

In the funding application process, the objectives of the project will have to be clear, partnerships with organizations with similar objectives need to be sought and should develop a detailed action plan for the project.

Consider the following traits that characterise successful projects:
1. Clear objectives – The most successful projects have clearly defined objectives from the outset.
2. A good project plan – A carefully thought-out plan serves two purposes. First, it allows everyone involved to understand and perform their part in the
project. It shows who is responsible for what and estimates how much money, people, equipment and time will be required to complete the project.
Second, it serves as a monitoring tool, allowing you to take early action if things go wrong.
3. Communication, communication, communication – Project is a collaborative effort between all of the individuals and organizations involved. All need to work together to maintain effective and continual communication between the parties.
4. A controlled scope – Numerous issues will come up throughout the project, and not all of them will contribute to the overall objectives. It is important to stay focused on the priorities, with little wasted time or attention.
5. Stakeholder support – Projects typically involve several stakeholders, who invest time and resources in the project. It is important to maintain stakeholder support throughout the project, so the project team can meet its objectives.

Scrum: a project management method for agile software development

  1. Scrum roles:  Scrum has three important roles; the Product Owner, the Scrum Master, and the Scrum Team.
    Product Owner:  The Product Owner is the one representing the customer and the business owners of the project. He or she is responsible for creating and prioritizing the Product Backlog, and at the end of the Sprint, the Product Owner is also responsible for reviewing the system. For commercial development, the Product Owner may be the previous product manager. For in-house development, the Product Owner could be the project manager or the user department manager.
    Scrum Master:  The Scrum Master is responsible for ensuring that Scrum values, practices, and rules are enforced. The Scrum Master is the driving force behind all the Scrum practices; he or she sets them up and makes them happen. The Scrum Master presents management and the team to each other. The Team Leader, Project Leader, or Project Manager often assume the Scrum Master role.
    Scrum Teams:  Scrum Teams are small (5-9 people), self-organizing and cross-functional, thus performs all design, development, tests etc. together. The team has full authority to do whatever is necessary to achieve the Sprint Goal. It is only constrained by organizational standards and conventions. Team members can interview others, bring in consultants, read books, browse the web, or whatever they need (within budgetary constrains) to achieve the goal. There are no roles or titles within the team and the members doesn’t have job descriptions other than doing the best work possible. Since the team size are relatively small, multiple teams often develop product increments in parallel, all teams working from the same list of wanted features. This set-up is known as a Scrum of Scrums.
  2. The Process
    Sprint Planning Meeting : At the Sprint Planning Meeting, customers, users, management, the Product Owner and the Scrum Team determine the next Sprint goal and functionality. The Sprint Planning Meeting actually consists of two separate meetings. First, the teams meets with the Product Owner, management and users to figure out what functionality to build during the next Sprint. At the second meeting, the team works by itself to figure out how it is going to build this
    functionality during the Sprint.
    Daily Scrum Meetings: Each Scrum Team meets daily for a 15-minute status meeting called the Daily Scrum. The Scrum Master is responsible for successfully conducting the Daily Scrum, by keeping it short and making sure the team members speak briefy. Other stakeholders can also attend the Daily Scrum, but they are there as guests and are not allowed to interfere in any way.Every person from the team shall, one at a time, briefly answer three questions:
    – What have you done since the last Daily Scrum?
    – What will you do between now and the next Daily Scrum?
    – What got in your way of doing your work?
    The first two questions gives the attendants a brief progress report, and lets the team synchronize their work. If a team member identifies something that is stopping him or her from working effectively, it is the Scrum Master’s top priority to remove that impediment. Such impediments can be that a server is down or that the team member was asked by management to do something else.
    Sprint Review Meeting:  The Sprint Review Meeting is an informal meeting, where the team presents what it has been able to build during the Sprint.
    Management comes to the Sprint Review to see what the team has been able to do with the resources that it has been given. Customers come to see if they like what the team has built and the Product Owner comes to the Sprint Review to see how much functionality has been built. Since this is suppose to be an informal meeting, no one should prepare extensively for it. That is why Power Point presentation and similar are forbidden. The Sprint Review is a working meeting where everyone should get an understanding for the product increment, as this is the knowledge they will need for the next Sprint Planning Meeting.
    Sprint Retrospective Meeting:  After each Sprint Review, but before the next Sprint Planning Meeting, a Sprint Retrospective is held at which all team members Retrospectect about the past Sprint. The purpose of the retrospective is to make continuous process improvement.