What is Scrum Team Culture? When a Company takes the steps for moving from a Traditional IT setup to an Agile Environment, there will be some teething problems due to the Culture Change. This is on several fronts:-.

• the Organisation is still organised hierarchically and find it challenging to accept the way of Work of the Agile Teams.
• the Traditional roleplayers within the IT Business Unit, such as Project Managers feel threatened and redundant.
• the Developers and Testers need to get to grips with the new way of Work.

Throughout the transition period, there needs to be comprehensive Change Management. This is in order to create an understanding and an agreement about how the Team Works and Delivers. The selected Agile Framework might make this journey easier. For example, if the business utilizes Lean to any degree, a Lean or Kanban Agile Development Team will likely get higher Acceptance.

Scrum Team Culture: Team Organisation

For those who are not familiar with the Scrum Framework, a Scrum Project is executed by small Teams. These teams range from about 6-9 members. The Team is Cross-Functional, except for 2 specific Roles that are essential to the Scrum Team and the Scrum Team Culture. These roles are the Product Owner and the Scrum Master. The other Roles are Fluid and Team members can presume different Roles to fit the scenario.

The Work is broken down into Iterations called Sprints, that last from 1-6 weeks. The content of each Sprint is drawn from a Repository called the Product Backlog, which is Managed by the Product Owner. The Work is assigned based upon Priority, with the highest Priority, most complicated and least-understood Items being allocated first, so that the most crucial Work is executed at the start of the Project.

Scrum Team Culture: Project Meetings

The Project Meetings are an important Feature of Scrum. These meetings are clearly described Meetings that have specific outcomes. These are:-.
-‘ Sprint Planning’ – where Product Artefacts, like User Stories, are extracted from the Product Backlog, assessed as to complexity.
-‘ Daily Scrum’ – a fifteen minute stake in the ground.
-‘ Sprint Review’ – On completion of a Sprint, a “show-and-tell” is held with the Stakeholders, where the Sprint output is demonstrated.
-‘ Sprint Retrospective’ – the effectiveness of the Team and any enhancements that might be applied to the procedure are discussed and applied to the next Sprint. If this technique is applied diligently, the Team’s performance should improve Sprint by Sprint.

What You Can Get Out Of A Scrum Team.

The temptation is to compare Scrum Development to Traditional Development, but things are not that simple. This is a different, non-hierarchical and Collaborative kind of Working, although the goal is common- to Develop a Quality Software Product that meets the Customers’ requirements.

Below are the terms of referral for the Team as an entire, the Scrum Master and the Product Owner.

What The Scrum Team Is

The Scrum Team is:.

• A Small Team of 6-9 individuals.
• An autonomous unit that is Self-Organising and Self-Managed. The Team members decide on issues such as whether a Team member can Work from home for a specified period
• Often arranged as a Team simply for the current Product Development, who disband on conclusion, although it is suggested that the Team stays together for the next Project, as they have learnt to Work well together.

• Plan the Work content for the Sprint in the Sprint Planning Meeting with the Product Owner
• Do not have a fixed deadline. They Work towards completing the Sprint
• Do not have a Project Manager. The Team decide and act jointly
• (Ideally) sit together in a dedicated space
• (Generally) a Jack of all trades, can move between Roles, e.g. getting the User Story (atomic requirement) documented and later Working as a Tester
• Develop through Tuckman’s 4 stages of Team growth to become a Collaborative and efficient Team

We found these books great for finding out more information on Agile Scrum:

What The Scrum Team Is Not

• Large Teams. Beyond the recommended size, if more resources are needed, they should be organised into multiple Teams
• A group of Workers who are required to submit to pressures and directives from outside their Scrum Environment.
• A permanent Workforce. It is not a bad thing, however, to keep the Scrum Team a cohesive unit for the next project, as mentioned
• Are assigned Work packets by a Project Manager, based on the Project Manager’s opinion
• They Work to Project deadlines and milestones
• A Project Manager commands and controls the Project resources.
• Sit in a space with colleagues with the same Role, Job Description, e.g. Testers.
• A specialist in one thing, e.g. database design. Does not acquire skills in the other domains.
• Emphasis is on the individual’s Development within the company, not as part of a Team.

What The Scrum Master Is

• Promotes the message of Scrum to the external Stakeholders: is a Change and Communications Manager in this respect
• The Scrum Master provides support to the Team so that they can do their best Work
• Protects against outside interference
• Is the champion of the Scrum practice, and keeps the Team aligned to the Principles and Practices. i.e. the Scrum Quality Manager
• The Coach, who ensures that technical skills are enhanced where the Project requires it, for each Team member

What The Scrum Master Is Not

• Is not a Manager of the people in the Team, but a co-worker.
• Is not a Project Manager.
• A trainer.

What The Product Owner Is

• The person in the hot seat for successful Product delivery
• Usually is a Person with a comprehensive understanding of the Business and Works in the Business
• An internal resource while the Product is being Developed
• Owns the Product Backlog and prioritizes its contents
• Is fully committed to the Team and the Project while the Project is Under Development
• The arbiter on whether the Acceptance Criteria have been met
• The person who authorises the release of a successful Sprint
• Able to cancel or halt the Sprint if he feels the circumstances demand it.
• A co-creator of the Product
• Responsible for ensuring ROI on the Project

What The Product Owner Is Not

• The recipient of the Product.
• An IT resource.
• The Product Manager, who is an external resource.
• A Business Analyst.
• An occasional visitor to the Team and is absent most of the time, Working on his day task.
• A Manager.

These lists simply give a sign of who the Scrum Team are and provide an indication of the Scrum Team Culture. The actual practices and how they differ from a Traditional Project are not evaluated here. Apart from the Sprint Retrospective, which is the same as a Project Retrospective or “Lessons Learnt” meeting in Traditional Project Management, the other Meetings, while keeping the Project on Track, are quite different and unique to Scrum.

The Scrum Framework is best suited to Projects with a high level of uncertainty, such as Development of an entirely new Product. As each Sprint is achieved, the Confidence Level and understanding increases. One also does not have to choose Scrum as the Agile Framework, Kanban allows for larger Teams, for instance. the biggest Risk on a Scrum Project is skimping on the Meetings. The Scrum Master has the stewardship of the Scrum Practice and ensures adherence by the Team. If Sprints are executed as they should be, the Scrum Framework has a high success rate. If for some reason, the Project is deemed to be going off the rails, the Product Owner has the authority to cancel or suspend the Project. This can be done very quickly, and does not create the Waste of Time, Cost and Resources that an unsuccessful Traditional Project will accrue.