SEEING IS BELIEVING AND USING IS UNDERSTANDING
Years ago I was active in business development for a rapidly growing company. In my first months in this nice company I was wondering if scrum methodology works in software development, but now I know the great advantages and more important the satisfied customers.
”Seeing is believing” and ”using is understanding” was also a fact in my personal case… Scrum Methodology Works in Software Development. Some companies uses the methodology also in other company areas. For example in sales & marketing departments.
Agility. Speed on development without losing quality and control over budget.
The Scrum Sprint Methodology. This is a continuous flow of short-term cyclic deliveries to ensure uninterrupted momentum while leaving room for flexibility and incremental insights. This approach leads to maximized incremental value. Together, we will create a solution that is an optimal fit to your needs, because we consistently opt for functionalities with the highest added value within the agreed budget.
BASIC RULES SCRUM
Each project has a ‘Scrum master’ and a ‘Project owner’. Together, they are authorized and qualified to make decisions quickly. This doesn’t only concern functionality, but resources in our joint team as well. The Scrum project consists of a minimum of three ‘Sprints’ or partial deliveries. Every Sprint follows a fixed process and starts with a stand-up session at one of our Scrum tables. A Sprint results in a workable partial solution and points of improvement. The first Sprint, the 0-Sprint, is a bit more extensive. The initial installation, procedures and system management choices will then be determined as well. The final Sprint covers implementation.
Fast and phased results, strict management by an experienced scrum master, team spirit through a positive, involved and constructive project ambiance, consensus about results, gradual implementation, with room for new insights and the best results within the agreed time and budget.
ROLE SCRUM MASTER, THIS PERSON IS A KIND OF ORCHESTRATOR
Tasks are: Hosting storyboard definition, poker planning sessions, Sprint delivery sessions, retrospective sessions, organizing stand-ups, daily checking the Sprint progress, how the burn-down goes and informing stakeholders about it, new stories coming any change on the priority? Making sure that the agreed Sprint is done in the way its agreed (for budget and progress control).
ROLE DEVELOPMENT TEAM
The consultant role is mainly testing (first test), helping developers to go through the stories and giving more detailed explanation about the stories (i.e. supporting technical solution). Developer and tester are members of the development team as well.
Tasks are: Helping customer to define the story (all roles), realization of the story (developer), technical testing of the stories (all roles), checking the stories defined by customer/ product owner (all roles), effort estimation (poker planning) for stories (developer and consultant), technical specification for stories (developer), give commitment on the planning (all roles) and attend retrospective sessions (all roles).
ROLE PROXY PRODUCT OWNER
This is a intermediary person who can fill the role of customer in case customer does not have enough resources/ time to describe/ define stories. This person can decide the definition/ content of the story but cannot make financial decisions (i.e. confirmation of budget) as long as customer authorizes him/ her.
Tasks are: Define stories (requirements), define priorities, attend poker planning sessions (give clarification to stories if required), attend stand-ups, attend Sprint delivery sessions, functional testing of the stories and attend retrospective sessions.
This person is the one who describes the end-product functions, has power to make decisions about budget, scope and planning.
Tasks are: Define stories (requirements), define priorities, attend poker planning sessions (give clarification to stories if required), attend stand-ups, attend Sprint delivery sessions, functional testing of the stories, attend retrospective sessions, confirmation of the Sprint planning (in terms of planning and budget).
SPRINT #0 | STRATEGIC BUSINESS AND ARCHITECTURE DESIGN
It’s a fix amount of budget where the software supplier defines the scope/ specs of the end-product. Discuss customer needs, get to know their business and understand the cases and translate the cases into storyboard and architecture. Outcome; business goals, cases, business model and “day in the life of a customer” and story board.
SPRINT #1 | SCOPED PROOF OF VALUE
Proof of our architecture and value & solutions. Outcome is a working pilot that can go live and learning (because both sides need to get experience about the methods, way of workings and solutions).
FOLLOWING SPRINTS | TUNING
Content; asses, tune the solution and iterate. Outcome; transformation of the complete vision into solution. Financially; depends on the case but should be definitive at the end of previous Sprint by having storyboard & poker planning.
RESPONSIBILITIES OF SOFTWARE SUPPLIER
Project management, delivery of the agreed scope, planning and future proven architecture.
RESPONSIBILITIES OF THE PRODUCT OWNER (CUSTOMER)
Definition of scope, prioritization and testing.
NOT RECOMMENDED IN THE ROLE OF THE SOFTWARE SUPPLIER
Story definitions should not be done by the software supplier unless customer authorizes the software supplier as proxy product owner (similar of product owner role but for budget needs to get confirmation from product owner). Sprint delivery should not be done by the software supplier! Daily stand-ups should be done everyday! Cannot be skipped.
NOT RECOMMENDED IN THE ROLE OF CUSTOMER
Change of the priority during the Sprint. It can be done but then the decision needs to be done together with team so that the correct commitment can be given.