What we can learn from Blossom IO

A conversation with Thomas Schranz

A. Sharif
7 min readJul 15, 2015

I have been a huge fan of Thomas Schranz’s writing for a long time now. Just check his Medium profile or the Blossom blog to understand why.

The most fascinating thing about his posts is the fact, that you will keep finding new information hidden in between, even after multiple reads.

I’m very heavy into Agile Product Development and Management. So it was about time to meet for a coffee and discuss, in further detail, how his ideas on Product Management, Agile Software Development and Engineering Culture can be applied in a non start up environment.

To be clear, I wanted to find out what agencies and software companies with external stakeholders can learn from Blossom IO. Especially how they can approach Agile Product Management in a more efficient manner.

The following is a summary of the ideas and topics we discussed.

ScrumMasters, Daily StandUp and Communication

I’m not convinced that ScrumMasters can be trained “by the book” with the help of a 2 or 3 day workshops and released into realities that need expertise, a lot of experience and people skills.

Especially this “by the book” mentality neglects the realities inside teams and companies. Thomas believes that we need more facilitators less Scrum Masters. I agree. Also read his When SCRUM Stand-Up Meetings feel like an Interrogation … blog post if you haven’t already.

According to Thomas we can split the experiences with Daily Stand-Ups into three separate groups. The first group can live with Scrum, but actually feel there’s something wrong. The second groups feelings can be summed up to the lines of “Damn, the Standup is the first thing in the morning. My motivation is on a low already”. One third seem to either accept or like it.

We will not go into detail on how to organize an efficient Daily. But we can agree on the fact, that a experienced facilitator might be able to turn this meeting into something positive and beneficial to the team.

A facilitator can be helpful in improving the communication between team members and identifying possible blockers, even spotting team members that are hindering the rest early on.

Facilitation can’t be taught in a one day workshop and one can’t learn it via reading books. This takes a lot of training, people skills and empathy. We need real facilitators less certifications and hit and run consulting.

Blossom have found their own way of dealing with the Daily Standup meeting format. Read 3 Tips for Effective Stand-Up Meetings. It took them sometime to find an approach that fits their culture and caters to the team.

We’ve experimented a lot with the common format, added our own tea ritual, changed the strict question format to a conversation about the board and we actually don’t stand all the time (pssst!).

Thomas Schranz, 3 Tips for Effective Stand-Up Meetings

There are some valuable resources out there, that might help with making things more efficient. Martin Fowler - “ It’s Not Just Standing Up: Patterns for Daily Standup Meetings” for example. Walking the board is another possible alternative. All solutions have the intent to take away that “spotlight feeling” according to Thomas.

Tools, Artifacts and Communication

One thing we should be very careful of according to Thomas, is shifting the focus away form communication to artifacts. A lot of agile tools market themselves as “This tools replaces meetings”. We should be more cautious with slogans like this. The best approach is a cyclic one, where artifacts and communication keep revolving around one another.

Most Product Managers like to talk about things while Developers tend to avoid being interrupted, pulled from the current tasks they are working on. This is especially annoying when these interruptions are perceived as shifting work they should be doing on to developers. The later hate to be treated like a resource. This is where product management tools make sense. They help to avoid unnecessary communication, that can be easily displayed via a tool like Blossom IO for example.

XP

What about extreme Programming? Can extreme programming help us tackle problems that Scrum might not be able to handle efficiently?

Thomas believes that XP is an excellent format to grow people inside a team. But it is often perceived as “Twice as expensive” from a customer perspective.

The advantages that come with XP can be summed up as:

  • More people with more knowledge and expertise
  • Stronger alignment and bonding within the team
  • Productivity and knowledge transfer
  • More alertness regarding blockers and tackling them

The problem from Thomas’s point of view is that there are limits to XP and just like with Scrum, over-exaggerating things will lead to negative side effects.

Combining XP practices with other methodologies can lead to very interesting results. Just prevent taking a dogmatic stand on XP.

Optimizing the External API

We need to optimize the communication with external stakeholders. In the case of an Agency or Software Service Company this will be the business customer.

One excellent advice from Thomas is to focus on the external API. With external we mean the part of an agile framework that is public, think user stories, sprint burn down and backlog.

We communicate on a story level with the customer. This might be too fine grained according to Thomas. What if we could communicate on a scale that is even bigger than epics? Think in terms of themes.

Instead of discussing user stories and along the way having to maintain the backlog, we only define themes.

This has many advantages when it comes to backlog grooming and prioritization. We are discussing “larger than epic” features with the customer but still communicating on the user story level within a team. Which means user stories are implementation details, private methods, not exposed via the API.

It makes mapping user stories to those themes easy. Everything that fits into one of the agreed themes can be prioritized, everything else is moved back down the backlog as it’s not part of the agreed scope.

Instead of only focusing on optimizing the internal workings and shifting focus on to the external stakeholders we can gain benefits that will have positive effects on the overall product.

Also read What Product Managers can learn from Jiro Ono incase you haven’t. Thomas shows how Jiro Ono optimizes the inner and outer workings.

Caring more than others is a real competitive advantage. Ingrained in the company culture and incredibly hard to copy.

Thomas Schranz, What Product Managers can learn from Jiro Ono

Proxy Product Managers

The aforementioned approach of mainly focusing on communicating on a theme level with the customer might enable the so called proxy manager to gain more control over the product again. With the proxy manager we mean, the product owner who only writes user stories according to customer needs or even gets the user stories pre written by the customer’s product owner and only passes them on to the team.

Market to the right Crowd

How can we get the right crowd to interact with our service, company or agency?

The customer can select from a large number of options and decide and command the terms and outlines of the agreement. Talk to any Designer and he or she will have a story or two to tell about a demanding customer trying to gain full control over the creative process.

The idea to reject customers that don’t fit a companies way of thinking and solving problems sounds intriguing, only that you’re dealing with financial realities in a real world setting. Who hasn’t told himself “Only this last client.” It never ends with this last client.

Thomas advises agencies and software companies to be very clear to whom they market to. If you have a list of big name clients on your website, then most probably you will appeal to other large clients or clients with a similar mindset.

This means that to bring yourself into a position where you can decide with whom you want to and with whom you choose not to work with, you have to start sending the right signals to the right clients right from jump.

This takes a lot of work and thinking, starting with answering Why (see Simon Sinek). Most companies can’t define the Why, their culture and work flow being dictated by external circumstances. This is especially hard for companies that have been in business for a very long time.

The process involves a lot of rethinking and self reflection.

For inspiration read on Jiro Ono, view Simon Sinek talking about “Why” and see Paul Rand present the Next Logo.

Summary

  • Be pragmatic with any tool or methodology
  • Find a balance between Artifacts and Communication
  • Facilitators over ScrumMasters
  • Define which customers you want to appeal to and market it properly
  • Try to communicate with customers on a theme not a user story level
  • Use Agile tools wisely, don’t eliminate direct Communication

Incase you need more insights on Blossom IO or more detailed information on how they approach Product Management check the following links.

Thomas Schranz Medium profile

Blossom blog

Blossom IO

--

--

A. Sharif

Focusing on quality. Software Development. Product Management.