I have been a Senior Project Manager and a Scrum Master and Product Owner for many years now. It is most important for a Scrum Master to evangelise all things Scrum. The process should be explained, artefacts should be created, roles clearly defined and followed, and ceremonies adhered to and their agendas and content created in line with the Scrum ideology.
Scrum is a flavour of Agile. It is probably worth explaining here what Agile is, and then building on it to explain Scrum. Agile is a Project Management methodology that is quite different from the older Waterfall methodologies, whereby the business agrees to produce a product by a deadline. It’s quite a linear approach with the focus on timescale, scope and, of course, cost. There is an emphasis on deciding on the key features of a product, including the technology to be used, very early on in the lifecycle. This can make it very difficult to change direction later on.
Agile is a much more fluid process that values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and finally responding to change over following a plan. These principles are outlined in the Agile Manifesto.
This allows for clients to release the product more often, and fundamentally, to change the direction of a product much more easily based on requirements. This, compared to the static scope and Project Initiation Document created in PRINCE2 for example, is revolutionary.
In Scrum, the commitment from the business becomes an agreement to deliver as much product as it can within a short length of time (typically two weeks) – referred to as a Sprint. The end result of a sprint should be releasable code, often called Minimal Viable Product (MVP). Then more sprints are put ‘nose to tail’ and deliverables from each sprint build on the product released in the previous sprint. This also has the added benefit of maximising the opportunity for regular customer feedback and meetings with the client, as well as showing a return on investment sooner in the Software Development Life Cycle.
It is important for development houses to use an iterative design and development approach such as Scrum for many reasons, but mainly because you wouldn’t want to build a product that delivers on time but no longer leads the market (although it may meet the original specification), or that the client’s customers will not want to use, and the client will not want to pay for. Requirements can, do and will change – Scrum allows us to respond to that change.
To enable Scrum in a development house there are a few concepts we need to adhere to. We commit people to a cross-functional team. They are self-organizing and we check they have the necessary skills to complete their sprints content. The team is all encompassing and there shouldn’t be a reliance on anyone outside of ‘the development team’. There is no team leader, and in general the team should sit together, even if it means people moving to another part of the office. The point is that the team must be able to interact easily and often.
Issues that arise and required decisions are overcome by the team as a whole, usually at a Scrum Ceremony, such as Daily Stand-up or ‘Scrum’.
This is a whistle-stop tour of Scrum and Agile processes. There is so much more to the methodology, and so many more sub-processes that I could write about (use of TFS for Agile, Jira Usage, story points, planning poker, burndown etc). Why not come and get involved with Derivco and find out for yourself?
By Alexander Brook, Development Team Lead, Business Intelligence, Derivco Ipswich