A deeper understanding on…
The Development Team
Road to PSM III — Episode 9
A short recap:
I’m going to rewind a bit (all the way back to ‘Episode 1’ of this series), where I wrote about the core of Scrum and the definition of Scrum.
- What conditions allow teams to best address complex adaptive problems and delivering products of the highest possible value?
- How can a team best be organized to optimize flexibility, creativity, and productivity?
Expanding on the empirical process control theory, a lightweight framework was created. This framework consists of self-organizing, cross-functional teams that iteratively delivers increments to achieve the aforementioned. They operate from the pillars of Transparency, Inspection and Adaptation. Even then, only when the Scrum Values are embodied by the team, these pillars “can come alive and build trust for everyone”.
Sure this may sounds like some Star Trek technobabble to some, but if you have followed the series, I hope you share a somewhat similar level of understanding of the above. In any case (just to try and get us on the same page), I’ll try to put it into my own words how everything in the Scrum Framework enables and empowers the Development Team.
Scrum is teamwork. A team that is trusted and empowered to self-organise, is best equipped to handle complex dynamic challenges.
“When the words “develop” and “development” are used in the Scrum Guide, they refer to complex work.” — The Scrum Guide.
Being cross-functional and having a clear collective purpose, they can develop a collective sense of accountability. They will focus on developing valuable output. After all, the product represents them.
The Development Team are ‘Value Creators’.
By removing titles for Development Team members, Scrum really drives home that the whole team is collectively responsible. Scrum Developers apply themselves to achieving the set goals, even if this involves adapting oneself. They step up and step in when it counts. They continuously discover what they are capable of.
No one is limited to one’s job profile when it comes to creating and delivering working increments together. In addition, a Development team can also not be divided into sub-teams for similar reasons.
Examples of ‘mindsets’ to avoid in a Development Team:
- “I am a [designer] so I will only [design]”;
- “I need [more info] before I can [start]”;
- “I will only do [tasks] that have been defined in [tool x] according to [format y]”;
- “I am [senior], so I don’t have to do [mundane tasks]”;
Everyone shares the responsibility in getting the best results. There can be no ‘pecking order’ (junior, medior, senior). ‘Lower level tasks’ are not delegated to ‘less qualified’ members.
It is all about departing from existing ‘frameworks’, to break through status quo and invisible barriers. So when moving to Scrum it really is time to ‘detox’.
Now having ‘removed’ all titles, Scrum introduces only two roles, dedicated to enabling the team to truly focus on creating value: The Scrum Master and the Product Owner. They don’t manage the team, the Scrum Team manages itself. Those two roles are there so they can do just that. Indeed, not even the Scrum Master is a manager the team reports to, the Scrum Master is there to serve the team. It’s called servant-leadership for a reason.
“Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.” — The Scrum Guide.
“Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.” — The Agile Manifesto.
Development teams don’t only optimize the product, they also improve themselves and the work environment, supported by the Scrum Master.
The team continuously aligns in order to develop ‘transparency’. Team members collaborate frequently. This means they interact directly often, at minimum during the Sprint events. Being cross-functional and self-organising, this should stimulate inventiveness and creativity in complex environments.
When working with others, most prefer to do this from behind one’s own desk. They simply back-and-forth over chat, mail, or comments in a project management tool. It feels safe somehow. This is most commonly so, when working with others from different organisations or departments, even when in pursuit of a common goal. Unfortunately, this comfort can get in the way of achieving the Sprint Goal.
“The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.” — The Scrum Guide.
The team experiments, learns, improves throughout. Call it ‘Kaizen’ if you will.
Many managers might argue that personal development is one’s own personal responsibility (which is true to some extend) and thus consider this to be something someone has to personally invest in… in their ‘own’ time.
Other managers may consider offering courses and training as a way to reward loyal employees. They might also argue that time spent training is not time spent producing, and thus it is unproductive. Some will argue competent employees are hired not trained. They might argue that’s for schools and internships, right? Others might argue that time spent producing is the only training required for getting the job done.
Training and courses generally take place in infrequent intervals when a employee and employer agree that ‘the time is right’. Organisations where this mindset is dominant, might resist the regular recurrence of Retrospectives. They might argue that, for teams running one week sprints, they don’t need Retrospectives or team improvements every week.
To stimulate creativity and productivity, Scrum makes continuous improvement a habit. So how does your organisation stimulate ‘continuous improvement’ for you and your team?
Development Teams may be considered to be a bit rebellious. Not even the Scrum Master can tell them how they should do their work. The self-organising concept may not sit well with those who spent years and years operating in the role of a project or team manager. After all, the mere notion that ‘their’ team might operate better without them, might not even have entered their darkest dreams.
They will continuously argue that their team either isn’t ready to self-organise, or they they simply don’t even want to. Thus they might not be motivated to help the teams (learn how to) self-organise.
There is truth in this, to a certain extend, we are all creatures of habit after all. Teams that are used to working a certain way, won’t just suddenly flick on their super awesome self-organising super power abilities when introduced to Scrum. This is similar too for specialists moving from single-functional teams to a multi-functional one.
Though the mindset required to make it work isn’t to acknowledge that they can’t do it, just that they can’t do it yet. This truly tests if an organisation is motivated enough to trust in and commit to making it work.
I already covered why the Scrum Team is organized the way it is in Episode 6 — The Scrum Team, and I don’t want to be repetitive to those who follow my series, but some subjects deserve some repetition.
The Development Team consists of three to nine members, also counting the Scrum Master and Product Owner if they are also executing the work of the Sprint Backlog. The Scrum Guide explains well enough why this is.
“Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains.” — The Scrum Guide
A Development Team requires all the competences needed to be able to deliver a “done” working increment each Sprint. It might be intuitive to expand a team with new members to onboard such new expertise. But remember that Scrum teams also have a continuous improvement routine in which they can develop required competences too. The bigger the team, the more complex its organisation will become. Or as John Clopton puts it: “Mo’ people, mo’ problems.”
So when expanding the team, consider the impact of adding complexity to an already complex environment.
Perhaps the team’s ‘ability to learn/adapt’ is too much of an uncertain factor to weigh in. Yet, a creative development process is a learning process, during which ideas are manifested and validated. We’ve learned that we are better at decision making as we are progressing; rather then making decisions upfront. In some occasions it is also better to train now, whilst progressing, rather than delay finding someone trained.
Changes to the team will have a (temporary) negative impact on the productivity and stability/reliability/predictability of a team. That said, working in highly complex and adaptable environments will likely require adaptability in a team’s composition too.
It might be tempting to have new team members conform to the team’s standards. The new team member may not understand how those have emerged or what value there is in complying to them. It may also limit the team member’s pro-activeness, creativity and motivation. Although new team members can learn a lot from a new team, the team should also learn a lot from the fresh insights of a new member. Consider pairing the new team members with each member of the team, at frequent intervals, to stimulate alignment and creativity.
In a Scrum organisation, teams preferably organise themselves amongst themselves. When multiple Scrum Teams are working on the same product, the Development Teams will organise dependencies directly with other Development Teams. When using the Nexus framework, this might be supported by a Nexus Integration Team.
To those of you hoping I would write about what popular practises Scrum Development Teams apply, I have to let you down… for now.
There is much still to cover like ‘emergent architecture’, ‘continuous integration’, ‘pair programming’, ‘estimating’, ‘Kanban’ and ‘quality assurance’ (like ATDD, BDD, dealing with technical debt such as bugs). As they are not core to the Scrum Framework, I will address them later. They are important to cover if you are journeying through the Scrum.org courses. I will address these in different episodes. If you are interested in how a development team may do its inspection, or what could be great Definitions of Done, I shared some of my experience in Episode 3.2 on Inspection.
Closing this episode I would like to recommend The Culture Code by Daniel Coyle. This book shares some great insights from some of the worlds most highly successful teams.
Continue reading in the next episode:
In this episode I tried to put into my own words, based on my own experience, what the Scrum Guide explains regarding the Development Team. This said, I am still struggling with effectively enabling Development Teams to work as self-organising and cross-functional teams the way Scrum intends. So please help your fellow Scrum practitioners out by sharing your techniques in dealing with the above. Please correct me if I have misstepped. Just drop them in the comments below, highlight the statements you found to be helpful and /or share them. Oh right, and don’t forget to clap! 👏 it truly means a lot to me if you do.