What makes an ideal agile team?

Summarising

In many occasions I am being asked by clients to share my thoughts on how they are (planning to) form their Scrum teams. My recurring comments always are to have the team as small as possible, stable and consisting of full-time individuals, maxing out at 9 persons. Have one or more coaches linked to the teams and make sure that there is a mandated Product Owner.
Make sure that relationships are based on trust and ensure that accountability and responsibility are two aspects addressed organisationally with full support of upper management.

The other day I was asked by a manager of one of my clients to comment on a proposal of one of his vendors. A key vendor that has been under delivering since a very long time, but still considered to be a strategic partner in most of my client's business. The vendor is currently experimenting with a different way of addressing its customers by better aligning its services to the needs of its customers. The vendor is proposing to setup a cross-functional team that will be tasked to deliver relevant products in short cycles.

My client is a little sceptical but willing to give the vendor the benefit of the doubt. As such he's agreeing to become one of the first customers to work according to the new proposed process and is now asking me to see what to look for in the proposal. Being the first customer and thus investing time and effort in amending the current mode of operations with this vendor, there's some head room to 'ask' for specific adjustments to the proposal.

The vendor is going to deliver new products and services in a variety of categories to my client and is proposing to setup a Scrum team. My client now wants to know if there are specific aspects of this team that need to be addressed. Also the role of my client with regard to this team is a point of interest in the negotiations. And obviously the delivery of products and services to my client.

Basically the question is: How should my vendor organise its team in order to better meet our requirements? The answer is reasonably straight forward.

In principle you want to keep a Scrum team as small as possible, that is actually a basic principle. The maximum size for a well-functioning team is 9 people. This has already been discovered by the ancient Romans, no kidding.

I would like to argue to start with 6 or 7 people. Rather 6 than 7 by the way. The reason for this is that otherwise you will get specialisations within the team that come to lie with one person, that will immediately become the SPOC / F, who can not get sick or go on holiday.
The strength of a well-collaborating team lies mainly in the knowledge spread throughout the team as well as complementing personalities of the team. This allows members to challenge, supplement and assist each other. It is a common mistake to see what kind of techniques and technologies you want to use and to find the experts for that. It is a Team and not a Group we're trying to forge. Understand the difference, it's important.

I find the use of FTEs in resource planning of Scrum teams confusing and dangerous. I've seen this plenty of time and it never resulted in anything good. One FTE can be filled in by 1 or more people, and that is what you want to prevent. You want the team to be stable, not only within a sprint but also over sprints. Almost at any cost. Again, I'm not talking about a group but about a Team. And, they must all have an engineering mindset. People who dislike doing things themselves and want to automate everything by definition.

Recently I was asked on the subject within the context of an initiative to start treating an operating environment as a platform, which was going to be treated like a product. With a Product Owner at the helm. And a group of my client's experts was assembled to form the 'Scrum team'. I was asked to provide my thoughts on this setup.

We're talking about server provisioning, networking, identity and access management, firewalls, certificates etc. This team is also going to be responsible for operating the platform they're developing. My initial thought is to have therefore functional expertise (provisioning, networking, identity management, loadbalancer, firewalls) and an engineering mindset (automating, monitoring, everything as code), if possible either a senior in one or more functional areas and medior in engineer and vice versa. Depending on the team composition, there may also be a medior / medior combination when there's enough seniority in the overal team. Attitude is more important than knowledge in my opinion. I would therefore always prefer someone who wants to automate, will always test and always asks for insight into production.

I do not see why one would need a full-time Scrum Master, that's probably overkill. Having said that, it seems wise to let the team choose their Scrum Master from the team itself. And with experienced teams that have been working together for a considerable time this is likely a viable option. But when you're just starting with Scrum in your organisation or when the team is just starting with Scrum and Agile concepts, I always prefer a Scrum Master from outside the team. Since the Scrum Master is the team's conscience, and at times will have to use strong words to get focus back on the team's goals and principles... it will be challenging for a Scrum Master from within the team.
Add a coach for roughly the first 6 sprints to coach the Scrum Master, even though the Scrum Master might be experienced, it is still good to have a coach. The team chooses the Scrum Master because it will ensure that it's their choice, a choice supported by the team. You want good chemistry between team and conscience.
The role of the Scrum Master is all about addressing people to the standards and values ​​of the team, but also facilitating them in doing their work. I have seen in various situations that it can work when the Scrum Master is also facilitating in another supportive role, e.g. as Tool integrator in Continuous Deployment environments. I'm not a proponent of this though.

I told the client that I was missing the Product Owner (PO) in his approach. The PO is relevant because the PO determines what the team is going to work on. That would be the person who talks to the customers about what is needed, etc. And to the users about what was delivered. Therefore the PO is accountable for what the team will deliver. The team is responsible for what it creates, the PO is accountable. These are the two most important aspects.

Keep in mind that responsibility can be delegated and shared, accountability cannot be delegated nor shared. So a delegated PO doesn't exist, as it would mean delegated accountability.

So a stable team and a PO (outside the team) defining the team's priorities. No one else but the PO is mandated (i.e. empowered) to determine what the team is working on, because the PO defines the priorities of the products and features to be developed. The team plans the work. So there has to be, by definition, a lot of trust between the PO and the Team, because the PO must be able to rely on the team's commitment to what they are going to do in a sprint. Here comes the Scrum Master in the picture again. Because the Scrum Master has to make sure that the team does not overcommit.

Here's an interesting aspect, the trust aspect. An aspect I will address in a future post, where I will cover more on metrics and KPI's and the trouble of the user story in this regard.

In my opinion, the role of customers should be not only one of the customer, but also one of the user. This will allow a user-centric approach on developing the product, and at the same time be very customer aware.

You should look for a future post on stakeholder management and agile processes to get some more insights on this topic.

I told in another case with another client of mine that it makes perfect sense to start treating their Scrum teams as internal startups. Basically consider the PO of these teams as the CEO of the startup and the management team would be the Venture Capitalists. By doing so, there's ample opportunity to experiment and evolve into a value driven minded organisation.
In this particular case I suggested to see if it would be feasible to go along these same lines.

The PO will need to determine what an MVP would be. Something small delivered in short increments, so to quickly find out if something is usable. Start cultivating a mindset where 'Done' means 'In use at a customer!' (Done = Live).
Agile means being able to deal with change in a timely manner. So here comes the point of view that the PO is a person who has a strong personality and is met with a lot of respect. Somebody that knows what the product should look like, with a product vision. And the PO will have to be mandated/empowered. It should never be the case that the customer can circumvent the PO to get things prioritised. This is for internal and external customers. And managers.

Again, I told my client to get a coach involved here as well. Even if it is an experienced PO, it is important to be coached. In the beginning intensive, but perhaps later (even after 6 sprints) it may be a bit less. It might be an opportunity to invest in an agile-coach, who will take care of all the coaching work (team, Scrum Master and PO).
Just like the PO is mandated to define what is and what is nog going to be in the product, the Team and the PO should be granted autonomy, independence and self-reliance. The PO is positioned external to the Team and in case of scaling up the team to two teams I would like to argue that both teams get the same PO.

In this particular setting, one could even consider starting with three small teams of 3 to 4 people who all work on their own part within the platform, three products if you will. A team for provisioning servers, one that works on network and connectivity (including DNS, firewalls, loadbalancers) and a team that focuses on IAM Automation (Directory services for example) and certificates. Combine these teams with a single Scrum Master and a PO with three Teams. Obviously an Agile coach for the whole bunch.

So, concluding: A maximum of 9 individuals, all full-time, in the Team. One of which will assume  the role of Scrum Master. Alternatively, form 3 teams of 3 to 4 full-time individuals with an overarching Scrum Master. In addition, a PO with knowledge of the subject matter and full mandate and an agile-coach.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

You know you're the Product Owner...

...when your product's users are complaining and you have to worry about your bonus.

Summarising

The Product Owner's bonus is on the line when users complain! You're not worried about the upcoming appraisals although the users are complaining? And you're not looking for that boat you fancied for so long because the users are giving you great reviews all the time? You're not a Product Owner.

In this day and age of DevOps and Agile, the most coveted job in the world seems to be the one of Product Owner. Never have I seen so many co-workers turn into a PO as recently is the case. Operators turning into Operations PO, testers turning into the Testing PO, security experts fulfilling the role of Security PO. It's amazing to see all these Product Owners mushrooming in organisations.

Understandably, because their original jobs are nearing their expiration date, or so they're let to believe.

The other day I had an interesting discussion with one of the architects of a client of mine. We're discussing a lot these days about architecture, API's, services, data warehouses and other interesting stuff. But this time around he challenged me. Seriously.

This particular client is a typical Project oriented organisation. Projects develop something and once it goes into production and becomes at times business critical, a very efficient department takes over. (Just in case you're wondering why I put efficient in italics, read this post). This architect is part of a department that is making the transition from a Project oriented towards a Product oriented way of working. It's a significant move and absolutely not trivial.

What's interesting is that the general understanding of the necessity of a mandated Product Owner has caught on with this client of mine. What hasn't caught on is that the PO is supposed to be somebody from the business. Take this with a tiny grain of salt thought, as by stating that the PO needs to be a business person, I mean that the PO needs to understands the business in which his products make a difference and generate value. Do you need to be an MBA? Nope, but you do need to understand the relevance of the product for your user.
And this is exactly the issue at hand. All the different so called PO's my friend the architect is dealing with do talk with the user, but do not necessarily understand the relevance of the products they're using. The Operations PO discusses the stability of the product, which makes perfect sense because the focus of an operations person is ensuring that the product is not crashing. One could argue that the relevance of an operations person is the fact that products will crash, which is a bit ironic. The Testing PO is of course focusing on whether or not the product is conforming to the requirements and specifications. This is what testing is all about: Is what has been build, delivering what was intended in the first place. And with all the security incidents, global incidents at that. And with all the new laws and regulations around privacy and what not, the role of the Security PO is cut out, it's focusing on limiting the risks for the organisation by having the products being used by, well the users.

Since all these PO's are doing their job extremely well, the products are up to par and are in fact creating value for the organisation. They surely do. But that is not to the credit of these PO's. The reason for this, is that none of the PO's are concerned with the best product, i.e. the product that is helping the user to conduct business. They are all focused on the product delivering what was intended, namely stability, requirements and security.
I hear your brains churning on this, so let's make an assumption here to illustrate: What if the product crashes all the time, but when it doesn't it removes the hassle of manual steps in a complex process? And although it crashes, data integrity is guaranteed? The operations person won't like it and will very likely take the product out of commission. Why? Because operations is affected when stability is an issue.
So now it turns out that the product is fully according to spec, tests are 100% green but the user will not stop complaining because the product is still not helping to drive business? The tester will not look into this as a testing issue, but as a specification issue. The fact that the tests didn't reveal this major flaw, namely usability. And even when it did, usability being a testable requirement is a novelty. It is with my client's organisation and it is in many others.
Guess you can fill in the problem with the Security officer acting as PO. Consider it a small exercise to flood your brain with some endorphin.

The issue here is that none of these so called PO's is accountable for the success (or failure) of the product. None of them is. And this is what sets the PO apart from everybody else in the organisation:

The PO's bonus is on the line when users complain!

This means that when a accountability of a product's success, i.e. the level if complaints from users about the product, is not with you, you're not the Product Owner. It also means that unless you get a full mandate to make a success out of a product, you're not the Product Owner either.
Don't accept the role of PO unless you get full mandate, which includes discretionary say about the product team, its road-map, funding, etc.

Back to our wannabe PO's, because that's the correct word for them. Their bonus is not on the line, they're not responsible for the product's success. They're definitely not accountable. But that doesn't mean that they're not responsible for making the product a success. Their knowledge, insights, experience and general professional view on the product is invaluable input to the PO to create a success out of a product. The PO shouldn't ask for their input, but when the input is not provided, the questions should be raised. They're not impacted by bad reviews, the PO is. They do have to worry about their jobs, because if the PO can't use them...

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contact-list. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

‘The Continuous Delivery IT Team’ fallacy

Summarizing

Considering Continuous Delivery something for your IT department is throwing your money out the window when doing an Agile Transformation program. If you want to do so, make sure you throw it into my direction. IT is a business concern, Continuous Delivery is a business concern.

Over the past couple of months I did a series of awareness sessions on Agile, Continuous Delivery and DevOps at a large client of mine. As is rather common, also at this organization the initiative to move towards Agile ways of working, Continuous Delivery and a longing for DevOps is with the software developers. This makes perfect sense when you think of it, because it's the developers that want or rather need to make changes and the pace by which they have to deliver changes is only increasing. But I guess I don't need to tell you this.

But Continuous Delivery (or Deployment for that matter) is only possible when you don't consider it a software development thing. There really is no point in spending any time to move to Continuous Delivery when you are not planning to do it broadly. I'll get to that in a second.

During these awareness sessions, which I do with colleagues from the same team, we discuss with non-developers like risk officers, sys admins, project managers, architects, test consultants, etc. we outline what Continuous Delivery and DevOps mean within the context of my client's organization. It's a common story and I won't bore you with the details, but obviously we touch upon the benefits of small increments, feedback loops and so on. And the fact of the matter is that our story actually does sound like it's the perfect thing. And we consistently get the question: "So, really, it can't be all awesomeness, so what's the catch?". And in the rare occasions we don't get this question, we still answer it.

The biggest problem with Continuous Delivery and everything following from it, is that it is not a software development thing, or even an IT thing. When you think so and still go down that road, spare yourself the frustration and disappointment, drop me an email asking for my IBAN number and transfer the budget for your transformation project into my account. At least one person will be happy with you spending that money.

And yes, even when you think it's an IT thing, you're better of giving me that money. This is what I call:

'The Continuous Delivery IT Team' fallacy

Let me explain. First of all, let's make sure you understand what I consider Continuous Delivery. It's the process that produces a product that results in business value in order to be able to sustain the organization up to the point that it can be delivered to a user and it will be delivered to a user as soon as possible. It's not a perfect definition or even a formal definition, much because there's so much more to it. But what's important is that it defines work on a product as being done, when it is ready to be delivered to a user. The actual delivery is an explicit manual step which is decided by the Product Owner to be taken as where the rest of the process is preferably fully automated. This as opposed to Continuous Deployment, where the delivery to the user is also automated and hence triggered by the developer when committing his code to the source code repository. Again, this is a definition close enough to what it is and fitting the purpose of this post.

With Continuous Delivery and agile working in general you want to receive feedback for what you've been doing as soon as possible. And preferably you want this feedback to be such that for one you know that you've done well and secondly you're actually contributed to the bottom line of the organization you work for. This is why we like to work at the granularity of user stories and epics and delivery on a per user story or at least on a per epic the changes to a user.

As you now understand, for every single user story or at least epic, you need to do everything that needs to be done for a release, because you're delivering to a user. Somebody is going to actually use that little piece of software you've worked on with such a passion. Fact may be that the complexity is limited because increments are small, still you need to release new or changed software. And there's the catch.

With software delivery, or product delivery in general, it's not just the product development team that's involved, or more specifically the software development team. It's other teams and people involved as well. Think about marketing, legal and compliance, worker's associations, security and risk management. These are all teams that are not part of the IT department. And no, security officers are not part of an IT department, and in case they are, they most definitely shouldn't be. And the biggest catch of all, the 'business' needs to be involved from day -1. Unless all of these different roles, teams, people, stakeholders, however you want to call them are on board and work in those same small increments, not becoming a bottleneck and automate as much as possible, your Continuous Delivery efforts are a waste of everybody's time and your organization's money.

Back to your 'business', it's them that request for features and not the user. It's them that pay for the development of the product not using it per se. When that 'business' is not capable or willing to define the product's features such that they can be delivered in tiny chunks, than you're out of luck and not much will come from Continuous Delivery in your organization.

The Product Owner is key in all of this. Being the hinge between the Product Team and the rest of the world, the PO is the single one person that can and must ensure that the product is delivered incrementally, with business value visibly added with each increment. PO can't do this, you've got yourself some trouble. The PO, at all times, must be able to relate every single feature, one way or another, to an improved life for the user of your product and therefore a positive effect on the organization's bottom line.

So, Continuous Delivery is not an IT thing, it's a business thing. And don't let anybody convince you otherwise. Being as it is, moving towards an Agile way of working and Continuous Delivery or Deployment, in fact would mean that you no longer consider your IT as being delivered by a separate IT department, but as an integral part of your business.

This does make perfect sense, considering your IT as part of your business I mean. It makes perfect sense because more and more business are all about information and are run based on information. IT is no longer a tool, like a glorified typewriter, it is in fact what is producing business value. No IT no business.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

This is the canvas your office walls are missing...

... just in case you read my previous post on the Dutch excellence in IT Architecture; No this is not a post about Rembrandt or Van Gogh. If anything, it's close to Mondriaan. The canvas I'm talking about is the Business Model Canvas, a Swiss invention in case you were wondering, made by Alexander Osterwalder. Both the Business Model Canvas and Alexander Osterwalder are featured on Wikipedia. Okay, here's a little trivia. Alexander Osterwalder was born in 1974 in the Swiss city Sankt Gallen. Fact is that I lived in St. Gallen 20 years later, when I did my internship at a Swiss company while studying Computer Science at a Dutch polytechnic. Coincidence? Maybe, but maybe it was ... well don't let me get there.

The importance of the BMC is that it allows people to make the right decision when they need to prioritise their pending activities. This is why you need to print it out poster-size and make sure that everybody in the organisation can at all times take a look at it from their desk. The BMC should be ingrained into your organisation!


So, the BMC. I think it's probably the most important model you as an architect can work on with your team and than print it out and give it a triple A location on a wall in your office. Printed such that everybody can see what's on it from any angle. And just in case your office has more than one room, make sure you print one for every room.
Just so your organisation's mission doesn't get lost, print it on the same poster above the BMC. Oh, by the way, you can also ask your management, your CEO, your board of directors, to give you the canvas so you don't have to create it yourself.

The reason for the importance of the BMC is that it very clearly documents why you're doing all that you're doing. And if you can't explain why you're doing what you're doing by means of the BMC, stop doing it.
The magic of the Business Model Canvas is that it helps you, initially, to write down what you think your business is. Business here is meant in the broadest sense of the word, so even when you're in an NGO, a not-for-profit, some form of governmental organisation or a commercial business, the BMC is crucial, especially the activity of filling the BMC. It should be your primary source of focus.
What is the BMC? Without trying to go too deep into the topic, here's a little extremely short primer. Do a quick Google or Bing search to find out more about the BMC.

The BMC has 9 fields that are desperate to be filled with your input. They're divided horizontally as well as vertically. Horizontally you see on the bottom the money flows, what's coming in, Revenue Streams, and what's going out, Costs. On the top you'll find 7 fields that correspond to your organisation, they explain all about the 'why' of the money flows. Who's your customer, who are your partners, what's your product, etc.
The vertically there's a split right in the middle. In the middle you find your product, what ever that may be, it even may be a service. On the left you find everything need to create that product or to deliver that service. Notice that this is on top of your costs, since input for product creation or service delivery requires payments, i.e. costs.
On the right you find everything that is needed to create a revenue stream through your product or service. Customers, channels through which to sell and of course customer relations to keep customers happy and invite them to purchase more.

As you can now see, every aspect of your organisation and it's (business) value is captured in one model. You should read about my view on models, which you can find here. The reason to read my view, is to understand why I'm a bit hesitant when talking about models. But also to understand that the BMC, which is a visualisation of your business model, is one of the best models out there because it so clearly defines what single aspect of a business or organisation it visualises.
Anyway, having a BMC allows you to ensure that your activities are related to what your organisation attempts to achieve, being creating value that is sustainable and in line with your organisation's mission and vision and is according to it's strategy to realise this vision. Say what? I need to formulate a mission and a vision as well and come up with a strategy? Well, uhm, uh, duh! I would be worried if you hadn't done so already. So I'm assuming that you have, giving you the benefit of the doubt.

One very practical way of filling in the BMC is to gather everybody from the management team in a single room and do a 3rd third workshop.
The complete management team should be in the workshop because they need to not only understand what the business model is, but also why it is the way it is. And understand everybody's input. Furthermore, all areas are related to each other.
When you're in a startup, this workshop can be with just the founders, or maybe when you're really at the early stages, it's just you. In a larger or more established organisation or if you're catching up with the BMC, you should involve all of the MT team, or maybe the members of the board. Just get all the executives in the room to do the workshop.
With respect to the BMC, limit yourself to the upper 5 fields and address them one by one. Take a full day, limit the total time for each field to 60 minutes. And make sure that you have a healthy refreshing lunch and a nice diner afterwards.

That's the recipe for a BMC, but what of it? What you'll notice is that when you work on the BMC, even without the 3rd third approach, some of the fields are easy to give some content, and some seem almost impossible. Now forget about the first category. I'm sure you'll manage. Heck, you'll be probably in need of restraints to keep you from talking about it. Focus on the hard ones, that's where you'll be able to gain the most from the BMC.
Typically the easiest is the Value Proposition, especially when you're a startup. When you're an established organisation you might find that one harder to do because you've diversified your business, and possibly too much.

I would say that you need to focus on your customers first. And make sure you've got some names of people you can contact. A good way to address this is to come up with a sample group of 5% - 10% of your customer segment that you can contact directly. When your market is smaller than 500 customers, consider the lower end of the 5-10%, when your market is larger... you get the drift.
These are the customers that you'll use to validate the rest of your BMC.
Now first validate your value proposition with your customers, use your sample to do so. Chances are your customers don't think your product or service will help them (optimally) or are not willing to pay for it or something else. There's a ton of ways to do this. Interview them, have them sign-up for a pre-order, start a Kickstarter campaign, etc. The point is that you need to make sure that your value proposition is feasible to pursue. And now keep on listening to your customers and keep them informed. And after reading this, you also know without me telling, that you need to make sure that your contacts will provide reliable feedback. You're building your BMC and therefore your business on their feedback. And before I forget, make sure that your vision and strategy are also taking this feedback into account.
Once you've got your customers and your value proposition filled, it's time to do that workshop and fill in the other fields. Make sure that they're in line with your customers and your product. But also make sure that they're in line with your mission and your vision. And strategy of course.

Which takes me to the lower half of the BMC, the money flows and how to address them. You'll need to make sure that you know how to make money from your product, or rather what determines your income. And you need to know where your costs are coming from as well.

The importance of the BMC is that it allows people to make the right decision when they need to prioritise their pending activities. This is why you need to print it out poster-size and make sure that everybody in the organisation can at all times take a look at it from their desk. The BMC should be ingrained into your organisation! It also means that the BMC has to be communicated to everybody. There shouldn't be anything secret about the BMC. When it is, you're screwed because you need to take a very dictatorial management approach with micro management. And if you take that approach you won't have time to generate your revenue streams to cover your costs. Think about it, it's one sheet of paper, what secrets can you fit on one sheet of paper anyway?

So you want everybody in your company to know what your business is, and how you think it can be sustainable. It will allow everybody to evaluate whether their actions are helping the business, create business value, or not.
And it goes beyond this, think about new product development or new features to existing products? Just one look and discussions about wether or not to do it can be rendered irrelevant. Marketing campaigns? Whether or not to do them is written on the BMC. Deciding about whether or not to partner with somebody? It's in the BMC.

This leaves me with my final comment about the Business Model Canvas; It is a model that needs to be revised, once every so often you need to reconsider its contents. Do it periodically, once every 6 or 12 months, but also do it when you've come to a pivot-point and realise you need to adjust your strategy, your vision or maybe even your mission. So make sure that you will maintain your BMC to keep its relevance.

I think all the above make sense, if not drop a comment and tell me what's not making sense to you. But if it makes sense, why do I hardly see a BMC print-out on the walls of offices? Why is it that so often there's no business model canvas even made? Probably there're three explanations.

• The existence or validity of the Business Model Canvas is unknown.
• It is considered too hard or too confrontational.
• It is considered a management only thing.

Whatever the reason is, you've come this far, now understand what it is and that it is beneficiary for the complete organisation. And it isn't that hard to create this most important canvas for your office walls. In addition, the canvas helps you to create a sustainable business.


Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist. But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

PS: Here's an interesting link to a more elaborate BMC picture.

[Special thanks to my amazing wife, who took the time to not only read the post but to also send me a Whatsapp with a whole list of corrections the post needed. Thanks dear.]

Disruptive creativity is in the 3rd third

The 3rd third approach assumes that you want to have some creative thinking for example to fill a business model canvas, to come up with a new product, or just to become disruptive. The 3rd third approach is an approach to help yourself or your team to become truly creative up to a point that you can be disruptive.
Especially when you're a startup in a commodity market, or at least an established market and you have found a means to become a player as well, you need to be disruptive. Having said this, when you're established or even market leader, you need to make sure that you will have a competitive advantage. The third-third approach helps in that it implements a process that weeds out all the usual suspects in creative thinking.
The complete management team should be in the workshop because they need to not only understand what the business model is, but also why it is the way it is. And understand everybody's input. Furthermore, all areas are related to each other.

The approach means that when you have to come up with ideas, you timebox this idea-flow in three periods of about 5-10 minutes with in between at least 5 minutes but preferably 10 minutes where you take a coffee, have a smoke if you need it, or take a bathroom break. Or answer a call, although I prefer not to make that call until after the third timebox. During each timebox everybody writes down as many things that spring to mind about the topic at hand. Once the timebox is over, there's time for pause. The second timebox is exactly the same, but every idea already on the table is off-limits. So you'll need to come up with new ideas. The third timebox is a repetition of steps.

In my experience it makes sense to have a facilitator in the room who keeps track of the time, ensures that there're plenty post-its and sharpies in the room. Who sees to it that everybody is drinking sufficiently and who makes sure that there're energy bars and fresh fruit available. During the breaks the facilitator makes sure that all written down ideas are easy for everybody to read, even to the point of recreating the post-its in a readable handwriting. The facilitator should not be involved in the creative process.

As you'll notice when you take this approach, the each timebox will be harder when it comes to generating ideas. Especially when you've never thought about the topic before. But the wonderful thing here is that the most outrageous and therefore most likely disruptive ideas are created in the third timebox. There're the ideas of value, otherwise revert back to the first timebox after considering the second timebox. It should be worthwhile to look into the ideas written down in the third third and see if they're feasible. They might seem too outrageous at first, but then again, that is probably the sole reason why they will be disruptive; Nobody had thought of them before. So feasibility might very well be the way to increase your business' value, market position, or relevance.


Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

This is why the Dutch make the best Chief Architects...

Summary

Last Wednesday the Dutch had to perform their civic duty and vote. You may or may not have read about it, but it inspired me to post about why the Dutch make such awesome IT architects, and why your Chief Architect should be Dutch.
Having a Dutch Chief Architect, or even just architects, in your organisation will ensure that there's going to be synergy. That you'll be able to benefit from something like a collective mind. That you will have a strong person that is able to bridge gaps in culture and break through language barriers.

Why the Dutch are the best architects out there...

... Last Wednesday the Dutch had to perform their civic duty and vote. You may or may not have read about it, but it inspired me to post about why the Dutch make such awesome IT architects, and why your Chief Architect should be Dutch.

I could end my post right there, because I mean, it's obvious isn't it? But just in case you're not too familiar with the Dutch let me explain.

First of all, architecture and being an architect is all about communication. It's about explaining what you want to achieve and why you want to achieve it. And the trick here is that the architect needs to ensure that there's buy in throughout the organisation in such a way that everybody is not only on board, but also convinced that it is the right direction in which the architect wants them to move.
The Dutch do this by nature. It's an essential part in the Dutch culture to work together and get onto common ground. The Dutch call it "Polderen". It's a Dutch trait, and only the Dutch know how to do it.
Here's the deal, with the latest election results, it's very thinkable that it will take up to 4 different political parties to form a coalition that has a majority in the parliament. And the Dutch are not worried at all, because we're confident that although the different factions have very different believes, they will be able to work something out and rule the country. Form a government.

What the Dutch can do as part of their culture, an Enterprise Architect, and a Chief Architect ever so more, will need to do as part of their role. Get common ground, work with different powers within an organisation and ensure that the whole of the organisation will achieve its goals, meet its objectives, work together to implement the strategy. Who better than a Dutch architect is most suitable to perform this Herculean task?

But wait, there's more!

Chances are that when your organisation has enterprise architects and a Chief Architect, your organisation will be fairly large and will have employees, vendors and customers from all kinds of backgrounds. Could be different ethnic backgrounds, different religions, different nationalities, different everything. Working with all these different people with different views, cultures, languages, etc. will be a challenge.
Again, the Dutch will be able to fit in immediately and work with them all. For one, the Dutch speak a variety of different languages. Of course they'll speak Dutch, but English will be there covered as well. And very likely they'll speak German and French as well. More and more Dutch children learn how to speak Spanish or Chinese in school. But on a linguistic level, you're covered when you're dealing with the Dutch. In addition, hardly any of the TV shows are dubbed, instead they're subtitled, so you can be sure that that Dutch architect you're now thinking about will understand the nuances of your languages, a fair amount of slang and sayings.

What's more, ever since the Catholic church started killing people because they didn't agree with how the Pope thought how life had to be lived, the Dutch took in those that fled from the Catholic raids and Inquisition. And more importantly, the Dutch embraced all these different nationalities, religions and cultures as part of the Dutch society. Not always without a fight or without amendments, but nevertheless, Dutch culture is to embrace other cultures.
Now think about different cultures within your organisation. For one you most likely deal with employees from all over the world, or at least different religions, upbringings and the like. But there's more. You must have noticed that those people from accounting think rather differently from them from legal, and the sales people are slightly different then the people working in IT. Still in IT itself you've got the developers and the operators that are different. However you look at it, you need somebody at the helm that you can trust with knowing how to deal with different cultures, mindsets, objectives, manners, languages and vocabularies. Who else than the Dutch architect can take this task upon himself?

Obviously the architect is all by himself, even when he's the Chief Architect, he'll be the minority. He'll be the few among the many. Heavily outnumbered. Under normal conditions, that might be a problem, but not when that Chief Architect is Dutch.
The reasoning behind this statement is quite simple. The Dutch know how to rule the world. Until not that long ago they ruled together with the British the Seven Seas. They, the Dutch that is, managed to become a global player although massively outnumbered.

Finally, the Dutch don't take anything for granted, but more importantly, they're a people that don't take just anything at face value. Instead of just mindlessly following orders, the Dutch will use their head and will stubbornly refuse to do something that doesn't make sense.

Having a Dutch Chief Architect, or even just architects, in your organisation will ensure that there's going to be synergy. That you'll be able to benefit from something like a collective mind. That you will have a strong person that is able to bridge gaps in culture and break through language barriers.

So yes, I think it's clear. The Dutch do make the best Chief Architects.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

"We develop our frontends in Angular" is not an Architecture Principle

Did you ever hear that story about that architect who was telling the developers how to develop their solution? Badabing, badaboom!!!

Yeah, I know it’s a bad joke, there’s no laughter there. I better not aspire a job as a standup comedian. Thing is though that there’re still plenty architects out there that are not only defining architectures, but also tell the developers how to develop that architecture. It amazes me why this is the case.

I know that not that long ago I told you to ditch your architects when they are busy creating roadmaps. But actually you shouldn’t because there’s a real legitimate reason for defining roadmaps. The reason being that they’re an excellent tool. So ditch the architect when roadmaps are what they deliver, because those are the ones you want to get rid of.

Now there’s another breed of architects out there that I have a hard time to understand. I really think that architects should be architecting. That’s what their roles are, just like developers should develop. People should be doing what they’re supposed to do, and preferably spend some time outside their boxes while thinking about what their job really is.

For an architect, the sole raison d’etre is to have answers when asked questions and at the same time be enigmatic. Well, maybe that last part should translate into being helpful to whoever is asking the questions to get the answers themselves.

The architect, as I see it, is the one that defines the boundaries within which the developers can act freely while being confident that there’s no harm to the overall integrity of the enterprise or the organization for that matter. The strength of the architect, the real power, is that this can be done by defining Architecture Principles. These are extremely powerful because you can link them directly to your organisation’s mission, vision and strategy. Well if you can’t than you should reconsider your principles. But if you can, you’ve got your business justification for your principles and you won’t need to define the business value of those principles either. But just like any power-tool, they’re not trivial and to formulate the right principles you really need to be ready to spend some serious time. Furthermore, you need to limit the amount or principles to a maximum of 10, just like the 10 commandments. More will be hard to remember by heart and live by, which is what you should expect from your developers. Less is better, but beware of the fact that you should cover all the important bases in your environment.

There’s another tool that’s really powerful, which is the reference architecture. Which in fact is a model, one of the good kind as you can read here. A reference architecture is a model of an application that meets all the architecture principles. But beware; It’s a model, not an architecture! It’s a visualization of what the architect had in mind when he defined the set of architecture principles. And more importantly, it’s one of many possible models.

So as the architect defining the reference architecture you should be aware that everything in it, can, should and will be taken with a grain of salt. And as the developer you should understand that the reference architecture is just a tool for your architect to illustrate what was meant by the architecture principles, and definitely should not be taken literally.

Ah, so what about the joke, the bad one?

Well, there’s this group of architects that don’t understand the difference between architectures and models and instead of defining architecture principles and reference architectures, they tell the developers what and how to develop such that they comply with the principles.

There’re some serious problems here. For one, the architect omits the definition of architecture principles for whatever reason. Likely because it’s too hard, or they don’t see the benefit. Shame on them! Then there’s the case where the architect ignores the fact that the developers are very likely more proficient in developing than the architect. Oh, and let’s not forget about the fact that architecture principles are almost timeless, or at least stick around quite a bit longer than the typical technology, tool or framework. Yet, this architect dismisses this simple fact of IT and at the same time doesn’t keep the construction manual, because that’s what it is, in line with the current state of IT affairs.

For example, I discussed a couple of years ago, where ‘discussed’ is a euphemism for ‘verbal fighting’ with some fellow architects in some kind of architecture board that it made no sense to dictate that a multi-tier architecture should always be deployed such that each tier should be on separate infrastructure. Instead the application should be complying to the fact that data access logic not to be mixed with business logic nor with presentation software. Sometime ago I had a discussion, which was a real discussion, about whether or not we should define in reference architecture that either Eclipse or Visual Studio should be used for coding. Uhm, I think not, thank you very much. And yes, this was a real discussion.

There’s the discussion about what part of an application is developed in what programming language? We had the discussion at a startup I was Chief Architect at. Guess what, the developers made those decisions, I just stated the principles that I wanted them to comply with.

So what it actually boils down to is that architects need to govern, and that should take up most of their time. They should safeguard the integrity of an organisation’s IT landscape and make sure that in all cases the applications or rather the products in that landscape can comply with the architecture principles. The architect should promote and facilitate an unambiguous way of working among teams. The architect should also be concerned about an ubiquitous vocabulary within the organization when it comes to business and that it is translated by IT consistently.

The architect should not dictate that a particular programming language to be used, that a particular infrastructure is to be deployed to or that specific tooling is to be used. And in those cases where there’s a good reason for the architect to do this anyway, than it should be implied instead of explicitly dictated. In case all development is to be done in Java, the architect should ensure that only Java developers to be hired. In case everything should be hosted on Amazon AWS, the architect will have to pave the way for the teams to use Amazon AWS, making it the favorable option for the teams of the many hosting alternatives they can choose from.

As you might have guessed here, is that the architect I’m referring at is the enterprise architect or domain architect. Definitely not the application architect or the solution architect. The latter are both very much there to device a solution for a problem. They’re more like designers than architects in that sense. Which brings me to another little piece of personal amazement. Why are there so many large organisations that have domain architects on enterprise level whose domain has nothing to do with the business, but are strictly technical? Probably this is some remnant from the time that we considered IT to be a cost center and centralization of IT was the holy grail for many a CIO. Nowadays where we see IT as a product, something that is not just setting us apart from the competition but an actual product, there’s hardly any room for the these architects, at least not on an enterprise level. They should be working closely with products teams from the same product portfolio. Become Product Portfolio Architects, safeguarding the integrity of the IT landscape of the portfolio. Is it a demotion? Definitely not, it just means that they’re relevant again.

To paint a little context here, I’ve been that architect I’m complaining about. Emphasis on ‘been’. I enjoyed the technology too much to let it go, but as the domain architect I wasn’t allowed to work on the software, so all I had was telling the developers what to type. Initially I got away with it, because I was at least one of those architects that actually could still code. But really soon thereafter it became apparent that I hardly had enough knowledge or experience to really do the work. To me that was a real eye opener and I had to good fortune I was working with people that didn't hide the truth from me. They expertly conveyed to me that yes I was more than a decent architect, but as a programmer I really wasn't up to it anymore. And as much as that hurt at the time, it allowed me to focus on architecting. I still code, because I still think I need to be able to understand and to know that things might work. But as an architect, especially in an agile world I find myself more and more facilitating, communicating and coaching. Working 3 sprints ahead of the developers, not because I'm that a fast thinker, but because being an architect I need to be able to set directions. Let the team worry about how to get to our destination, be their own satnav system, and me the architect am more and more the person controlling the system's settings. Controlling whether or not to allow ferries, toll roads, to prefer back roads, go for the scenic route or the fastest or most economic route.

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect

Principles of the API-First paradigm

API's are weird puppies. They've been around since forever and whole battles have been fought in courts to gain access to API's. This was in the old days when having a platform with an API for 3rd parties to develop for your platform meant that you had a lot of leverage over those parties. Not providing early access to them meant that they would be late to the party and all the sweets where already shared between the early guests. Having an API meant having power. Not providing access to your API resulted in lawsuits because you were a monopolist, using your position as the platform owner to bully your competition into obliteration.

Nowadays the situation is completely different. Having an API means having a future. Nowadays to survive as a business you need to have a platform, which in turn means you need to have an API. Unless you have an API, one that suits the needs of 3rd parties and that is easy to use, you're doomed. You'll be just an Application Vendor, and toast before you can say "I wish I had built a platform". An excellent book on the topic is "The Age of the Platform" by Phil Simon.

As you can read in my previous post, API's are the hardest thing to develop. It always helps to have some guidance when you're up for a difficult task, and often principles help you getting this guidance. There're quite a few other guidelines out there on the interweb that are more than helpful. Below are 5 principles of the API-First paradigm. Followed by 5 derived principles and at the end of the post, I'm listing a couple of more than interesting resources on API design.

One final note before I go into the principles. An API is not much more than an interface into the depths of your platform. It discloses your platform and makes it possible for others to leverage it for their needs. It is therefore critical to have comprehensive documentation for your API. Now comprehensive doesn't mean that you need a big fat document describing everything you can think of that might be remotely related to your API. Typically you will need to document the technical interface of the API, i.e. the call signature of the API, including the input and output parameters of the API.

In addition you will want to document it's behavior exhaustively, i.e. only develop the behavior your documentation mentions. It makes perfect sense to use BDD (Behavior Driven Development, see my post on the topic) for this purpose. By doing so, your users know exactly what to expect from the API and it allows them to create stubs that behave the same as your API without the need to have access to your API's implementation. Finally it helps to have a simple example on how to use the API without making any assumptions as to why one would use the API. This could be through showing the relevant cURL statements.

Enjoy your reading…

Principles of the API-First paradigm

The API is the product.

It is owned by a product owner, and the responsibility of a product team. A team is responsible for it, from cradle to grave. This team is responsible for managing and ensuring its proper operation. Don't consider an API as part of another product, something that's a by-product, because it means that you won't treat it with the proper dignity and soon you'll find yourself alienating from your users.

The API makes no assumptions about its Consumers.

It is robust and resilient enough to thwart of any consumer with bad intentions as well as ignorant ones that have no clue about what they're doing. All this without compromising the service level to all well intending consumers. Mind that in most cases you're working on an API while making assumption as to who and why they'll use your API, only to find yourself in a situation where your users are all but the ones you envisioned, and all using your API for completely different reasons than why the API was created in the first place.

The API is suiting the needs of the Consumer

The API is developed only when there is at least one consumer and it is tailored to suit this consumer, by this the API is creating business value through its consumer. Don't be so arrogant to develop something that's supposed to be an API without having at least one consumer lined up to actually use it and tell you how great it is. Apart from the fact that working on something that is not being used is a complete waste of time, it also means that you're not really understanding the fact that you should not make any assumptions about the API's consumers. No assumptions at all.

The API is built to last

An API is never breaking compatibility with its consumers, although it may rely on the paradigm of 'Ignore what is unknown' to allow for extending the result. API's, other than the humans that build them, never break a contract. Period! This is to say that they will respect contracts, will have addendums to the existing contract, or in those cases when the API, which is after all a product, is no longer adding value, they will void the contract, but obviously respecting the contractual notice period. On a side note, it is fair to assume that its consumers abide by the convention that they'll ignore what they don't understand or know, hence the fact that you can add addendums to existing contracts without actually breaking the contract.

The API is idempotent.

At all times, in any situation, always. It doesn't matter what you do, how you do it or when you do it, when you call an API it always behaves exactly the same. Meaning that its result is always the same and therefore perfectly predictable. The order in which API's are called doesn't matter, as long as you put in the same values, you will get the same results.

Architecture principles for the API

The API is clear in its error reporting

Errors are either caused by the API implementation, the API consumer or something unexpected. It makes perfect sense to stick with the conventions of HTTP errors, why invent something new, when the existing is fitting your purposes perfectly. But whatever you do, make a clear distinction between these three causes for errors.

The API is always managed.

An API can be managed independently from;
Technical level, i.e. it can be accessed securely and consistently throughout its lifespan -> Scalability, Availability, etc

Application level, i.e. consumers can use the API based on a published interface that is behaving per this interface -> Interfaces, authentication/authorization, etc.

Functional level, i.e. users of the consumer can be provided access to the API based on the agreements made -> Throttling, metering, monitoring and reporting, etc.

The API can be implemented independently of its interface;

They are truly decoupled. Multiple implementations can co-exist and determining which implementation to choose for each individual call can be context driven. Mind that the interface should be technology agnostic, or at least as much as possible, and in no way should the interface disclose anything about the implementation other than that it should explain how it behaves.

The API is technology agnostic.

The interface can be called by a consumer of any technology without any assumptions of the technology used in the API implementation, and vice versa. This is pretty much an extension of the previous principle, but important enough to mention explicitly.

API's are like dogfood.

The API is used by the team responsible for it in the same use cases as the consumers for which the API was intended; "Eat your own dogfood" paradigm. Always make sure that in case you need functionality that one of your API's is providing, you're calling that API yourself and making yourself dependent on the API. Only this way you understand your API, and more importantly you'll be very cautious about how you treat your API and therefore how you treat its users. After all, you'll be one of them.

Interesting Reading

• Google's API design guidelines
• 18F API guidelines
• W3C Web API Design Cookbook
• CISCO API design guidelines
• Haufe API style guide
• Heroku API guidelines
• Paypal API guidelines

Thanks once again for reading my blog. Please don't be reluctant to Tweet about it, put a link on Facebook or recommend this blog to your network on LinkedIn. Heck, send the link of my blog to all your Whatsapp friends and everybody in your contactlist.But if you really want to show your appreciation, drop a comment with your opinion on the topic, your experiences or anything else that is relevant.

Arc-E-Tect