Learning together as a team

This is a cross-post from Evolve Agility blog post.

A Systems modeling technique to visualize and act on deeply entrenched systemic issues.

Everyone carries a model, fuzzy as it may be, a map of sorts to navigate reality as perceived. As team members we have expectations from each other. This internal picture of our expectations, and reasons, and emotions, and all the mess that is being human is our mental model. The differences between what actually happens and what we expected it to be, reinforces our mental models or alters it. Learners are able to update their mental models more often, and thus adjust their actions and expectations with ever emerging reality.

I find that curiosity is the doorway to learning. Accumulation of knowledge on the other hand is founded on the mistaken belief that knowing about a thing is the same as knowing the thing.

By learning, I do not mean accumulation of knowledge or a collection of jargon to impress your colleagues. By learning, I mean understanding that enables you to take actionable steps in a very real practical sense.

Overcoming the false dichotomy of Specialization vs Generalization with Scrum

Virtually every Team in their first Sprint is confronted with the problem of single-specialization causing work imbalance. What happens? The Product Owner orders the Product Backlog to maximize value. But when the team members are specialized in a single dimension - such as QA, Java development, front-end development - some team members regularly will find themselves with no work related to their area of specialization. Single-specialization inevitably causes work imbalance.

Number of backlogs and multi-learning 2) functional team and component team

(Originally published by Lv Yi on June 12, 2019)

In this article, we shall look at the structure of functional and component teams, explore the dynamics around their backlogs, analyze its impact on agility, and find the lever to optimize for agility.

org structure impact on agility

A functional team is responsible for functional work such as analysis, design, implementation, and testing. Component team is responsible for the implementation of various technical components, such as component A, B and C. Each team has its own work and priority, thus, its own backlog. For overall value delivery, it means that the required work is in multiple backlogs which are dependent on one another.

Contact Support