Great Product Team, Successful Product (closing keynote day 1)

Marty gave an eye opening talk about what he considers key ingredients of great product teams. He summarizes them very well in this blog post “product success”, so I will only add some additional notes below.

His overall statement is that while many companies follow agile principles during the development phase, the rest of their process of building software products is still more waterfall than anything else. (I believe elsewhere I also heard Water-Scrum-Fall as a term.)

Marty emphasized the importance of connecting the team directly with the customer. Only then can the whole team help to contribute to the solution, instead of just acting like an internal agency.

To keep the team on track towards their shared goal, one needs a clear vision (inspiring) and strategy (intentional). Having this can also be a great hiring tool for a company!

Instead of pretending we know what we are building, we should focus on quick discovery, and risk assessment. Risks may come in different forms but for example:

Psychological Aspects of Estimating

Joseph delivered a rather uncommon talk for a technology conference but that is probably what made it so great. He focused on how we typically do estimations in software development teams, and which biases we have when we do this.

Even more impactful for me however was the following quote:

If we find that our language (in software) is reducing our ability to communicate with our customers, then that is the problem we should solve. (Joseph Pelrine)

This resonated a lot with me. Truly great product teams need a healthy amount of communication with customers and other business stakeholders. Hence finding a common language between both worlds is very important. Last but not least as the language we speak influences the way we think.

Embracing uncertainty: Why you should and why you won’t (Keynote)

Dan is a very engaging speaker. I attended his workshop as well, and many of his ideas center around this quote, which takes quite a bit of unpacking:

Sustainably reduce lead time to business impact. (Dan North)

In his talk he focused on how uncomfortable we are with uncertainty, and how this need for creating certainty may lead to dysfunctions in our software development processes.

Most noteworthy for me, he mentioned that measuring “proxy metrics” can negatively impact the behavior of your team. Make sure you know why you are measuring what, and what you are doing with this number. (e.g. velocity is a pure capacity planning metric but has nothing to do with performance)

Deploying and Scaling Microservices

Sam gave an overview talk, starting from artifacts and how you might build them and ending with deployment platforms for containers. It suspect that for people will experience in container deployment, this talk didn’t have much new. However as an overview talk into the topic I found it helpful.

He reviewed different techniques of artifact creation, along these 4 guiding principles:

Easy to create

Easy to deploy

Abstracts out the tech stack

Good for dev, good for ops

According to Sam the vendor lock-in of the deployment platforms is not that big of a problem, as the decision of where you run mesos or kubernetes is yours. (amazon ECS, Windows Azure, google cloud, …).

Architecture without architects

After their talk I didn’t necessarily have an answer to how to achieve “architecture without architects” but they certainly provided interesting stimuli. Martin and Erik view the role of an architect as somebody that improves other developers, and not somebody that draws diagrams.

Can we imagine a system where adding new features becomes easier, the older the system is? If that is the case, then we have to assume that some architectural thinking was applied.

Build upon each others work, with local rules and an evolutionary architecture (Martin Fowler & Erik Dörnenburg)

One more instructive comment for me was that each microservice should contain part of UI composition and API gateway, as the team that builds this service has the required domain expertise. Interesting thought, now I am just wondering how to do this

Toward Better Design and Code - A Case Study with Pelikan Cache

Yao talked about a case study at Twitter but while doing that also explored general principles of writing and re-writing software. Her overall approach is that software should be modified by evolution, not revolution.

She finds it dangerous to aim for a better solution. According to her we cannot always afford ‘better’. Do good first, then make it better.

Yao also mentioned that their team would not have been able to design pelikan, without first using all the other technologies that pelikan is abstracting from. So in short, you cannot shortcut the learnings that need to be made. Damn!