What is your next step in Continuous Delivery? Part 1

Continuous Delivery helps you deliver software faster, with better quality and at lower cost. Who doesn’t want to delivery software faster, better and cheaper? I certainly want that!

No matter how good you are at Continuous Delivery, you can always do one step better. Even if you are as good as Google or Facebook, you can still do one step better. Myself included, I can do one step better.

But also if you are just getting started with Continuous Delivery, there is a feasible step to take you forward.

In this series, I describe a plan that helps you determine where you are right now and what your next step should be. To be complete, I’ll start at the very beginning. I expect most of you have passed the first steps already.

The steps you already took

This is the first part in the series: What is your next step in Continuous Delivery? I’ll start with three steps combined in a single post. This is because the great majority of you has gone through these steps already.

Read more →

Create the smallest possible Docker container

When you are playing around with Docker, you quickly notice that you are downloading large numbers of megabytes as you use preconfigured containers. A simple Ubuntu container easily exceeds 200MB and as software is installed on top of it, the size increases. In some use cases, you do not need everything that comes with Ubuntu. For example, if you want to run a simple web server, written in Go, there is no need for any tool around that at all.

I have been searching for the smallest possible container to start with and found this one:

Read more →

Big Fat WAR Files Hurt Continuous Delivery

Last May, I spoke at JavaOne India on Continuous Delivery. The title of my presentation was: “A Diet for Your Big Fat WAR File”. Large WAR files slow down the delivery process of software. If you want to achieve continuous delivery and improve your time to market, you need to make your deliverables nimble. In this video interview, I summarize the main points from my presentation and explain how big fat WAR files hurt Continuouw Delivery.

This post is part of a series on Continuous Delivery. Please see our tag Continuous Delivery for more posts on this subject. Or check our Continuous Delivery website to learn how Xebia’s consultants can help you improve your time to market, reduce costs and improve quality using Continuous Delivery best practices.

“You cannot change anything without starting a project”

You can’t change an IT system without investing in time, money and resources. If your change exceeds the maintenance budget of the system, most companies require you to start a project to raise the necessary funds. In a typical company, project budgets are allocated on a year by year basis. This means that on average, it will take you six months before you can start on your change. And then we did not even mention the politics of competing projects and the bureaucracy of getting your project defined, approved and started.

The continuous nature of product development conflicts with the limited lifetime of a project

The nature of a project is that it has a clear deliverable and an end date.  After the end date, the project is completed and its team disbanded.  However, a system requires continuous improvement in order to provide a competitive advantage to the company.  There is a mismatch between the two concepts: projects have a discrete nature, while improvement requires a continuous approach.

Read more →

Conference Report: Plot Visits XebiCon 2013

Tuesday June 4th, Xebia organized the XebiCon event in Fort Voordorp in The Netherlands.  One of our visitors, Dirk Louwers, wrote a conference report which nicely summarizes the day. Dirk Louwers works as CTO for a company called Plot. XebiCon consisted of two keynotes and 15 sessions divided over five parallel tracks. Dirk Louwers reports on both keynotes and three of the parallel sessions.

You can read Dirk Louwer’s report at Plot Visits XebiCon

Thanks to Dirk Louwers for publishing this article!

Series: How to Kill the Architecture Department? Part 6

Part 6: The Senior Operations Engineer

Architectural activities tend to focus on the initiation and design phase of a project. In the previous post, we already pointed out the importance of architectural thinking during the development of software. In classic organizations, there is relatively little attention for the operations department. The architecture of infrastructure is essential for the success of software.

The only valuable software is software in production. This means that for software to be valuable, you should focus on getting it in production as quickly as possible. Many agile practices help in speeding up the development part. But if you limit yourself to these agile practices, you may still hit a wall when you want to deploy your software on the live systems.
Read more →

How to Kill the Architecture Department Part 4

Part 4: The Chief Technical Product Owner

In part 3 of this series, Herbert introduced the role of Technical Product owner as a counter part of the (Functional) Product Owner. Before Product Owners and Technical Product Owners can start their work, high-level priorities need to be set by upper management. In this post the Chief Technical Product Owner is introduced. He represents the technical perspective in this high-level prioritization phase.

Getting Things Prioritized

In a typical company, there are many requests for new functionality. Usually, the number of requests exceeds the realization capacity by far. Therefore, early on in the process, choices have to be made. Functionality can be picked up in the order of priority. And priority is a result of expected business value, relative cost and feasibility.

Early on in the process, it is difficult to estimate the effort to realize it. Usually, at that stage a functional request has not been analyzed, detailed or scoped strictly. Providing a low estimate gives the business owner a blank check to later on design the user story in such a way that it is more expensive to build than initially estimated. They can refer to the initial low estimate when IT says “no”.

Providing a high estimate may block the feature from ever getting picked up. The business owner may look for external parties to realize the functionality without involving IT. As a result, there are even worse architectural incompatibilities.

In the agile organization model sketched in the first post, there is a phase designated for prioritization of features. For a large part, prioritization is done by business managers. Many business managers have no idea of technology. They cannot estimate the technical size of a story.

Some functional requirements depend on larger technical changes. For people with a technical background, it seems difficult to explain the value of such technical changes to business managers. Especially when talking to upper management. This is where the Chief Technical Product Owner (CTPO) comes into play.

The Chief Technical Product Owner

The Chief Technical Product Owner is a specialized Technical Product Owner who distinguishes himself from the others with political sensitivity and the ability to communicate and negotiate with upper management. He helps the business decide which functionalities should be picked up in what order and how to improve the non-functional qualities of the system.

In an ideal world, stories should be prioritized strictly on business value. In the real world there are practical and technical hurdles to overcome like legacy systems and technical debt. Sometimes, in order to pick up a set of user stories, in an effective way, a technical change needs to be made first.

The Chief Technical Product Owner distinguishes himself from the Technical Product Owner by being more focused on the management. The Technical Product Owner is more focused on the team.

On the other hand, the Chief Technical Product Owner needs to have an understanding of technology in the Ready, Done and Production phase. For example, when the system operators are haunted by production issues, the CTPO should convince upper management to take actions that provide a structural solution on the long run rather than loading the teams with large piles of new functionality to build.

To do this, the CTPO is a high profile function. If you draw a comparison with traditional IT organization, the manager of the architecture department may be best capable of fulfilling this position. If no manager is available for this position, you could consider one of your enterprise architects to fulfill the role of CTPO. Make sure that upper management trusts this person and that he is sensitive to the technological challenges in the IT organization.

What is next?

With the roles of CTPO and TPO, the prioritization and specification phases of a user story’s lifecycle are well-managed. In terms of classic architects, the architecture manager / enterprise architect and information architect are replaced with more agile roles. The next post will discuss the architectural responsibilities of the Senior Software Engineer in an agile organization.

Stay tuned!

Series: How to Kill the Architecture Department? Part 1

Part 1: The Employee Formerly Known As Architect

Every system has an architecture, but it is not necessarily designed by an architect. This post sketches a reference model for agile organizations without the role of Architect. Next posts in this series will provide best practices on how to improve architecture within this architect-less agile reference model.

Classic IT Architects do not fit in agile organizations

Agile organizations seem hostile environments to classic architects. The DONE-teams are encouraged to Do The Simplest Thing That Could Possibly Work (DTSTTCPW) and avoid Big Design Up Front (BDUF). In addition, teams are encouraged to be self-organizing and make their own decisions.

With a classic architectural mind frame, it is easy to feel left out in an agile organization. If you keep writing Project Start Architecture documents, it seems like the documents are never read. Or worse: you never get the chance to write the document properly, because the DONE-team has already started developing.

Architecture remains important

This blog post is the start of a series introducing best practices for architecture in an agile organization. In this new organization, there is a good chance that nobody has the title Architect anymore. Yet, the architecture of the system remains of vital importance to your long-term success.

The process for creating and maintaining architecture in an agile organization is different! Architecture becomes a team responsibility. So how can you make sure the teams make the right decisions?

Introducing an agile organization model

This first post introduces a reference model of a typical agile organization. The following parts in this series will build on this reference model to introduce the technical roles in all phases of the software lifecycle.

Getting it DONE

Agile is a container term for a number of processes: SCRUM, eXtreme Programming, RUP, DSDM and possibly others. The most popular agile process is SCRUM. This series assumes a SCRUM process extended with principles and practices from the eXtreme Programming community.

Figure 1 provides an overview of the SCRUM process. In the To Do column, there is a backlog with User Stories that are iteratively implemented into Potentially Shippable Software (DONE) in 2-3 weeks sprints. During sprints, there are daily standup meetings facilitating team communication on progress and impediments.

SCRUM is a lightweight process. It provides a helpful structure, mind set and best practices for a single development team. However, it does not help you on how to create user stories, manage architecture and scale over multiple teams. It also does not tell you how to bake a cheese omelet, for that matter.

In a larger organization, you probably need user stories, architecture and multiple teams. And probably, at some point you need cheese omelets too. So, rather than switching to a heavyweight process that covers all of these, you should extend SCRUM with additional processes and best practices for the challenges at hand.

You can choose the additions that fit with your organization.

Getting it READY

In order to write user stories before a sprint starts, you can introduce iterations preceding the SCRUM sprints to get stories READY. Figure 2 illustrates the model of an agile organization and how the READY team relates to the DONE team.

In a READY team, product owners cooperate with stakeholders, analysts and consultants in order to write specific user stories for the next sprint.

A product owner may serve multiple DONE-teams. However, in a larger organization, there may also be multiple READY-teams. For good communication, it is important to communicate over teams. A Scrum of Scrums is one of the solutions to facilitate this kind of communication.

Getting it PRIORITIZED

It takes time to write good user stories. If the READY team is unable to deliver stories before the next sprint, a DONE-team cannot start developing on time. How do you know which stories to write first? For this, you need to have a good understanding of priorities.

Priorities depend on your company goals. In most companies, the demand for new software features is larger than the capacity of people to realize the software. So, choices need to be made.

The reference agile organization model recognizes a Chief Product Owner who decides the priorities of new initiatives before user stories are written.

In order to decide on priorities, even before writing the final user stories, you need high-level analysis and communication. For this purpose, there is a Getting it PRIORITIZED phase.

Getting it in PRODUCTION

The only valuable software is software in production. Traditionally, SCRUM aims to deliver Potentially Shippable Software. In the ideal case, the DONE team goes one step further. The definition of done should be: DONE = LIVE.

At some point, there is a transition of software from development into production. And in production, software needs to be maintained.

In an agile organization, the transition needs to be as smooth as possible. And transitions need to be made as often as possible because the more often you do it, the easier it gets. Best practices to support this are described in the Getting it in PRODUCTION phase.

So, where is the architect?

Over the four phases, you have met product owners, chief product owners, developers and operators. But none of the phases bothered to mention an architect. So, where is the architect?

Remember the introduction of this blog post? It said: “In this new organization, there is a good chance that nobody has the title Architect anymore.” The good news is that the introduction also said: “Every system has an architecture, but it is not necessarily designed by an architect.”

Stay tuned for the next episode of How to Kill the Architecture Department

The next posts will explain the new roles for The Employee Formerly Known As Architect in the agile organization. Each phase has its own architectural role. Below is a sneak preview of one of the new roles. Keep reading following parts of this series and find out what the other roles are.

What are the responsibilities of a Technical Product Owner? And how do these compare to the responsibilities of an Architect in a classic organization? Please share your opinion by commenting below!

To be continued in two weeks!