Scrum Is It Really For Developers?
This seems like a very inflammatory comment, but let me explain.
The backlog, sprint planning, sprint reviews and retrospectives; lead us to a better interaction across the business sectors. Thus allowing the developers to deliver the right functionality; at the right time for the right money. Scrum provides a project management framework that allows delivery of software that the business wants.
One of the key tasks for the developers is that each feature delivered must be ‘DONE’
This is what the Scrum Guide by Ken Schwaber, from the Scrum Alliance defines what delivers a done feature.
Scrum requires Teams to build an increment of product functionality every Sprint. This increment must be potentially shippable, for Product Owner may choose to immediately implement the functionality. To do so, the increment must be a complete slice of the product. It must be “done.” Each increment should be additive to all prior increments and thoroughly tested, ensuring that all increments work together.
In product development, asserting that functionality is done might lead someone to assume that it is at least cleanly coded, refactored, unit tested, built, and acceptance tested. Someone else might assume only that the code has been built. If everyone doesn’t know what the definition of “done” is, the other two legs of empirical process control don’t work. When someone describes something as “done”, everyone must understand what “done” means.
Done defines what the Team means when it commits to “doing” a Product Backlog item in a Sprint. Some products do not contain documentation, so the definition of “done” does not include documentation. A completely “done” increment includes all of the analysis, design, refactoring, programming, documentation and testing for the increment and all Product Backlog items in the increment. Testing includes unit, system, user, and regression testing, as well as non-functional tests such as performance, stability, security, and integration. Done includes any internationalization. Some Teams aren’t yet able to include everything required for implementation in their definition of done. This must be clear to the Product Owner. This remaining work will have to be done before the product can be implemented and used.
Which I think gives the clearest definition of what DONE means, and gives the PM and the business a clear definition of what to expect.
However, it still seems to leave us with a very unsatisfactory and “hand wavy” definition if how the developers achieve this state. The process itself only defines the end gate, that deliverable features must be ‘Done’. The above excerpt goes someway to define what is required to achieve that state of ‘Done’, it just doesn’t explain what tools and practices the developers and testers need to achieve this state. You could argue that this is implied by that a Scrum team needs to be ‘Self Organising ’. But is this acceptable? If you’re team has agile experience then I think that this is acceptable, if they don’t have this experience then I don’t think this is fair. It almost seems to be setting new Scrum Adoptees to fail from the start.
We are all aware that there are resources a plenty for developers and testers on agile practices, tools, frameworks, etc. So learning how to develop in an agile manner is possible. However many Scrum practioners’ tell you that you should only do Scrum the way it’s prescribed until you are fully conversant with the way that it works. Until then you should refrain from making changes to the process until this point. This just doesn’t seem to tally; if these are not prescribed as part of the framework and that you must work out how to integrate the relevant testing and development practices, into Scrum. It seems inexplicable to me that these are not included from the outset.
Could this be the reason why there is such reluctance from business to accept Scrum as a framework? After all if the framework is structured in such a way that you will have difficulty getting the developers on board; why should it be expected that the business will accept that Scrum is capable of delivering what it promises?
It leads me to believe that the Scrum Framework needs to change from its perceived status of being purely being aimed at Project Managers and to make sure that it properly includes testers and developers so that it is a complete delivery framework. It must make sure that it engages all the delivery team and not just the PM. It must suggest tools, frameworks. So those who are new to Agile / and or Scrum are given the full toolbox to confidently and more importantly successfully implement it.
So that finally the ‘PIGS’ are completely confident that they can achieve the state of ‘DONE’.