On 2nd February, we were guests at Spreadshirt (http://sprd.net/). It was standard Open Space format.

Pitching

I was keen on showing my User Story Generator to the public and getting feedback on it. So, I started the pitching.

After some hesitations, we got our agenda and even a small backlog.

Sveto offered the topic “networking effects” that was so interesting from my perspective, that I stepped back with my already accepted USG-topic to open space for it.

 

Unfortunately, my Windows phone suffered on an unwanted feature regarding the camera. Therefore, I have no personal photo-documentation of that evening at hand.

Fortunately, others shared their photos via meetup.com.

Round 1

“my session”: Quality of working software

I participated at the “Quality talk”. That was great. We got behind the scenes and really inside the PO’s bet (do I release a feature, that gains revenue early or should I wait until it is all “ready”?).

We shared our experiences on testing, acceptance criteria and measurement methods to determine quality.

Amongst others we found helpful NPS (Net promoter score), A/B Testing and finally SUS (System Usabilty Score)

 

Others

There were two other groups. One talked about documentation,

the other about conflicts in (Team)communication – how they arise and how they can be solved.

Break

We got wonderful wrap rolls sponsored by our host (http://sprd.net).

There was a wheel of fortune You could turn to win funny shirts or play with a game console.

https://a248.e.akamai.net/secure.meetupstatic.com/photos/event/e/8/0/b/600_458519403.jpeg

 

I made a private session about USG – what is the story behind, how can You use it …

Round 2

At 21:00h, Sveto had to leave (they launched something in that night). I got a small briefing, so I could take over and co-hosted the session.

“my session”: network effects

Fortunately, Steffen of lecturio joined the session and we got a little more “behind the scenes” about what initiated the topic.

Issue: You cannot do it all Yourself.

Strategic question: make or buy?

Contra-intuitive: paying for what You are able to do Yourself.

Sometimes, there are situations, where You take something from “outside”, integrate it and create a powerful Tool/App from it. Networking effect then is, that the creator of what You took, has not the use case You have. But s/he has done a lot of the way to the point where You both cross. By joining Your activities, You get both what You need and You both will get able to share experience and development energy (resources with partly aligned aims).

Now, there is the contra-intuitive thing in that. You might want to experience it all Yourself. You might want to do all the failure on Your own. Or You (or Your company) just believe You have to do so.

Option: step back one step, get rid of Your (company’s) ego and pay somebody who had already done this.
By paying to, You can get involved, pronounce Your requirements, make demands by that and participate in directions on the product.

That is not stepping on the shoulder of giants. It is not being an unheard consumer of a foreign provided service.
It is about getting involved and sharing Your resources.
It is partnership, hopefully on eye-level.

One major and widely seen example of this is the buyout of here by the German Premium Automotive consortium build of Audi, BMW and Daimler.

There are trillions of other opportunities. Use them …

Others

There was another session evaluating and demonstrating sketchnoting amongst others with the bikablo technique.

The second one was about team development only by retrospectives.
As a Scrum Master/Coach You are not the “Scrum Mom” washing other’s dirty clothes …

Conclusion/s

I was under the impression of the networking effect talk as the wrap up took place.

Suddenly, there came an idea to my mind. I always wondered, why so many developers are so reluctant to document and so unwilling to test.

I find this a very bad behavior for years, but now I see a possible reason in that.
In my view, it is a kind of lacking maturity.
People that behave in this way just have no idea what it should be good for.

If it is broken – they will fix it. If they have no knowledge, they will ask or try out. Everything comes to “fine” within minutes and hours and afterwards they forget about, because there is no pain experienced.

They take more or less well documented pieces of code from sources like stackoverflow. They use products that are intended to be published (i.e. apache) and use it for systems that are consumed as they are (www.myapp.net).

They were just not confronted with inherited, undocumented code, yet. They never talk to users of “their” services. They never had to support foreign code and systems without personal experienced knowledge or documentation. And they never experienced the pressure of keeping these things running on an everyday basis.

Thank You!

Thank You who were there for participating, sharing a little part of Your lifetime, Your experiences, Your knowledge and facilitating by all this, the described insight about testing and documentation and lots more on the way to here.