Blog

Scrum Does Not Tell You How to Build Stuff
,

Scrum Does Not Tell You How to Build Stuff

There have been some respected leaders in the industry that evidently just don’t get what Scrum is meant to provide and, more importantly, what it’s not.

Scrum does not tell you that you have to use TDD, BDD, Continuous Integration, Continuous Deployment, OOP, etc. Scrum also does not tell you that you have to use User Stories that are estimated with the Fibonacci-ish scale. It doesn’t tell you how and if to do exploratory testing, load testing, performance testing, acceptance testing, or anything else.

Why? Because it wasn’t meant to. Are all of the things I mentioned above good things? Absolutely! Is every team ready to adopt them? NO.

100% of the teams that I’ve coached were not ready to take on the additional stress of learning these practices that Scrum does not require. The FIRST thing they had to work through was how to be a team. How to understand what commitment means. How to respect and trust each other. How to feel and be empowered. How to build trust with the customer that had been long lost or most likely never existed. How to better predict what will be delivered. What it means to deliver VALUE.

Focusing on these things is many times almost more than a team can handle. I’m surprised that anyone would think it would be a good idea to right away add on top of this the pressure of learning new technical practices. The fact of life is that most enterprises do not have the processes, infrastructure, or culture that allows quick adoption of modern development practices. Change takes time. Take a deep breath and embrace it. Only then will you be able to make real change.

Talk to Us Today

3 Comments

  1. Al Shalloway

    It’s not that some of us thought leaders don’t get what Scrum is supposed to provide, it’s that some of us disagree with this classic view of Scrum as a super-light framework where people have to reinvent much of the wheel. Agreed that becoming a team is critical, there is not only one way to do it. Aligning around technical practices is one way, insisting on continuous integration is another. Starting with your current process and using the Kanban Method is even another (not any more my favorite than classic Scrum).

    Scrum’s starting mandate (new roles, new team structure, new timeframes) often causes much more stress than the methods you describe.

  2. CK

    Read only this part:
    “The FIRST thing they had to work through was how to be a team. How to understand what commitment means. How to respect and trust each other. How to feel and be empowered. How to build trust with the customer that had been long lost or most likely never existed. How to better predict what will be delivered. What it means to deliver VALUE.”
    Think of it…
    That can define your goals for improving a team’ production. And I agree with Andre that these are common goals, domain-agnostic (not specific to IT e.g.).
    Then you can define the way to get it. Depending on the domain, the constaints, your comfort zone…

  3. Phil Thompson

    I agree with your statements of what Scrum does and does not include. However in my experience Scum is less likely to be successful if the team (or general IT culture) has not adopted some of the technical practices first, in particular continuous integration and some level of test automation. The Scrum practices will become unsustainable and will then wither and morph into the old ways of doing stuff. Changing roles and behaviours has an impact outside the team – it is starting to demand wholesale organisational change – product management – stakeholders etc – absolutely right but it is very difficult. Adopting the Technical practices, however, can be done in relative isolation from the rest of business operations, enabling you to manage that change in relative isolation.

    So yes technically Scrum does not mandate a whole pile of XP style practices but it is more likely to be successful if you have adopted a few first and adopting those will be easier than adopting Scrum.

    Regards
    Phil #philagiledesign

Leave a Comment

Your email address will not be published. Required fields are marked *