Estimating the shape of agile teams

How Scrum may grow

From management perspective it is fairly easy to scale Scrum alongside the pure “scale” dimension, of growing the number of teams, or the “distribution” dimension, number of different geographic locations.
Just put up new teams, either in a department or distributed, call them Scrum teams and you are good to go.

Picture from scrumalliance.org : Scrum@Scale

It is the “saturation” dimension, the degree agile principles have pervaded an organization that is the hardest to achieve.
To saturate Scrum teams with principles of agility it needs 1) luck, that you have a team of highly talented professionals OR 2) a long breath in upskilling your juniors and embedding the appropriate work processes, which have first been summed up under the term Extreme Programming.
Namely: Test-Driven-Development, Pair Programming, Close Customer Collaboration, Fast Feedback Loops, Continuous Integration, and lots of more best practices for agile software development.

For new Scrum Teams it is often hard to figure out where they stand, what their team identity suggests for working principles and practices, and thus how to actually get better. It would need a 100% qualified Scrum Master to even out a lack of understanding of agile software development in the team, but what if the Scrum Master is new to his role, too?
What if the Scrum Master doesn’t know where to begin? What if the Scrum Master is indeed an high-achiever but doesn’t know what to do? There is no scrumming by the book as every reality of implementing methods for higher project performance is different: Projects need to grow organic. (Organic means that we are talking about living systems, and such don’t grow linear, but they evolve new sub-systems in a leap; organically grown systems are not just a matter of healthy food (Bio trademark sends its greetings), but all of them encapsulate the capability of emerging new solutions when the environment changes.)

Thus the Scrum Master may be unsure what to do and that their job actually is to make the Scrum Team better and better by using Scrum Retrospectives. The value of retrospectives lies within opening up the Development Teams potential to emerge solutions to new problems (impediments).

At an organization they might not do retrospectives as they are meant to be, and go with simple methods to keep the ritual going (e.g. a starfish retrospective; a good fit for most retrospectives in general, but it is not as precise as other techniques. It ultimately depends on the Scrum Master whether a meaningful impediment is been made transparent and acted upon.).
But there might be Scrum Master not knowing what an impediment can be. And since social solutions and social engineering are a no-mans-land for most Scrum Masters with IT background, I suspect the number of SMs not being able to identify social impediments to be quite relevant. E.g. an upcoming junior developer is very knowledgeable about a topic, but is not able to teach about it. Or another junior has great potential in leading and managing, but he is not being supported by his supervisors in growing into his potential.

A framework for agile implementation for de-located teams and un-experienced scrum masters

I made up my mind how to support a lack of knowledge about agility in Scrum teams. And I think that it is possible to offer an exoskeleton of Scrum Artifacts to reach out to for the Scrum Master. Additionally a basic guideline how to supervise these can be provided. This can help a part time scrum master to not lose track of a specific team’s performance improvement, but also give an unsure-what-to-do Scrum Master necessary stability for his own productivity.

The following is a first draft for an Agile Artifacts Standardization Process (AASP I suppose). These artifacts can be quantified and for some cases templates for qualitative comparison can be given.

I know that this topic has a shared interest all over the world of business and can be found in the agile scene under the term “agile fluency” (http://www.agilefluency.org/model.php)and of course in any value chain modelling we would find dozens of different perspectives on this.

So I am not reinventing the wheel here. But for those who want to spend some thought on on this topic, it might be a fruitful list nevertheless:

1. Impediment backlog: Measuring flow from left to right
2. Jira Backlog: measuring number of tickets in relation to time
3. Jira Sprint Backlog: measuring how many tickets flow in during the sprint, how many don’t get closed (the quantity is irrelevant, the sprint goal needs to be qualified as implicit trust bond between PO and Developers)
4. Dashboard: burn down chart, activity streams: measuring/overseeing comments/ticket creation
5. Ticket templates, stories, tasks(several), defects (one project), ideas and change requests (multiple projects): adaptation must be well enough to project specific use cases, how many template exist, which are used, adding components automatically for measurement
6. Team Agreement: across teams need to have same quality.
7. For de-located teams Jira tickets get exponential more important (mainly because they can transport implicit information via ticket-linking, but also for the means of a consistent/non-disruptive workflow)
   1. Thus: We need to change the way of ticket creation to model the spontaneous way humans “get” to their ideas and to the way humans work collaboratively.
8. Ticket creation: changing the model from pushing tickets into the system, to getting the ticket content pulled from the knowledgeable and responsible people’s brain.
   1. Jira ticket templates for any use case. Don’t waste time thinking about how to create tickets: “don’t talk about tickets set them up”
   2. Jira shared idea boards and change request boards, which gets refined collaboratively.
9. Workflows for supporting system (jira, wiki, git): can be pictured and compared (value chain = workflow + informationflow)
   Same workflows deliver specific results in the form of new tickets, which activate the need for filling it correspondingly. (see: Ticket creation in 7.)

—

Thank you for your time reading my blogpost. If you find the idea of such a supportive framework interesting for kickstarting Scrum Teams don’t hesitate to ask a question or contact me directly via email etc.

Best Regards,
Paul