1

After taking a look to SCRUM it doesn't same to me "enough" to lead a project since it isn't disucssing the technical side of it, so my questions are:
1-is it possible/recommanded to combine SCRUM with some unified process or any other software development process ? How to make specifications in this case?
2-What about planing the project : Divide the project into sprints and use the Y method in each
Thank you

4
  • Is 2Tup really predominantly French? Jun 8, 2016 at 14:27
  • I'm not sure I've understood what you mean, but that was just an example Jun 8, 2016 at 15:01
  • 1
    All of my Google searches for 2TUP lead to French results. Anyway, mixing together two different software development management methodologies seems ill-advised in any case. Jun 8, 2016 at 15:05
  • 1
    Oh sorry you're right didn't find any english result for 2TUP too, but SCRUM isn't speaking about how to "make" the project I mean it isn't not talking about conception and technical needs (only talking about functional needs) Jun 8, 2016 at 15:27

1 Answer 1

3

You're right that Scrum doesn't discuss a lot of details. But that's OK because it's a process framework.

For example, Scrum says that the Product Owner is responsible for adding to, removing from, and prioritizing the Product Backlog but doesn't say how the Product Owner does this. That's because everyone who implements Scrum may have a different process. Scrum in a more regulated environment would likely need to implement a more rigorous change control process to change the backlog, while other situations may not require artifacts to produce. It leaves it up to the organization to define how the Product Owner (and possible supporting people) go and figure out what requirements to write, how to write them, and how to prioritize them for the development team.

Another example is the daily work that teams do. Usually, teams implementing Scrum will write automated unit tests because they can be run automatically by developers and automated build tools to get rapid, incremental feedback on work. However, Scrum does not mandate this. Scrum simply says that at the end of the Sprint, you should have an Increment that meets the Definition of Done and is usable. How you ensure that you have an Increment is up to the organization and team.

Scrum defines what its creators see as the minimum amount of roles (Product Owner, Development Team, Scrum Master), events (Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective), and artifacts (Product Backlog, Sprint, and Increment). In your organization, you may choose to have other roles.

For example, a lot of critical software requires independent verification of work. In this type of environment, you may choose to have an Independent Verification Team that operates alongside the Development Team, but with the appropriate independence from the creation of the software and associated deliverables.

Officially, tailoring Scrum makes it not-Scrum (from the Scrum Guide):

Scrum is free and offered in this Guide. Scrum's roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

I don't consider this to be realistic as it doesn't recognize the variety of environments in which software is developed. I wouldn't recommend combining Scrum with something else, but instead using Scrum as a starting point and then tailoring to your environment within that framework. If Scrum is so wildly unsuitable for you, perhaps a different process framework should be considered as a starting point for tailoring. If Scrum isn't right, there are alternatives - Disciplined Agile Delivery, for example, builds on ideas from Scrum, Kanban, Extreme Programming, Lean, and the Unified Process (in particular Rational and Agile). The Crystal methodologies that Alistair Cockburn described may also be a good starting point.

2
  • What I read in that quote from the Scrum Guide is that if you tailor by removing stuff, then the result is "not-Scrum", but if you tailor by adding ceremonies/artifacts/whatever, then the resulting process can still be called Scrum. Jun 9, 2016 at 8:51
  • 1
    @BartvanIngenSchenau Perhaps the use of the word "immutable" is wrong in the guide, since it means "unable to be changed" or "inflexible". On one hand, your stance makes more logical sense to me, especially since Scrum is a framework. On the other hand, it would allow you to add ceremonies that are not consistent with the agile methods and call the result Scrum. I suspect part of that statement comes from branding the idea of Scrum and not wanting people who are doing waterscrumfall to call it Scrum and leave a bad taste for people who are supposedly experiencing Scrum for the first time.
    – Thomas Owens
    Jun 9, 2016 at 9:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.