In every organization, one of the goals that they would want to achieve is to provide the needs of their customers in an instant. With this, they have been using a software engineering approach that makes it easier and quicker for them to make their goals be reached. The approach that is now being used by almost all organizations is Continuous Delivery. This approach is now being used because even the companies who are not great in making software can make it because it allows the organizations to make their own software, which they can depend on anytime.

With CD, there are a lot of advantages that organizations can get. When they make use of CD, the delivery times will be made quicker. Not only is that the cycles will be in short release unlike when not using a continuous delivery, the releases will be large and monolithic. In addition, CD lets you make your products have high quality and your production failures will be lesser. Moreover, not using CD will keep you in a high risk which is why, when you utilize it, you will be able to experience risks that are adequate. With CD, everything is made easy and efficient.

Tools to do it

With continuous delivery, you will be able to encounter tools that help the approach to be more effective at the same time useful. Here are the tools that you must get familiar with when you make use of continuous delivery.

1. NuGet – This tool is used in CD because it offers a dependency management for the applications that you have. In addition, when you make use of this tool, it will give you benefits because it has a package manager that will help you in the development of your project or product. Apart from that, the tool is free to use.
2. ProGet -This tool for CD hosts the releasable packages that you have. In addition, with this tool, you will be able to have a package source, which your team can access.
3. Go – This tool is kept and written by people of ThoughtWorks who are responsible for the book about Continuous Delivery. This tool can perform both the CD and the CI, which is the continuous integration.

Risks and Pitfalls

No matter how beneficial CD and its tools, it still gives dangers and pitfalls that everyone should be aware of. Here are the risks and pitfalls that organizations may face once they use continuous delivery.

• Building a CD when the CI is unstable is a pitfall. Before an organization makes use continuous delivery, it will first fall in continuous integration which is why it must have a firm foundation in order for it does not cause any risk or failure.
• Continuous delivery and continuous deployment are different even though they may be alike in some terms.
• Trying to change to CD even without any infrastructure that supports it

• Obstacles when implementing the approach to CD
• The approach may be useful but there are problems that hinder it from being applied. Here are the obstacles that the approach faces.

• When the applications are enormous and colossal
• Less automation is also an obstacle that CD faces
• When the setting is inadequate

With continuous delivery, it is best to know the tools that are best to use in order to avoid it from getting into risks and pitfalls.

— Slimane Zouggari

Every company would want to make their businesses be on the top of their game and make them successful. However, the path to success is not easy.  There will be many risks, which can bring them to either achieving it or lead to failure. Hence, when this kind of situation happens, the only solution is to have a continuous delivery, which has been helping big organizations for them to be inventive, responsive and lean.

History

Continuous Delivery or CD as being referred is known as an idea that was given a description in a book that was published in 2010. The book was co-authored by Jez Humble and David Farley, which are both ThoughWorkers. Continuous delivery is used as a language about that is utilized when it comes to the software builds and when an examination or placement activities occurs in the production of the software. CD is being used until today by huge organizations in order to for them to take control their customers when the software is in its continuing cycle.

What is it?

Continuous Delivery or CD is software with engineering approach, which allows individuals to create software in cycles specifically the short ones that will guarantee that the software is trusted once it is launched. Continuous Delivery allows individuals to alter such types as new features, bug fixes, experiments in a safe and abrupt process.

Why doing it?

With CD, there are a lot of benefits that an individual once he or she makes use of it. Continuous delivery avoids the organizations to be out of high risks. With this, the software engineering approach will enable the software to be deployed in low-risk and effortless which can ben demandingly done anytime. In addition, with CD, organizations can quickly market their software to their clients that also keep them more advanced with regards to competition.

In addition, continuous delivery lets the organizations be able to get the feedback of the customers in a faster way since with their regular releases, they were able to gather all the feedbacks of the customers that they will deliver to the application development teams. Moreover, the approach allows the organizations develop the quality of their product because it fixes the bugs found in the product and not only that, it helps them reach the satisfaction level that their customers want and improve it.

For organizations who want to know how they can improve their products, continuous delivery is the solution because it helps them to get the feedbacks from their customers in an instant. The feedbacks become the basis when it comes to developing the product. With the help of CD, the organizations will be able to know how they easily fix the issues and make it even workable for their clients. The approach will be the key for the companies in order for them to make changes to the software that they have released which allow them to make the software and product have a higher quality.

— Slimane Zouggari

Feature team is not new anymore; have been around in huge products such as within Microsoft (compiler development) and Ericsson (telecom systems) and always emerged together along with the daily builds. It only became popular upon the advent and introduction of the agile development, as the team focus more on the end-customer requirements as well as shorter cycle times.

What is Feature Team?

A feature team is best defined as cross-component, cross-functional, and long-lived team that completes numerous end-to-end customer features individually. They have the essential knowledge as well as skills to complete the end-to-end features that are customer centric and play an essential role in scaling up an agile development. They generally stay and work together throughout the years and implement numerous features. Without this type of team structure, an organization is more likely to make countless sub-optimizations as well as waste that can lead to sequential development cycle.

Why and when doing it

There are countless reasons for adopting the feature team, but organizations should be cautious of the drawbacks that can be encountered along the way.

Advantages / Disadvantages

The advantage that the feature team brings is that it exploits the speed benefits from a specialization provided that requirements map to the expertise or skills of the team. In case the requirements failed to map to the team skill, learning will be ‘forced’ to acquire or learn the needed skill and knowledge. At large, feature team balance flexibility and specialization.

The drawback is, the efficiency of the entire team will be compromised if one of the members failed to understand the whole system. Not the individual members but the team itself as a whole should to learn the skills to effectively implement the whole customer-centric features. The skills include functional skills such as interaction design, test or programming, and the component knowledge.

Component vs. Feature Team

Feature team differs from component team in various ways. Primarily, the feature team is optimized for providing full customer value and is more focused on system productivity and high-value features while its counterpart is optimized for providing the complete number of code’s lines and is more focused on increasing individual productivity through implementing the lower-value ‘easy’ features. Other differences include the following:

Feature Team:

• Responsible for the whole customer-centric feature
• Increases flexibility through minimizing dependencies between the teams
• Avoids the Conway’s law
• Focus on numerous different specializations
• Responsibilities are shared within the team
• Exploits flexibility; broad and constant learning
• Requires adept engineering practices
• Provides motivation in order to make code maintenance and testing easier

Component Team:

• Responsible for a part of the customer centric feature
• Requires additional planning due to dependencies between the teams
• adhere to the Conway’s law
• focus on a single specialization
• designate responsibility to each member of the team
• exploits the existing expertise; less likely to work on learning new and additional skills
• uses slack engineering practices
• does not believes that motivation leads to an easier way of maintaining and testing code

Which is better between the two? Well, the answer depends on the perspective. If seen from the organizational-flexibility and value-delivered perspective, a feature team is ideal. However, flexibility and value are not the only criterion for the organizational design. Considering this, majority of organizations then tend to end up embracing a hybrid models. Yet, organizations should be cautious with this, as it brings drawbacks that can cause headaches and pain.

— Slimane Zouggari

Comprehending the definition and nature of cost of delay is of paramount importance when developing improved or new products. Learn the basics of cost of delay through reading further:

The Cost of Delay – What is it?

The Cost of Delay (CoD) refers to a means of communicating the effects of time on the anticipated results. It combines value and urgency, which most people find it difficult to distinguish between.  Oftentimes, people tend to focus more on value while overlooking the importance of urgency but in reality, these two things should be given the same importance. The value that can be missed out when something is delivered “late” can be massive.

In simple terms, the Cost of Delay helps people understand and know how time affects the value of something.

Value & Urgency

Having a clear understanding of what cost of delay means generally helps and likely ensures that an organization makes a better decision. It is important that an organization will not only understand and determine the value of something they are working on but also learn how its acquired value diminishes over time.

In general, CoD helps organizations, specifically when developing improved or new products as well as services in three primary ways:

• Decision-making – this was already mentioned above. Whether it is all about controlling the queues length, experimenting with the WIP limits, optimizing the batch sizes in several different points, the Cost of Delay is a piece of information that will be of paramount importance.
• Altering the focus – change the focus from cost and efficiency to value and speed so whatever the organization wants can be likely achieved and those unwanted things will be less likely to be encountered.
• Prioritization – through using the CD3 or the CoD Divided by the Duration, organizations can deliver total value (CD3 is also referred as weighting the WSJF (Weighted-Shortest-Job-First) through calculating the job size and CoD) through Organization should recognize the limits of what can be done and developed, hence taking control over the demand will be important at some point. Organizations should be able to determine where to begin, in what order should things be done, and when to stop and then move into something with more value and is urgent.

Prioritization, hence, should be updated on a constant basis to guarantee that the value delivers the best possible economic result for an organization or a business. CoD, at large plays a huge role in ensuring that not only SAFe or the constant flow model that is typically applied in situations wherein the ARTs or Agile Release Trains are engaged in constant and on-going development helps in eliminating delays and in keeping the system lean.  It also ensures that the business knows what will work and what will not.

Quantifying the Cost of Delay provides a plethora of benefits. However, dealing with this may be a bit overwhelming for some individuals. For those who want to be more familiar about CoD but have not muster the courage to face the fear related with numbers yet, then learning the qualitative assessment will be a good place to start.

— Slimane Zouggari

If you’re looking for the best alternative to create a better backlog that will surely help you explain your system, plan and rank your releases, story mapping is such a perfect option.

What is it?

Story mapping is a practice designed to provide a more organized approach to release planning. Also called User Story Mapping, it covers ordering user stories together with two independent proportions. The map organizes user activities alongside horizontal axis in coarse order of priority. While down the perpendicular axis, it shows rising sophistication of the application.

Story mapping organizes user stories in a valuable model to detect omissions and holes in backlog, understand system functionality and efficiently plan all-inclusive releases that provide value both to businesses and users with every release.

Why doing it?

Using story mapping has many beneficial returns that you and your business will surely benefit in the long run. Some of these expected benefits are:

• Split large requirements in small parts

Story maps will allow you to become brief when it comes to requirement description mainly because you can organize requirements in groups and deliver in small releases.

• Defers the less significant requirements to another release

It will now be easier for you to defer less significant requirements to a potential release since the requirements are distinct in smaller increments. Unlike a partial product with tough whistles and bells, your project team is more likely to achieve greater success at supplying a particular product your customer critically needs.

• Visualize the system or product roadmap

When you handed your customer a spreadsheet or document inventory with numerous page requirements, he will probably start skimming the document and miss an essential requirement that he would be held responsible to in the development period. But when you use story mapping, the focus is simply smaller and your client can visually understand the requirements delivered during the first, second or subsequent releases.

• Improve customer relationship

In terms of communication to customers, story map is an excellent tool. Your customer will clearly understand the type of functionality that will be delivered with every release, since all requirements are associated to specific process releases and steps.

What’s more, story map can be easily converted into agile project management tools such as Mingle as your product backlog.

How to do it?

The structure of your story map should be Goals > Activities > Tasks > Stories.

Group your stories by theme/application/functionality and make the grid. For instance, you can find the title for every group functionality in a horizontal way, and the main issues or stories connected to every group in a vertical way. Prioritize the functionalities from more important (left) to less important (right). Then, every group will have the stories ordered again vertically. As soon as the stories are ranked, you can now begin the surgical operation – slice the list.

Difficult as it may seem, but when you try practicing and doing it on your own, multiple benefits can be gained. Later on, you will find that story mapping is even easier than dealing with a list of stories.

— Slimane Zouggari

Estimating your project for software development is difficult. These days, lots of companies are shifting to relative estimation because it helps provide the capability of quickly assessing how long it will take to complete a project and about how much it would cost.

Relative estimation is among the few distinct flavors of estimation, which is used in Agile teams. It is consist of estimating user stories and tasks in ultimate periods of time but by grouping or comparison of items with the same difficulty.

Why Relative Estimation

There are many benefits provided by relative estimation

• It is more accurate: It may be an accurate method to plan every spirit when it comes to the money or time, which you need to be able to complete your task. However, if you run even slightly behind the schedule, your whole project’s scope may get thrown off, which is called the cone of uncertainty. When you groom the backlog, you are developing and resizing fast estimates of effort in an Agile way.
• It is fast: Relative estimation does not aim to come up with an exact level of effort when there are lots of uncertainty and there is a limited time. On the other hand, it aims to quickly get an estimation of the level of effort, and you will be able to do it much quicker as compared to what you can when you are using a traditional estimating approach.
• It is project-specific: It is almost not possible to predict an exact amount of hours for any given story. This is for the reason that hours are relative numbers. When you generalize to several significant numbers, you are allowing yourself to get more accurate velocity, which is tied to your particular project at hand.
• Getting better and better through time: Through time, you may look at how many points are getting completed by your team within a sprint, and thus, becoming much better at relative estimation. It will be a great help in gauging your development team’s as time passes by, identifying the usual capacity of your sprint, and serving as a good tool to predict the future estimates.

Difference of relative estimation over the traditional estimation

Traditional approaches require great efforts for gathering information, which result in pages of complicated documentation, as well as a project plan that has estimated dollars and hours. Given the rising popularity of this methodologies and the customer’s growing focus to save money and time, it is advocated that you build a high level of feature list and using relative estimation for a more precise estimate costs and level of effort.

You need to keep in mind that software estimation is difficult, and development has been burdened with many levels of uncertainties and complexities. You cannot perfectly estimate the span of a certain feature to be done. However, with relative estimation, you are offered with many benefits through an elegant and simple development process.

— Slimane Zouggari

The rapid development of technology enables us to complete our day-to-day tasks easily and conveniently. Among them is pair programming, which has been capturing the interest of many people, specifically businesses to improve ideas and address potential problems.

What is it?

Originated from Extreme Programming (XP), pair programming is an excellent agile technique where two developers collaborate and work in a single computer. These two developers or programmers are composed of driver (writes code) and navigator or observer (reviews all code lines as it is keyed in). Often, these programmers shift roles.

The idea is to split responsibility between the navigator and driver to maintain a stable development flow, have better structure, and avoid bugs while sharing more knowledge through the team. Though pair programming is challenging to implement since it is a big change, intense, exhausting and entails soft skills that most of the team could have not completely developed, it possesses lots of benefits that can help a business attain success that it critically needs.

Why doing it?

Over the last few years, pair programming had benefited lots of users across the world. In spite of the demands it requires, one must try what it can offer. The pay-offs you can get include:

• Greater team solidity – You are now bound to know your team better after spending full periods of time working with them. Thus, team solidity increases.
• More satisfaction of job – Mostly, programmers learn that it’s a release to share the encumbrance of code writing with a coworker. They can help each other. Meaning to say, they don’t need to beat heavy time only to finish the job on their own.
• Save time – The actual development can be quite slower of faster. With a higher quality, you and your team can save more time in refactoring code and error fixing.
• Safer and better code – Because two brains are focusing on the code, failures and errors can be minimized. At the same time, you are able to discuss various solutions and structures you wouldn’t produce alone.
• Happier team – Some think it is more satisfied and fun working with the environment by yourself. Not unless you try pair programming because it can also be your great time to make new set of friends especially with those you usually don’t spend time with.
• Higher focus – Since you’ve to team up, you’ll potentially focus more on other important tasks. A constant dialogue helps you to keep focused as well.

How to do it?

In order to have a successful pair programming, keep these important tips in mind:

1. Before sitting down, plan a reasonably definite task
2. Agree on one small goal at a time
3. Depend on your partner and show your support
4. Talk a lot. Don’t hesitate to say anything, ask for application ideas, highlight possible inputs that the code does not cover, propose clearer names for subroutines and variables, etc.
5. Sync up regularly
6. Take a time to celebrate as you finish the jobs and overcome problems
7. At least for every half hour, shift roles often

— Slimane Zouggari