As Agile, and in particular, Scrum, continue to make inroads into business, many are grappling with just what it means, and how to do it.
Executive leaders work hard to understand the meaning and implications of “the Agile Organization”, and just want the truth of the matter regarding risk, effort, organizational efficiency, product and service quality, cost, growth and strategic success.
Functional and People Leaders often become lost in the jargon, without a clear understanding of what the words and phrases mean. Scrum, Kanban, Sprint, Product Owner, Scrum Master, Lean, and even Agile itself are tossed around in meetings, without common definitions. Misunderstandings abound, with the most commonly expressed one being that a Scrum Master is just another term for Project Manager.
Many decision-making and high influence business stakeholders continue to believe that Agile means no more documentation (yay!), that they can change their minds as often as they want (YAY!), and that they no longer have to worry about working with Business Analysts, Solution Architects, Process Analysts / Designers, User Experience Analysts / Designers, or Quality Assurance / Testers (Whoopee!). Old ways die hard, and the inertia of Waterfall requirements of their time and effort, always grumpily acknowledged to begin with, are now held close and dear, with the realization that Scrum demands ongoing, high levels of involvement throughout the project from all of them, instead of just at the project beginning and end, leading to rejection of the whole thing out of hand.
Human Resources struggles with how to understand and integrate all of this into employee lifecycle management, from recruitment through performance management, compensation, job ladders, training, and professional development career paths.
And legacy Developers, born and raised with Waterfall definitions and processes embedded into their DNA, often look at Agile Scrum with trepidation, or with the view that nothing really changes for them. That is the focus of this article.
Let’s start by going right to the source: the Scrum Guide. As described in the Guide,
“the fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of one Scrum Master, one Product Owner, and Developers. Within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.
Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.
The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required. They are structured and empowered by the organization to manage their own work. Working in Sprints at a sustainable pace improves the Scrum Team’s focus and consistency.
The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.
Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint. The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:
Creating a plan for the Sprint, the Sprint Backlog
Instilling quality by adhering to a Definition of Done
Adapting their plan each day toward the Sprint Goal, and
Holding each other accountable as professionals.”
As identified above, Scrum does not imply that a single individual Developer has to be able to do everything themselves, nor that the term Developer means only traditional Software Programmers. However, the Scrum Guide stipulates that Scrum does not include the creation of sub-teams with their own team leaders, as in Waterfall methodologies. So how is this reconciled?
Developers transitioning from Waterfall-based project environments are often challenged by the 360 degree nature of accountability within Scrum, and the extensive range of skill sets required to be successful. For example, in a Waterfall-based methodology, software developers can normally rely on the services of:
A Project Manager, who works with the team to develop guidepost documentation, including but not limited to:
Deliverable Breakdown Structures and Descriptions
Work Breakdown Structures and Descriptions
Major and Minor Milestone Breakdowns and Descriptions
Dependency Models and Schedules
Financial and Risk Management Plans
Project Control Plans
Business Analysts, who, working alone or with Process Analysts and Designers, capture and manage extensive requirements documentation, including the development of static and dynamic requirements models including but not limited to:
Comprehensive stakeholder group identification and analysis
Business and UML System Use Case Diagrams, along with text-based human-system interaction Use Case Descriptions
Workflow diagrams of As-Is and To-Be business process, such as UML Activity Diagrams and BPMN diagrams
Text and graphical representations of business, functional and the many categories of non-functional requirements
Quality Assurance Analysts and Testers, for the development of test cases and scenarios at the unit, functional, system, inter-system, user acceptance and business acceptance levels.
User Interface / User Experience Analysts and Designers
Database Analysts and Developers
eCommerce and other Web Specialists.
Because everyone who is not a Scrum Master or Product Owner is called a Developer, legacy developers (and others) may wonder if Scrum means that all those specialists simply go away because their skills are not needed.
The answer is No. It does mean that:
the term Developer is inclusive of everyone who is directly involved in developing the business solution. This is a fantastic, and healthy perspective, without the risks that can arise from project team members focusing primarily on their specialized contributions, and communicating with other specialists mostly at handoffs and periodic status update meetings. With Scrum, we’re all in this together every day, with an explicitly stated common goal, all the way through.
at project inception, all skill sets required to deliver the product must be identified and incorporated into the Developer group, and that the structure and cadence of their work must be fully integrated and highly collaborative on a daily basis. Everyone works together to achieve incremental shippable product within time-boxed Sprints, rather than in a mostly separate fashion over extended Waterfall project phases.
That said, the competency bar for individual Scrum Developers is considerably higher than in Waterfall methodologies, hinging on the term self-managing. There is no Project Manager in the traditional sense, and Scrum Developers must resist the temptation to consider or pressure the Scrum Master to become one. The Scrum Master manages the Scrum Process, not the Scrum Team. Scrum Developers must be able to take complete ownership for their own time and effort management. With freedom comes responsibility.
In addition, Scrum represents a flat, rather than hierarchical, team structure. The Scrum Master, Product Owner and Developers are co-equal. Everyone owns the accountability for achievement of the Product Goal. So, Scrum Developers co-equally own and are accountable for demonstrating the official Scrum Competency set in everything they do:
Understanding and Applying the Scrum Framework
Developing People and Teams
Managing Products with Agility
Developing and Delivering Products Professionally
Evolving the Agile Organization.
Finally, there is, for some, the greatest challenge: the critical need for interpersonal effectiveness, the so-called “soft skills”. These flow directly from the Scrum Competencies and include the ability, and the desire, to work with others towards shared goals. Interpersonal effectiveness competencies include collaboration and teamwork, empathy, active listening, critical thinking, solution focus, optimism, emotional intelligence, written and verbal communication, diplomacy and tact, win-win negotiation intention and skills, a proactive conflict management mindset and skill set, professional humility, and many others.
Isolated Genius, Lone Wolf and Prima Donna Developers have no place in Scrum.
©2022 Jason Questor
Gemba Group Solutions
www.gemba-group.com
Comments