“But our team needs something special”

It all started with a workshop on a new internal platform I helped to build. Besides the platform team, we had some seasoned engineers from the (stream-aligned) development teams present. This helped to create alignment, but can be dragging. I anticipated a longer discussion when one of the architects from the development teams noted:

“But our service is special. We will need a special configuration, which none of the other teams will request. With this new platform, I know I will need to wait for 6 months and have endless meetings.”

This is obviously bad. A decline in productivity was not one of our goals for the new platform. Fortunately, the engineer was also very hands-on and wanted to solve the problem. As we were in the means of building the first version of the new platform, we agreed to join forces.

At the same time, I had this uncomfortable feeling that something was not right. Aren't we supposed to build the platform? Shouldn’t this great engineer focus on building his service? This suspicion kept lingering in my mind until I had read about the different interaction modes in Team Topologies. This helped me to disambiguate the different roles and make the interactions explicit.

Product Thinking For Internal Platforms

Internal developer / cloud platforms are a great mechanism to set guard rails, reduce cognitive load on (stream-aligned) development teams and therefore improve the overall productivity. But a common risk is that we build another internal system that doesn’t meet the requirements, isn’t well maintained and slow to adapt. A common approach is emphasizing on a product mindset (e.g. CNCF Whitepaper, Thoughtworks) to ensure we keep users and their requirements in mind and that we prevent feature creep by building the Thinnest Viable Platform.

Collaboration As Competitive Advantage

Something that I miss with these approaches is the unique setting we are in when we are building an internal platform. We don’t have a customer relationship. We have a team relationship between the development and the platform team. If the platform is just another service: Why not hire someone external? Why not buy something off the shelf? Using off the shelf components might be a good idea for certain capabilities, but the reason we are building an internal platform is that it’s doing something unique. Something that our stream-aligned teams can’t just buy. As an organization, we should use this special setting to our advantage. We should enable collaboration between teams and allow new ideas to flourish in this safe internal environment. But to ensure this collaboration is productive, we need to manage it.

Self-Service Adaptation

Just like the architect from my example, good engineers know how to help them-selves. They get around roadblocks and automate toil away. However, they need an environment that allows them to do it. So in the case of our internal platform, we have to ask ourselves:

How fast can good engineers adapt the platform to their needs?

There are several ways to approach this, but if you have good engineering practices likes CI/CD for your platform development, you can treat adaptations from other teams just as normal development. A seasoned engineer should just take your platform, fork it, adapt it and deploy their version of it.

This is not a hard task. Especially in our unique internal setting where we can be open and descriptive on how to run and operate the platform. Frameworks like Crossplane support this out of the box.

Explicit Interactions

Once these forks (or other adaptations) exist, we need to evaluate if we want to get these changes back into the platform. We need to look for adoption signals, and the development team should do some internal advocacy.

If we see a rising interest, we start evaluating if and how the changes should be merged back into the platform. The development team and the platform team start collaborating closely. It’s important that this collaboration interaction is explicit and time-boxed. The final goal is that the new functionality is completely handed over and Team A can get back to using the service as an offering from the platform.

Summary

Great engineering organizations are leveraging their collective internal knowledge. And great platform teams enable adaptations of their platform. To ensure our development continues to flow, we need to be explicit about interaction modes between teams and keep close collaborations time-boxed.

If you have seen similar issues in your org, please reach out or leave a comment. I’d like to learn more about other approaches. I am happy to share more insights on what I’ve learned so far.

(This was also posted on LinkedIn)

Team Topologies is a fantastic book on how to organize teams in modern technology-driven enterprises. I’ve been reading up on this book for a while and recently had the time to dive deeper. I’ve discovered that many of my experiences and ideas on building and evolving platforms can be mapped or expressed with Team Topologies. So I thought it’s a good time to bring them to paper, which I will start with this post.

Agile, Lean and DevOps Don’t Talk About Team Structures

Throughout my career, I learned and used several great methodologies that helped software engineering teams. Agile, which emphasizes on iterative approaches, small teams and feedback cycles. Lean, which introduced a holistic value-stream thinking. And DevOps which popularized automation and collaboration between developer and operation silos. Today, the principles and practices of these methodologies are taken for granted and teams are implementing them left and right.

These methodologies don’t address how to structure teams when you start scaling out software engineering. The SAFE process never felt aligned with Agile principles. The Spotify model was a great addition by introducing basic team structures like cross-functional teams (Squads) and communities of practices (Chapters & Guilds). While I’ve successfully applied an adoption of this model, I always found something missing.

Team Topologies discusses many different interconnected ideas. In this post, I’ll start with a brief introduction of what the book is most famous for: team types and their interactions. In subsequent posts, I’ll dive deeper and introduce other ideas and examples where I’ve seen them work and fail.

Flow, Flow, Flow

The book introduces four team types: Stream-aligned, Enabling, Complicated Subsystem and Platform. And three interaction modes: Collaboration, X-As-A-Service and Facilitating. As we dive deeper into the types, it’s helpful to remember that the book is about “organizing teams for fast flow”. Matthew Skelton the author, recently even started thinking about renaming the “Platform” team type to “Flow Platform”.

Four Team Types

With flow in mind, the goal is to focus on autonomous, decoupled Stream-alignedteams who maintain full ownership of building, fixing and running their application. I’d like to think of a small shop with just one team, which basically creates the whole app. The other team types support these stream-aligned teams in various ways, but all with the same goal: enable the various stream-aligned teams to deliver features for the business. And you wouldn’t introduce new teams if the Stream-aligned teams haven’t signaled any issues.

The first additional team type Team Topologies introduce is the Enabling team, which consists of a set of specialists which have a specific mandate to help the Stream-aligned teams to overcome obstacles. I’d like to think of these as technical consultants which temporarily collaborate with the team on a specific topic like: test automation or improving the build pipelines. The Stream-aligned team stays autonomous and is now enabled to better build software. In some later posts, I’ll discuss different enabling teams which we have crated in the past.

The next team type should be the Platform team, which offers internal services. It’s important that there is no hand-over between a stream-aligned team and the platform. Instead, the platform offers some kind of self-service, which other teams can choose to use. The whole trend of product-thinking for internal platforms is motivated by this topology. I’ve seen plenty of examples within big enterprises and small firms and I’ll write about product management techniques with concrete examples later.

The final team type is a Complicated Subsystem team which is supposed to be used very seldom. It’s used for subsystems where significant specialists' knowledge is required for a long period of time. The driving factor here is the expertise of the team members, not the potential for reuse. The Complicated Subsystem team never sits in the flow of change and work is never handed over.

Three Interaction Modes

With these team types in mind, the book introduces three modes of how teams interact. These are sometimes overlooked, but are crucial for the overall health and evolution of the software engineering organization.

Often, teams are just told to “work together” and are not further guided on what this interaction should look like. Team Topologies makes the following differentiation on how teams interact and what to expect from each other.

The first interaction mode is Collaboration, where different team members work closely together. The team shares the same goals and their processes and activities are intervened for a certain period of time. The amount of collaboration between the two teams might wary but should be temporary or is a signal for a different team structure. We need to make sure that we have a well-defined collaboration goal and understand that the collaboration comes at a cost of slowing down the teams.

The second mode is X-As-A-Service, where one team provides a service to another team with an API and service level expectations. The team offering the service needs a strong sense of responsibility and a good amount of product / service thinking on topics like value, usability and feasibility. Therefore, these teams are sometimes supported by a dedicated product manager. Platform teams often use this mode to offer some e.g. infrastructure-as-code service once the need is well understood.

The last mode is Facilitating, where one team coaches another team on a specific aspect. This mode is mainly used by enabling teams, but not limited to them. The goal is to enhance the productivity of the teams they support. Facilitating teams often work on a specific aspect across many teams and can also help discover inconsistencies.

Note that teams interact differently with different teams in the organization. It’s important to create a shared understanding of how the different teams want to interact with each other.

Ready for Well Informed Adaptation

This was a very brief introduction and I highly recommend reading the book. But something I hopefully brought across is that we now have a framework to analyze, discuss and evolve on how we structure teams, and in my case the platform teams. Or in short, we have organizational awareness.

In my next post I will show a way on how to build adaptive platforms with Crossplane project and how we can support the discovery and adaptions by sensing and changing interaction modes. Stay tuned.

PS: If you find this topic interesting, and you are building a platform yourself, please reach out. I’d love to chat and exchange ideas.

(Originally posted here: https://www.linkedin.com/pulse/platform-strategies-team-topologies-matthias-luebken/)

This post is a short opinion piece on one of the key characteristics of serverless architectures: the precise usage-based accounting.

The context: Sam Newman of some microservices fame did an excellent talk called “Confusion In The Land Of The Serverless” at Craft Conference where he digs behind the scenes of this new buzzword. During his talk, Sam mentions five categories for a serverless platform which Mike Roberts has assembled:

The Key Traits of Serverless:

1. Does not require managing a long-lived host or application instance
2. Self auto-scales and auto-provisions, dependent on load
3. Has costs that are based on precise usage, up from and down to zero usage
4. Has performance capabilities defined in terms other than host size/count
5. Has implicit high availability

You can read more on this in either Mike Roberts blog posts or his free eBook What Is Serverless?

During his talk, Sam comments on these traits and one particular comment caught my attention. On the third trait ("costs are based on precise usage") Sam partly disagrees because inside an organization you probably wouldn’t need/want to do precise cost accounting. This trait seems more applicable for public serverless platform offerings.

I agree with Sam that probably most organizations currently wouldn't want to set it up that way. But maybe they should? I think that the “precise usage accounting” is one of the main innovations that serverless (more precisely the FaaS - Function-As-A-Service part) has brought to the table. And I would argue that this trait is the key to the success of serverless.

Why does this matter?

With this trait developers are now incentivised to look at the runtime characteristics of their application logic: How much memory do I need? And how long will my function be running? Now, developers have done this before when choosing the right EC2 machines. But with FaaS these assessments and decisions can differ for every function. The number of decisions to be made have increased by an order of magnitude. And this results in influencing the architecture. In a FaaS environment developers suddenly ask themselves: How can I split this function, so it falls below a threshold? How can I move from waiting on this callback to an event-trigger?

A hypothesis I would put out there is that the economics of FaaS are driving more architectural decisions than many of the existing best practices in designing these applications. Note that these design decisions aren't necessarily for the better. Eg. I've already heard about teams adding more functionality to a function just because they had 20ms of average computing time left. That said the incentivisation to create small independent functions seems to play nice with many modern design patterns. It will be interesting to see what other implications we see from this precise usage-based accounting and what patterns we see deriving from this.

Beyond architectural concerns

As you might have guessed people a lot smarter than me have already thought about this. The strategist and cloud visionary Simon Wardley has written an extensive piece on “Why the fuss about serverless?”. In that post he describes that “Monitoring by cost of function changes the way we work — well, it changed me and I’m pretty sure this will impact all of you.” On top of that he describes “worth based development” where business metrics of functions are used to drive the development. Very very interesting.

TL;DR

A major trait of serverless / FaaS architectures is precise usage accounting. This influences decisions on the applications architecture. It remains to be seen what concrete patterns are deriving from this.

TL;DR: Choose your (product / development) process as you like. But make sure you inspect and adapt and have one accepted pace setter.

(Image by Paulkeller showing a Keirin race which have a speed-controlled start.)

When I talk to people about software development processes I often get very different opinions about what they think is the "best" process. There is often a breed of Scrum, Kanban or some sort of Waterfall process (although very few actually admit it). I do think there are common situations where you can apply certain kind of patterns and processes but a lot of people miss the point. Some famous Agile advocate loosely quoted said:

"I don't care how many practices you are using and how much of a certain process you are. Start with retrospectives and keep improving and you are good to go".

Many processes have these sort of mandatory feedback and improvement cycle: Like "Plan-Do-Check-Act" from Deming or "Inspect and Adapt" from Agile or Kaizen from Toyota/Lean. Although I still think an important part is missing.

I hope we can agree on that in great modern work environments continuous improvement is an accepted practice. But what often gets out of sight from individual team members are the influencing factors that require change. If you are in a startup environment, especially in a growing business, many different things force you to change: New colleagues will join, teams will form (storm, norm and perform) and departments will be restructured. But change is not only triggered from the inside. External factors are likely to change to: markets will grow and shrink. Market segments will vanish and new ones will arrive. A product/market fit will manifest or volatilise. Or your competitive advantage will increase or competitors will arrive.

Meanwhile the team members are (rightfully so) shielded away from every aspect of the business. And they are busy doing a great job and continuously improving in their context. Depending in the culture of the company the employees are updated with other aspects of the company. But it's not their duty to put every change effort in the context of the company, the position of the market or some other aspect. This is the managers / leaders job.

I think it's an important (and often neglected) duty to guide a teams effort in their change process and give them right amount of context for the upcoming weeks and months. Ultimately it’s a leaders job to set the right pace of the change efforts and give the teams the appropriate context for their own improvement efforts.

So, who is your pace setter? Is he doing a good job at it? And if you are a leader are you giving your team / department / company the right context so they can improve accordingly?

Matthias

As of 1.1.2014 I have started my next adventure: I am joining Catalyst Zero. After almost 3 years of growing a software development department with all the bells and whistles around development, processes and teams I am / we are going for fresh start in changing the world.

I am staying in the software development business and I am glad to help any teams who need some agile and lean expertise. In addition I am broadening my scope of duties to product development. A field with lots of undiscovered potential.

At CØ „we build great software-based products and services to solve had and valuable problems“. See Olis first blogpost to get a first idea about what we are up to. And while your at it subscribe to our Twitter stream: twitter.com/c0team or our Blog. In the upcoming weeks and months I will share lots of our ideas and thoughts around software-based product development.

Two weeks ago Anna and myself were at the Agile HR Conference in Cologne. We presented the status quo of peer review efforts and had some interesting conversations about agile management and hr. In this post I'd like to share some thoughts we presented.

When you look at most implementations of Scrum there are a great deal of feedback loops: Sprint-Reviews, Sprint-Retrospectives, Stand Ups, Pair Programming and even automatic Tests and Pull Requests. To these standard loops we have added department retrospectives every half year which we call offsites.

This is great so far and we still try to emphasize and improve on those since they give valuable feedback for teams. At the same time we noticed that we didn't improve on direct feedback and guidance for individual employees. In the last two years we grew from one team sitting in one room to four teams sitting in four rooms. Although we still work closely together the manager doesn't have as much time to get to know each and every developer.

For getting a grip on the problem we sat together for a couple of workshops. We wanted to define our context and find a concept that fits our current situation. We did this with external help from Manuel Koelmann whom we like to thank for his support!

After some discussions we defined our current context as follows:

• We want more direct feedback for every developer.
• We want to stay with the existing hierachies and let the manager do the employee talks for now.
• We want to keep our ability to changing teams.
• We want to start with a focus on employee guidance and development.
• We want concrete, more often and faster feedback.

Setting our context helped us to define our concept we came up with a couple discussions later:

• Each employee fills out an online form per quarter.
• The form contains role specific questions to all his peers he works with.
• For a developer his main peers are currently: Other developers in his team, the product owner, the manager and a self percetion.
• Almost all of the questions can be answered with a scaled answer. In addition we have one freetext feedback per role.
• The form needs to be finished within 30 minutes. We hope to have higher acceptance and faster feedback cycles.
• The results are not given to the employee directly but filtered through the manager or HR. The results are than anonymously communicated in an employee conversation.

Please note that most of these steps reflect our current situation. Hopefully this differs to your setting ;-). We are a young company with even younger employees. We are still learning and want to with caution with this topic.

At the conference we also announced the availability of our implementation of the feedback form: The Adcloud PeerReviewApp. This is a simple Rails app that has to self hosted. Please note that it's very alpha and still contains bugs. But you should get an idea how it works and maybe you like join in efforts!?

So what's next? We are currently starting with the first reviews and are learning. There is lots to follow and we hope to tackle them sooner than later. If you have questions or comments please do so in this post or send us a Email. We love a hearty discussion!

We at Adcloud Dev have started using Trello for our Sprint planning. Trello is a simple task management tool mimicking physical boards with columns known from Kanban boards. We especially like that it looks like our physical board. (Why we keep two boards? That's a topic for different blog post.)

Now Trello doesn't come with a notion of card types (for bugs and user stories) or points per card (for estimating and tracking), but its a web application and it has an API. Hooray!

For the different card types we are using the Trello labels and a convention: Red=Bug, Yellow=Chore, Green=Feature. Our Sprint commitment goes only for features and chores but we also want to track bugs.

For the estimation we use a another convention: Put the points into simple brackets into the name of the card. E.g.: "Writing Blogpost (2)". The great thing is that there is already a Chrome Extension Trello Scrum that extends Trello to assist you entering and reading these points!

Now there is one small piece left: How do you do your burndown chart? Well it turns out that Trello has an awesome API. It can fetch all the lists and cards from the board. And with the naming convention we can simply define our work in progress and our work done, grab it from Trello and put it into a chart. Since we are using Google Apps a lot and since they have their own scripting environment Google Apps Script we simple wrote a script and pull the data into a spreadsheet. In that spreadsheet is an embedded chart and via a trigger the data is fetched every morning.

Unfortunately it's not easy to share and test Google Apps Script. I might work on that in the future. For now you can use the following script as a starting point. Just create a new spreadsheet. Open Tools > Script Editor and paste the script into it. Change the variables and give it a try.

I’ve been talking to lot’s of developers lately. And most of them were surprised what kind of events are happening in Cologne. But the list is huge. On the one hand there (un)conferences like the famous Nodecamp and the winning Pirate Summit or the upcoming NoSQLMatters. But on the other hand there are tons of monthly meetups:

• Likemind
• HN Meetup
• DevHouseFriday
• Ruby
• JavaScript
• Python
• BonnAgile
• Cologne Web Performance
• Limited WIP
• …

The site hcking.de has a pretty good overview.

So Cologne Hacks. Developers get out there and network. There is tons to learn and nice people to meet!

Find me here: luebken.com/+

"I'm leaving it-agile". "You've gotta be kidding".

So why am I leaving? First of all I want to make sure that I am near my family. Although I was quite lucky, arranging the traveling with a healthy family life is quite a challenge. The second reason is the opportunity at my new company.

I would really like to thank everybody at it-agile. It was fun and exciting years. I learned a lot and it was great working with you! I wish you all the best. I know that you are going to stay the agile market leader. For a good reason.

So my new company is Adcloud. An exciting advertising technology company which builds the worlds first open advertising ecosystem. I am going to join the team as the technical product manager and will help grow agile development. I am so looking forward to this exciting company and my new colleagues.

Hope to see you soon everybody. And keep coding.
Matthias

Today is the last day of MobileTechcon. Time to say thanks for all the great discussions and for meeting so many great people (Tobias, David, Stephan, Patrick, Sven, Henning, Peter, Paul, Sebastian ... ).

All of our ressources of our workshop are at Lanyrd: lanyrd.com/scmzz/

And this mornings presentation is here:

I just noticed that I haven't kept my keen readers updated on my conference participations:

End of march I will be at the MobileTechCon in Munich. Together with my good friends from Uxebu we will do a workshop about creating mobile HTML5 apps. Really looking forward to this workshop! And lots of people too: it is sold out since weeks! On wednesday I'll be giving a talk about the same topic.
And my colleague Sven will be giving a talk about refactoring a Top 10 iPhone App. He is going to give some great insights! So stop by our booth and lets chat about mobile, agile and beer in Bavaria.

There is another conference coming up in May. Details soon.

I had a great time at the WJAX. Here are my slides. And here are some more impressions. This time an interview with me:

I am the WJAX right now. Here are some impressions of the first day. Enjoy.