AWS Summit Berlin 2018

Last week I visited AWS Summit Berlin 2018 and I really enjoyed it even though some presentations were very AWS marketing heavy. I guess that is fair given that it is a free event.

awssummit

I learned that this year it was the first time that they scheduled it for two full days. Hence the sessions were a good mix of more high-level presentations and some technical deep-dives. I enjoyed both kinds of presentations.

You also had the opportunity to talk to lots of AWS employees and partners which probably was useful for those coming with very concrete topics. For me, I only took the time to learn what some of those companies are doing which definitely was time well spent as well.

If you asked me my three main takeaways here is what I’d like to call out.

1. Don’t start with solutions, start with problems that your customers are having.

This reads so obviously and still, often we are not working like that. Instead of first deeply understanding the need of the customer and the problem that we’d like to solve we are suggesting a premature solution and later are surprised by the fact that we are not meeting „customer expectations“ or rather haven’t solved any real problem or have solved it in a way that doesn’t work for the customer.

To resolve this you can use different methodologies. Design Thinking is one of them, Working Backwards is how AWS fills this concept with life.

It was also pointed out that this process needs to become part of an organizational flow in which you start with Design Thinking, you then work on solving the problem with Agile Teams and operate those solutions with DevOps in mind.

2. Generalists vs. Specialists 

In a session about Artificial Intelligence and Machine Learning, the presenter made a point about generalists eventually becoming more important than specialists if you are talking about building successful solutions.

Take experts in artificial intelligence for example. There are only a few true experts in this field available globally. However, there is a huge demand for knowledge of AI / ML in the industry. The way AWS reacted on this is to offer three layers of AI / ML related services. First, the very basic level. It offers you the greatest flexibility, but it also requires you to understand the underlying models and math. The second layer gives you access to frameworks. You still need to understand the ML concept, but you can rely on algorithms doing the actual work. The third layer consists of application services which have a specific purpose and are pre-trained by AWS. E.g. voice recognition, image recognition etc.

So in above example, people who are not experts in AI / ML can apply ML to their solution because of the application services that are being offered by others. The specialist is not needed in that case. Who is needed is someone with a brought view on technology who is able to understand problems and find solutions given existing technology.

I still think there always will be the need for specialists, but I found that point of you refreshing and interesting.

The presenter also shared a fitting quote from Robert A. Heinlein:

“A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.”

3. Learn

This one is more personal for me. Sometimes it is easy to become complacent. You know what you know and you are good at what you are doing. But what are you really doing? You’re are slowly killing your future. It is important to continue learning and stay curious. Why?

  • You open yourself up for new opportunities
  • You find better ways
  • Shed light on blind spots
  • Keep up with technology (vs. being left behind)
  • Fuel your personal growth
  • It is simply more interesting

Learn to Learn and be Curious:

  • Dedicate time for learning and being curious. It needs to become part of your daily routine.
  • Do so consistently
  • Outside of your comfort zone
  • A new language, a new framework,  new activity, a new anything
  • Visit random meetings / conferences / meetups
  • Increase entropy and collisions
  • Inspiration and new perspectives

Have you visited an AWS Summit in your country? What were your main takeaways?

Advertisements

Devops Tools

DevOps has many levels of complexity. The cultural shift and the organizational structure are the hardest ones in my opinion.

Another one is simply the wealth of tools in that space. I really like the page that XebiaLabs put together. They formatted it like the periodic table of elements which helps you to select tools for a certain domain, e.g. repository management.

devopstools

Unfortunately the page is not quite complete, nevertheless, it is a good starting point.

The Problem With Quick and Dirty

The last couple of weeks have been pretty busy. Privately our little daughter is rightfully consuming a lot of time and also we have been in the final phase of planning our big garden project which now will commence in May. For work, I’ve been traveling a fair bit being in the US now the second time in a month and on top of that was in Prague last week. Besides that, we are entering a time of change, which is good, but also intense.

I want to keep my schedule with posting something every Monday 6pm and really today I only will manage it with a cheat. I definitely missed German time 6pm, but I can still make Seattle time 6pm!

Recently on Twitter, I found this quote:

“The problem with quick and dirty is that the dirty remains long after the quick has been forgotten” – Steve C. McConnell

Steve McConnell is the author of Code Complete which you can order on Amazon (affiliate link)

It is a book full of wisdom for programmers and one of those books that I like to have a hard copy of. Its content remains true for a very long time.

Back to the quote: „Quick and Dirty“ is so appealing when you are acting under constant time pressure. Everybody seems to be happy at first. The developer can move on to the next task and the product owner gets the feature, extension, bug fix or what-so-ever quickly.

The problem is that just after delivering the item the next urgent thing is lurking around the corner and the quick win is soon to be forgotten. What remains, however, is the hack. Worst case it will cause a bug in future because of unconsidered use-cases or untested side-effects. Best case it will make your system less maintainable, less performant, less readable, less extensible, … the list could go on.

The collection of hacks that your system is built on over time when you have delivered too often „quick and dirty“ is going to make it harder and harder to maintain and extend the application. It will become more error-prone and you will deliver slower and slower until you eventually will have to go into a painful and resource consuming rewrite of large parts of your application.

Don’t be tempted by quick and dirty. Try to do things right and you will be faster in the long run. Constant investment into the architectural health of your system will pay off.

The MVP approach sucks – sometimes.

Defining an MVP is a great approach to deliver value quickly to your customers and also to get good feedback on functionality very early in the development process so that you can base future decisions on that feedback.

Let’s start with a definition. What is an MVP? Here is the definition from Wikipedia:

A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.

And another definition from the book The Lean Startup:

Version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

To me the two key goals of a Minimum Viable Product are

  • be quick to market
  • get early feedback for future iterations

So why does the title of this blog say that MVPs suck sometimes? It’s when we deploy an MVP into production and then never listen to the feedback and never invest in future iterations.

In that case, the only value we will get out of an MVP is being quick to market. And of course that in itself is a value but you are risking to get unhappy customers because sure enough by delivering an MVP you are setting the expectation that feedback will be evaluated and eventually the piece of functionality will evolve into something fully featured.

Many of you probably know this picture comparing an MVP to a classic iterative approach.

mvp

I fully agree with the second row of the picture, but the important piece here is that the product evolves over time from a skateboard (something minimal to get from A to B) to a car (something pretty efficient and comfortable to get from A to B)! If you keep the skateboard for years without improving it you will end up with unhappy and frustrated customers.

Also, …. the agile teams who worked on the MVP will be disappointed that they cannot iterate on the product. It feels like an unfinished job. You might think that this is unimportant detail, but the contrary is true. It directly impacts the motivation and the engagement of the team. More about that topic in my post about what employees really motivates.

Of course, sometimes it is just fine to stop after the MVP is delivered.

  • You might decide that the skateboard is just fine and customers are actually happy with the MVP for long-term… in that case: awesome; job done!
  • You might learn that no customer actually wanted the skateboard and you retire it. Stop selling it. That is also a perfectly legit approach.

Getting feedback from the market and not iterating on it because you are already asking teams to work on the next top priority is what will hunt you down at some point future and has a negative impact on team morale.

So what’s the alternative? I think there are two, but really there is only one. And also…  maybe there are some that did not come to my mind …

  1. Stop defining MVPs, deliver a fully featured product (how again do I know  what fully featured means??!)
  2. Start focusing and embrace the MVP approach.

In my opinion, only #2 is the only long-term sustainable way to go. Everybody involved in the process of delivering software to customers should push for this. It is not easy because there are always so many important things that one could work on, but it will pay off over time because it allows for focus and the customer feels heard.

I’d love to hear your opinion on the topic!

Deutsch oder English als Blog-Sprache?

See for English language below….

Deutsch

Dem wiederkehrenden Besucher wird auffallen, dass manche Artikel in Englisch, andere wiederum auf Deutsch veröffentlicht werden.

Warum?

Der Hauptgrund ist meine eigene Faulheit die Optimierung meiner eigenen Zeit. Ich schreibe in der Sprache, in der ich am besten über das gegebene Thema schreiben kann. Für Themen die sich auf irgendeine Weise auf meinen Beruf beziehen, fällt es mir leichter auf Englisch zu schreiben, da das die Sprache ich die ich beruflich zu 95% einsetze. Artikel über Hobbies fallen mir leichter auf Deutsch. Darüber hinaus ergibt es auch wenig Sinn über z.B. MyPoster.de auf Englisch zu schreiben.

Wird sich das unter Umständen ändern? Vielleicht… „Nothing is as constant as change“. Das aktuelle Ziel ist zunächst einmal jede Woche einen Artikel zu veröffentlichen und ein paar Besucher zu bekommen.

Vielen Dank fürs Lesen!

English

The returning visitor might have noticed that some articles are published in English and some are published in German.

Why?

The main reason is my laziness my attempt to optimize my own time. I always write in the language in which I can express myself the best on a given topic. On topics that are somehow related to my job I’ll always use English as that is the language that I use 95% in my day to day job. Posts about my hobbies are easier for me to write in German. Furthermore it doesn’t make a lot of sense to write an article about MyPoster.de in English.

Will this change eventually? Maybe… „Nothing is as constant as change“. The current goal is to publish a post per week and to get actually some visitors.

So thanks for reading this!

 

What really motivates us

My Development teams at Concur are currently all working on complex, high profile projects. Things are challenging and stressful.

In times like that it is important to remember what really drives motivation of a highly skilled workforce. As probably everybody knows by now: it is not money. Money is important and we need to pay people fairly, but it is not what ultimately motivates them long term. As I said, not a new thought, but in times like these, it is easy to forget.

What really motivates us can be distilled in three words:

  • autonomy: have the autonomy to do solve problems the way you think is best. We hire smart people, why not let them take the decisions they need to take in order to do a good job?
  • mastery: enable your people to become really really good at something.
  • purpose: answer the question why we are doing what we are doing.

Read all about it in „Drive“ by Daniel H. Pink. Or just watch this video:

The right DevOps Structure

Once your company has decided to adopt DevOps, that’s when the hard work actually begins. Typically Development and IT-Operations are separated organizationally. How do you bring the two together? What’s the best approach for your company and how do the different approaches compare to each other?

All those questions are non-trivial to figure out. For me, the work of Matthew Skelton and Manuel Pais really helped me to bring order to the various patterns and anti-patterns that exist.

I highly recommend you take a look at their work:

devopswebsite

http://web.devopstopologies.com/