Reflections on Scrum implementation and practice

Tags: #<Tag:0x00007f9f0ba74750> #<Tag:0x00007f9f0ba74598> #<Tag:0x00007f9f0ba743b8>

(Josef Kreitmayer) #1

I think it is worthwhile to start a conversation about our emerging scrum / agile technical development practice, that I find very interesting, inspiring and simply great. Starting the first sprint at KuBIZ before SOLIKON gave me a lot of energy and clarity.

In searching “waterfall” (yes, I am the guy drawind GANTT-Charts to give funders a from their view required perspective of what is achieved when) and “agile” I found that inspiring and well crafted / visualizing article about conventional waterfall project development and agile development. It provides a view of not being either:or, vice versa, but a good combination of approaches for guiding the various streams of the technical, non-technical, inside-outside interfaces and approaches.

mailman lists for SSEDAS-Topic-Groups
(Gualter Barbas Baptista) #2

Product owner (and in our non-hierarchical case all the team) can of course add user stories to the backlog at any time, just not prioritize them. We should also meet before the sprint planning meeting for grooming, but this is more about cleaning up/refining user stories than changing their priority.

We can probably get them to shorter cycles, but please understand that shorter cycles may imply more frequent changes and less time to really get into the tasks needed to do on the sprint. But lets discuss this after the retrospective and when deciding the next sprint.

Yes! But we also said we are piloting the scrum, testing it with a stable team. One story of our team might be to find people to create another team. But following a Portuguese say, “don’t put the car in front of the oxes”. Lets finish our test, reflect on it and decide on next steps to bring the larger community of TransforMap (if we find it useful) into new, operational and agile teams.

(Josef Kreitmayer) #3

ah @gandhiano then I simply misunderstood the task of grooming.
I found a good description for grooming in scrum here

My only concern is, that usually a scrum team (coming from IT) is dedicated to IT-development, and not to overall organizational development.

I already tried to share my concern in Berlin, that we currently centralize all structure and structural work to “the team”. Just to understand, before we centralized to “the scrum team”, all of us contributed on a free way, and had interactions on several topics with several people, that are now not in “the team”, but contribute on those topics, that would refer to other circles, if they were well implemented.

As we can just handle a certain ammount of complexity within one meeting / circle, but can interact as individuals organized in several circles, I would strongly argue for developing several working teams (as we decided in potsdam), wether they use scrum or not.

(Josef Kreitmayer) #4

the following is the collection of Backlog-Items, that we decided on taking out of the backlog, but want to store them elsewhere, as they are still interesting, but to general or epic, as some of them depict the whole story of TransforMap:

  • TransforMap engages user communities in shaping its semantic ontologies. overall TransforMap epic (the absolute epic) 42
  • create &curate online process to align communities in their mapping efforts. to big, not specific enough, actually, what TransforMap is about. Might need splitting into smaller stories.
  • As a user I can visualise the geographic distribution of the alternative economy in a specific area. too broad, general idea of TransforMap
  • Implement a secure and privacy-oriented federated tempospation mapping community and infrastructure. out for now, borad scope for possibly 2017
  • As a community, TransforMap allows me to model my information into interoperable data formats related to others. rather an acceptance critera for #35 and #137.
  • Make a proposal for boundaries rules. sent to governance.
  • Clear description of the governance structure & processes of TransforMap to engage as community user. sent to governance.

(Josef Kreitmayer) #5


here 2 interesting articles, how we can improve on the overview and readability of our user stories.

The title of a user story should be a title and can be quite short. It does not need to start with “…the user …”, but should help the team to be able to identify it again.