Skip to Content

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 : 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” ( 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,


You must be Logged on to comment or reply to a post.
  • Hi Paul,

    It would appeart that the ability to Alert Moderator for blog comments should now receive a bit higher priority as well as the ability for Moderators to intervene.  Thank-you very much for bringing this to our attention!
    Cheers, Mike (Moderator)
    SAP Technology RIG

    • Hey Christopher, thanks for sharing that article. I think that guy is confusing the actual state of scrum implementations with its desired ideal state. (I've read that article once before.)

      Most of his complaints are reasonable, as the agility movement in total has not yet reached a level of maturity in most implemenation cases. (did you know the D-A-CH sister to the scrumalliance in the US has just been founded this year. Pretty fresh information from the scrum user group karlsruhe two days ago ? )
      Check out the graph on this page : most teams stay at level one. Ultimately the agility movement will be spread out and saturate the agile teams to an extend that they all can reach the fourth level. (You can also take these four levels to evaluate with which kind of level-teams the author of “terrible” probably had the most experiences.)

      I think his complaints about user stories are falsy, as a good refinment makes good user stories, and to implement big stories we can use epics.. ain’t it so?

      What I do like are his complaints around that the high end developer is not getting the appreciation he deserves any more. We can’t make him a PA anymore, we can’t give him a fancy title. Now for earning money this shouldn’t be an issue due to the balancing power of economic market.
      BUT I know from developers telling me about it, that they miss the appreciation, and also the status that comes with it.
      Problem I see here is that the future of teams using agility is a future of team learning. As the dam that stowed agilities potential was just teared down (see the emergence of scaling approaches), we have simply not reached a level were we can substantially deal with that issue. 

      As soon as the high end devs understand that they never have to develop again, but can scale their development ability onto younger devs, a new role system will emerge (as social roles already exist in Scrum, they are just not made transparent) that can satisfy the need for appreciation. It will also allow a complete new way of cross-team collaboration. (I’m logically concluding these things for myself, wouldn’t bet my life on it or write a blogpost about it… yet)
      I put these . there because my format keeps vanishing after saving ..