Tuesday, April 25, 2017

The reverse triple constraints of troubled projects

Project Management Reversed Triple Constraint Triangle
Assuming you suspect or know that one of your projects is in trouble the first step is always an extensive project review. After such a review you hopefully have the necessary information for decision-making as well as the team’s support for the recovery of the project.

It may be highly unlikely that the original requirements can still be met without some serious tradeoffs. You must now work with the team and determine the tradeoff options that you will present to the stakeholders. When the project first began, the triple constraints most likely looked like what you see in the figure below.

Project Management Triple Constraint Triangle

Time, cost and scope were the primary constraints and tradeoffs would have been made on the secondary constraints of quality, risk, value and image/reputation. When a project becomes distressed, stakeholders know that the original budget and schedule may no longer be valid. The project may take longer and may cost significantly more money than originally thought. As such, the primary concerns for the stakeholders as to whether or not to support the project further may change to value, quality and image/reputation as shown in the figure below.

Project Management Reversed Triple Constraint Triangle

This happens almost every time I join a troubled project. After focussing on these the project actually runs a lot smoother and high-value outcomes are prioritized and supported. So the big question is why don't we start projects with the reversed constraint triangle? Why put our image and reputation on the line by letting it come that far? Why work on things that obviously do not have such a high value because when it comes hard on hard they are not needed? Why make the quality first a priority when we already feel the pain of bad quality?

The funny thing is that agile methods like Scrum try to do exactly this. Focus on value and quality. This automatically helps your image/reputation. When the time in a Scrum project is fixed this automatically means that cost is fixed as well, but your scope is flexible. In other words, only the most valuable things are done in a good quality.  When the scope is fixed, your time and costs are flexible. Still, the team will start working on the most valuable things first and you can stop the project at any time, and have valuable results. No high-risk big bangs, valuable results are delivered every sprint.

The reason I say that agile methods try to do this, and not actually do this, is because they are hindered in most organizations. The acceptance and adoption of new ways of budgeting and planning for projects lay way behind of the acceptance and adoption of using agile methods in projects. And those agile projects are suffering because of it.

Read more…

Sunday, April 23, 2017

Our public workshops in Q3 2017

Agile Project Management Workshops
Data Solutions offers public workshops on various topics around Agile Project Management. Come and find the right workshop for you or contact us for an individual training recommendation.

We have currently fixed the following public workshop dates for Q3 this year:

 Workshop  Date  Location  Price
 Agile Budgets and Contracts  Thursday,
 July 6, 2017
 Zurich  CHF 990
 Scaling Scrum in an Enterprise Environment  Thursday,
 July 13, 2017
 Zurich  CHF 990
 Agile Budgets and Contracts  Thursday,
 September 14, 2017
 Zurich  CHF 990
 Scaling Scrum in an Enterprise Environment  Thursday,
 September 21, 2017
 Zurich  CHF 990


Sign up now for our workshops.


Read more…

Wednesday, April 19, 2017

8 Signs of a troubled project

When you’re dealing with a troubled project, there are usually a number of red flags surrounding you. This article is written from the perspective of a senior manager (for instance, members of the Steering Committee).

All of us have endured troubled projects that didn’t accomplish their intended business goals. Such watermelon projects, which come across as green on our project dashboards but are, in fact, red, upon closer inspection, are very typical in a company’s project portfolio.

Generally, during the failure of a project, the last people to find out are those in senior management. However, at some point, failure becomes readily apparent. When the scenario gets to that point, you might not have any other choice but to start everything over from scratch. What separates failure from success is isolating the red flags of a troublesome project early. Here’s a brief synopsis of early signs to look out for in order to prevent a disaster.

1. Always Green Lights, Minimal Activity.
Most of us are known with labeling a project as green when they are budgeted and scheduled; yellow when the project is under the gun, and red when the project is late and over budget. Maybe your primary project has been reporting green for a while, but strangely, there’s been minimal activity associated with it. That’s a strong indication of the project being in dire straits.

2. Many TBD’s (To Be Determined).
Proper issue and risk management is vital for a project to be successful, but is typically neglected. If your primary project has surpassed the early stages, yet marking plenty of TBD’s in the “resolution” column for issues and risk, then it’s more than likely facing a series of problems, regardless of whether a schedule discloses it.

3. Avoiders.
The charge leader in your primary project might be a business line manager or a formal project manager. No matter who they are, your gut is telling you that they’re avoiding you intentionally. Maybe they’re not seen in meetings, they walk the other way when they see you coming, they don’t pick up their phones, or aren’t sending you status updates. Chances are you’re being avoided because the project is in trouble.

4. Problematic Trends.
An up-to-date Product Backlog tells you exactly what has been accomplished for what money in what time. Or methods like EVM (Earned Value Management) to identify the progression of a project could be used. They contrast real results by what was intended, expenses incurred, and time allocated. While your projects might not use these methods, you can catch substantial drops or increases in expenditures, large modifications to work being sent, or immediate alterations to a timetable without new dates. Pay close attention when this is the case.

5. Non-Progress Reports.
You’re smart, so you have consulted your project manager about offering weekly status reports. That said, those reports don’t show any sign of progression, ironically. More specifically, if you’ve obtained a couple of weekly status reports without chronicled progression, chances are your project is either in trouble, or about to be.

6. Failure to Display Physical Results.
During the timeline of your project, you request a demonstration or assessment of finished work so far (Sprint Reviews for example). However, the meeting for such reviews is regularly postponed and rescheduled, perhaps by days or even weeks. Further, you’ve made a spontaneous visit to the project leader, but instead receiving a demonstration of work done you are getting documents, PowerPoint presentations and a lot of hot air talk. If this is the case, you probably have a troubled project on your hands.

7. Lack of Communication.
Poor engagement, whether it’s informal and formal, is a red flag. If the stakeholders, including users and group members, aren’t interacting with one other, guess what? You’re facing trouble.

8. Instinct.
You are mindful of what projects are high-risk. When your primary project is mentioned, you know something is up, even if you can’t pinpoint what. By trusting your instincts, you’re inclined to discover something noteworthy.

Be mindful that these red flags are just signs, and nothing more. They don’t suggest failure of a project, or that people have failed. Each project endures its highs and lows, and you simply have to account for them. The red flags might suggest that a project is in need of proper attention from executive management.

Managers are encouraged to do nothing more than observe closely for a couple of weeks before taking action. A detailed project review is required when no tangible improvements have been realized in this period.

Read more…

Friday, April 14, 2017

LeSS and Scrum Alliance against SAFe?

So last week the Scrum Alliance announced a partnership with LeSS. How this partnership is going to look like was not part of the announcement so we will have to wait for this. But I think it was a smart move for both the Scrum Alliance and the LeSS company. Too late, but smart never the less. A few random observations from my side:

Scaling

- Scaling Agile / Scrum is becoming a more and more important argument for certification companies.

- Scrum.org (Ken Schwaber) created it's own scaling framework Nexus. See my Nexus review.

- SAFe is only about scaling agile. See my SAFe review.

- LeSS is only about scaling Scrum. Hence a good add-on for the Scrum Alliance since it is about Scrum only, and no other agile methods. See my LeSS review.

- Scrum Inc (Jeff Sutherland) created its own modular scaling approach Scrum at Scale. See my Scrum at Scale review.

- Scrum Alliance had no answer to the scaling question. This would be solved now.

Selling

- SAFe is selling very successfully in the enterprise world. When talking about the number of times a scaling framework is used SAFe is absolutely on top. See 11th State of Agile report for international numbers and Trends and Benchmarks of SwissQ for Swiss numbers.

- Scrum.org is very focused on software development only and seems to be very successful with it. The quality of their certifications is in my humble opinion better than those of the Scrum Alliance. This because of standardization and hard questions, were those of the Scrum Alliance are hit or miss depending on your trainer and own efforts and interest to learn.

- Scrum Alliance is very focused on selling certifications, and this only on a ScrumMaster / Product Owner / Developer / Coach level. This meant that management was completely left out of the picture. But they are usually the ones that are deciding on what framework to implement.  SAFe understands this very well. The Scrum Alliance tries to catch up with Agile Leadership certifications, but this is also the wrong thing to address when it comes to enterprise selling.

- LeSS is not much used in companies. There are a number of use cases, but there is not a large market traction. The partnership with Scrum Alliance could change this.

- SAFe is entering the certification market of Scrum.org and Scrum Alliance with their Advanced Scrum Master Certifications.

Implementation

- SAFe has defined a very clear path to implementation with its implementation roadmap. There it addresses the very important point of training all executives, managers, and leaders even before you train your teams. Get their buy-in and understanding. This is absolutely the right way to do. Again, they seem to understand how the enterprise world works.

- LeSS also has written about how an implementation (they call it adoption) would work best. It is not as clear and detailed as that from SAFe, but it makes sense and is a good start.

- Scrum Alliance actually hardly mentions how you could implement Scrum in your organization. It's training and certification only focus on how to run a single Scrum team. This is a huge gap in their training.

- Scrum at Scale is not a framework and not something you can implement. But it is an incredibly helpful tool to help you create your own scaling strategy and/or framework.

- SAFe (like Scrum) is very prescriptive, so it easy to start with. All steps are defined for you. The way it is defined and how prescriptive it is takes away the Agile part of it. You could easily argue that SAFe is not Agile at all anymore.

- In order to successfully implement LeSS, Nexus or even Scrum, you will need significant changes in your organizational structure. With SAFe you do not, it is placed on top what you have, so it is easy for management to decide this because they do not have to change.   

What would I implement?

I already have written down my "Essential rules for Scaling Agile" in a previous post, and I still stand by them. But when I would be forced to select a framework for a product oriented company I think LeSS can be of high value when a goal of the company is becoming agile. When it is a company with a traditional project culture and is saying it wants to be agile, but is actually liking the status quo than it is far much easier and probably more successful to implement SAFe. 

It seems to me to be a compromise between the abstract desire for more agility and the typical constraint that the enterprise can get away without more agility. I appreciate its attempt to acknowledge the realities of the typical enterprise, but it seems to give enterprises an excuse not to change very much. I don't like it, but I understand why it exists and seems to be selling very well. The verdict is still out if it actually works very well for all those organizations.

Read more…

Tuesday, April 11, 2017

The Ultimate Project Review Checklist

The Ultimate Project Review Checklist
After reading the book "The Checklist Manifesto: How to Get Things Right" from Atul Gwande I was thinking about a number of checklists that I am using on a regular basis myself.

A few of them were created by others (see for example the Unofficial Scrum Checklist and the ScrumMaster Checklist), but I also created many of them myself. This eBook is one of those. It is the checklist I use as a base for my Project Reviews. Like every checklist, you have to adapt it to your specific situation, but I think you will find it very usefull as a base for your own Project Review. It contains 22 different categories and more then 140 different checks/questions.

Focus is on software development, financial modelling, business intelligence and data migration projects, but most of it is valid for other projects as well. Since I use almost exclusively agile techniques like Scrum, Kanban, XP and LeSS in my projects the list is leaning in this direction, but I tried to keep it very method agnostic. Meaning this list is just as usefull for waterfall projects as for a typical agile Project. You can get a free copy below.


The Ultimate Project Review Checklist

Get your Ultimate Project Review Checklist

Read more…

Sunday, April 09, 2017

Your real project costs

At the top of the budget hierarchy in most companies and organizations stand two major kinds of budgets, a capital budget, and an operating budget. These two kinds of budgets do not overlap: they handle distinctly different spending categories. Capital and operating budgets, moreover, are built through different budgeting processes, by different managers, and they use different criteria for prioritizing and deciding spending.

A capital expenditure (CapEx) is defined as an expenditure contributing value to the property and equipment of a business. It is an expenditure toward capital assets, as contrasted with spending that covers operating expenses (OpEx) or purchase of investments unrelated to the company's primary business.

Many projects I am involved in only looked at the potential (and mostly theoretical) business benefits and the CapEx cost upfront. They "forgot" or "ignored" the OpEx side of the project. These can be very high compared to the initial project costs. Especially when you implement a new technology/product in your company where there is no team yet that understands it and is able to run it without help from outside.

Even when working with both CapEx and OpEx a number of "hidden" costs are easily forgotten, hence the concept of Total Cost of Ownership (TCO) for 3 or 5 years.

Let me start with a quick definition of CapEx, OpEx, and TCO.

Capital Expidenture (CapEx)

CapEx is an expense where the benefit continues over a long period, rather than being exhausted in a short period. Such expenditure is of a non-recurring nature and results in an acquisition of permanent assets. It is thus distinct from a recurring expense.

For tax purposes, CapEx is a cost which cannot be deducted in the year in which it is paid or incurred and must be capitalized. The general rule is that if the acquired property's useful life is longer than the taxable year, then the cost must be capitalized. The capital expenditure costs are then amortized or depreciated over the life of the asset in question. Further to the above, CapEx creates or adds basis to the asset or property, which once adjusted, will determine tax liability in the event of sale or transfer.

Included in capital expenditures are amounts spent on:

1. acquiring fixed, and in some cases, intangible assets
2. repairing an existing asset so as to improve its useful life
3. upgrading an existing asset if it results in a superior fixture
4. preparing an asset to be used in business
5. restoring property or adapting it to a new or different use
6. starting or acquiring a new business

An ongoing question for the accounting of any company is whether certain expenses should be capitalized or expensed. Costs which are expensed in a particular month simply appear on the financial statement as a cost incurred that month. Costs that are capitalized, however, are amortized or depreciated over multiple years. Capitalized expenditures show up on the balance sheet.

Most ordinary business expenses are clearly either expendable or capitalizable, but some expenses could be treated either way, according to the preference of the company. Capitalized interest if applicable is also spread out over the life of the asset. The counterpart of capital expenditure is operational expenditure (OpEx).

Operating Expidenture (OpEx)

An operating expense, operating expenditure, operational expense, operational expenditure or OpEx is an ongoing cost for running a product, business, or system. Its counterpart, a capital expenditure (CapEx), is the cost of developing or providing non-consumable parts for the product or system. For example, the purchase of a software involves CapEx, and the annual maintenance fee, power, and maintenance costs and people running the software represent OpEx.

In business, an operating expense is a day-to-day expense such as sales and administration, or research & development, as opposed to production, costs, and pricing. In short, this is the money the business spends in order to turn inventory into throughput.
On an income statement, "operating expenses" is the sum of a business's operating expenses for a period of time, such as a month or year.

Operating expenses include:

1. license fees
2. maintenance and repairs
3. people who operate the software
4. training
5. first, second and third level support

To summarize the key differences between CapEx and OpEx are:

Total Costs of Ownership (TCO)

Total Cost of Ownership (TCO) is an analysis meant to uncover all the lifetime costs that follow from owning certain kinds of assets. As a result, TCO is sometimes called life cycle cost analysis.

Asset ownership brings purchase costs, of course, but ownership also brings costs due to installing, deploying, using, upgrading, and maintaining the same assets. These after-purchase costs can be substantial. Consequently, for many kinds of assets, TCO analysis finds a very large difference between purchase price and total life cycle costs. And, the difference can be especially large when ownership covers a long time period. As a result, TCO analysis sends a very strong message to corporate buyers, capital review groups, and asset managers:

Those who purchase or manage IT systems have had a keen interest in TCO since the late 1980s. At that time, IT industry analysts began publishing studies showing a very large difference between IT systems prices and systems costs. And, not surprisingly, these soon got the attention of IT vendor sales teams and marketers.

Competitors of large companies, for instance, used their own TCO results to argue that the systems of these large companies were overly expensive to own and operate. This kind of argument is possible because the five-year total cost of ownership for major hardware and software systems—from any vendor—can be five to ten times the hardware and software purchase price. The same is currently happening with the move to the cloud.

TCO for large projects and purchases is very helpful in the following:

1. Budgeting and planning
2. Asset life cycle management
3. Prioritizing capital purchase proposals.
4. Evaluating capital project proposals
5. Vendor selection.
6. Lease vs. buy decisions.

Why does it matter?

In order to make a good decision about starting, continuing or ending a project you need a good overview of the costs of the project. Just using the direct costs of the project are usually only a small part of the truth.

Consider TCO instead of project costs when making decisions!






Read more…

Tuesday, March 28, 2017

Cost of delay

Cost of Delay
The Cost of Delay (COD) is a term used in Software Product Development. It is a method used to understand and communicate the effect of time against predicted outcomes. It provides a method to determine and evaluate the cost of not finalizing something now, by choosing to do it at a later stage.

In software development, COD can be used to determine the cost of delaying the deployment of one feature over another. Taking things a step further, if a company has multiple projects running at the same time, using COD calculations can help them prioritize which projects should be done first.

A business is there to make money and it’s logical to prioritise what you do in such a way that you maximize profits. Calculating your COD allows you to do exactly that. Let’s use a very simple example. If you’re developing a product that will add a value of $10,000 per week to your company, you will lose that amount for every week that you’re late. A delay of 6 weeks will cost the company $60,000. If you knew that up front, it would make sense to, for example, hire an additional programmer for $15,000 if that means the product will be released on time. You would still be $45,000 better off.

Quantifying the Cost of Delay

Suppose we have 3 features that we can include in our software, each with a different value and each having a different development time. We can use Cost of Delay to make the best financial decision on what to do first.

Step 1 – Determine Feature Values

Put the features, their values and their development time in a table as shown below.

Dev Time
Value / week
CD3
Feature 1
2 Weeks
$3,000
1.5
Feature 2
5 Weeks
$9,000
1.8
Feature 3
7 Weeks
$12,000
1.7

The CD3 value is calculated by dividing the value in thousands by the dev time, e.g. 3 / 2 = 1.5

Step 2 – Compare Scenarios

Let’s compare different scenarios, showing the return on investment we would get using different priorities.

1.  Do all features at the same time.
2.  Complete feature 1 (shortest time) first, followed by 2 and 3.
3.  Complete feature 3 (highest value) first, followed by 2 and 1.
4.  Complete feature 2 (highest CD3) first, followed by 3 and 1.





Step 3 – Calculate Financial Impact

Scenario 1 - All
If we do all features at the same time, we get $24,000 of value on our 15th week.  For the 14 weeks we are developing, we incur the COD of all features = $24,000.

Total COD incurred = $336,000.

Scenario 2 - Time
In this scenario, we will get our first ROI of $3,000 from week 3, $9,000 from week 8 and $12,000 from week 15. For the first 2 weeks, our COD is for all 3 features = $24,000 x 2 = $48,000. From week 3 to 7 (5 weeks), our COD is Feature 2 + Feature 3 = $21,000 x 5 = $105,000. From week 8 to 14 (7 weeks), our COD is Feature 3 = $12,000 x 7 = $84,000.

Total COD incurred = $48,000 + $105,000 + $84,000 = $237,000.

Scenario 3 – Value
In this scenario, we will get our first ROI of $12,000 from week 8, $9,000 from week 13 and $3,000 from week 15. For the first 7 weeks, our COD is for all 3 features = $24,000 x 7 = $168,000. From week 8 to 12 (5 weeks), our COD is Feature 2 + Feature 1 = $12,000 x 5 = $60,000. From week 13 to 14 (2 weeks), our COD is Feature 1 = $3,000 x 2 = $6,000.

Total COD incurred $168,000 + $60,000 + $6,000 = $234,000.

Scenario 4 – CD3
In this scenario, we will get our first ROI of $9,000 from week 6, $12,000 from week 13 and $3,000 from week 15. For the first 5 weeks, our COD is for all 3 features = $24,000 x 5 = $120,000. From week 6 to 12 (7 weeks), our COD is Feature 1 + Feature 3 = $15,000 x 7 = $105,000. From week 13 to 14 (2 weeks), our COD is Feature 1 = $3,000 x 2 = $6,000.

Total COD incurred $120,000 + $105,000 + $6,000 = $231,000.

Summary

The results from the different scenarios described above is surprising. One would have expected that doing the feature with the most value first is the best financial decision, but this is not the case. Prioritizing based on the CD3 value of a feature gives the best results. Although the difference is small in the example used, it may not be the case for your product.

Priority Method
Cost of Delay
All
$336,000
Time
$237,000
Value
$234,000
CD3
$231,000

When next time you prioritize your software development portfolio, don’t try to maximize the value delivered. Limit your Cost of Delay, or at least do the calculation before making a decision.

It’s not only about prioritisation!

COD gives you a number of other benefits that will help when you develop new or improved products:

Improved Decision Making
COD will make the economic trade-offs in your projects and processes visible. Every creative process has these trade-off decisions, where we often need feedback about what will work and what won’t fast. There are many trade-offs at the development system level where Cost of Delay can be used as an effective tool for managing workflow. COD can help you calculate suitable levels of capacity application, managing queue lengths, testing WIP limits, or improving batch sizes at different points.

Optimal Prioritisation
You can deliver more total value by using CD3. As there is never an infinite capacity to develop everything, the demand has to be controlled somehow. You have to decide where to start, determine the order in which things should be done and, importantly, when you have to change direction and move on to something else that is more urgent and valuable. If you understand Cost of Delay, you can stop using gut-feel to prioritise and be very specific in determining what to do next. Having a definitive method available will also allow you to communicate your reasoning and the logic behind it clearly.

Change the focus
By using Cost of Delay, you will change the focus from cost and efficiency, to value and speed. It doesn’t help expecting people not to estimate things like delivery dates or cost, if you are not able to give them a practical alternative that will actually help. By defining things in terms of Cost of Delay, you will achieve more of what you want and less of what won’t help you.

Read more…

Monday, March 06, 2017

Building is the easy part...



DevOps
Agile Frameworks and books tell us how to build a product--that's the easy part... What we are not told are equally important things like maintaining, operating, fixing and extending the built product. When your agile philosophies fail to cover these areas, it greatly reduces agile's benefits. This is where DevOps comes into play.

DevOps is the combination of practices, cultural philosophies, and tools; in order to increase the speed at which organizations deliver applications and services. This results in evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This benefits the customers who will enjoy better services and the organization which will have a greater competitive edge.

DevOps means joining development and operations. These two teams form a single union, to oversee the total lifespan of an application: development, test, deployment, operations etc. and there are no limitations to the number of skills that can be developed when DevOps is involved. There's the possibility of quality assurance and security teams coming together in close conjunction with development and operations teams for the duration of the application's lifecycle.

These teams use practices to automate processes that historically have been manual and slow. They use a technology stack and tooling which help them operate and evolve applications quickly and reliably. These tools also help engineers independently accomplish tasks (for example, deploying code or provisioning infrastructure) that normally would have required help from other teams, and this further increases a team’s velocity.

Benefits of DevOps

Speed
For customers to get quick services; for organizations to efficiently adapt to the changing market and for them to gain the needed competency for achieving their desired business results; a model that provides maximum speed is required. No better model than the DevOps model to make these results materialize. A quick release of updates is made possible as services are ultimately controlled by the teams.

Rapid delivery
When releases are fast because of an increase in speed; quick improvement and innovation of products follow suit. When there is a consistent release of new features and bugs are quickly fixed; you will retain your customers as their needs are promptly satisfied; thus, you don't lose them to your competitors. The software release process is automatic because of the uninterrupted integration and delivery practices.

Reliability
While your delivery is fast; DevOps ensures that the application updates and infrastructure changes remain qualitative regardless of speed--the consumers continue enjoying a positive experience. To be sure of the functionality and safety of each change, you should test it with continuous delivery and continuous integration. Using practices like logging and Monitoring ceaselessly gives you information about the performance.

Scale
The risk that comes with managing complex or changing systems can be minimized when you operate and manage your infrastructure and development processes at scale. They can be efficiently managed with automation and consistency. Your development, testing, and productive environment, for instance, can be more efficiently managed using infrastructure as code.

Improved collaboration
With ownership comes responsibility and accountability. When the teams are equipped with these, they become more effective--this is what the DevOps model brings about. Labor is divided between the development and operations teams. As they closely work together, time is saved and efficiency level is increased. For example, handover periods that involve writing codes that account for the background environment is placed at a minimal level.

Security
Automated compliance policies, fine-grained controls, and configuration management techniques keep your security intact as you adopt the DevOps model. Compliance at scale can be defined and tracked using infrastructure as code and policy as code.

DevOps practices

With the necessary tools, some key practices can boost the innovation speed of organizations. These practices involve automating and streamlining the software development and infrastructure management processes.

One fundamental practice is to perform very frequent but small updates. This is how organizations innovate faster for their customers. These updates are usually more incremental in nature than the occasional updates performed under traditional release practices. Frequent but small updates make each deployment less risky. They help teams address bugs faster because teams can identify the last deployment that caused the error. Although the cadence and size of updates will vary, organizations using a DevOps model deploy updates much more often than organizations using traditional software development practices.

Another essential practice is implementing a microservices architecture. It is like a breakdown tool; it breaks down complex systems and makes projects simple and independent. Organizations can use microservices architecture to create less rigid applications and ensure quicker innovations. There are varying individual services in an application, with different functions that work independently of each other. This architecture minimizes the coordination overhead of updating applications and as each service is paired and owned by agile teams, the speed of an organization’s progress is increased.

To attend to the operational challenges that might arise because of the combination of microservices and increased release frequency; DevOps practices like continuous integration and continuous delivery come into play to ensure that reliability and safety are maintained even as a rapid delivery remains in progress. Infrastructure as code and configuration management are infrastructure automation practices that help to ensure that frequent changes do not affect the elasticity and response of computing resources.

Furthermore, engineers can track applications and infrastructure's performance using monitoring and logging, to keep them actively reactive to problems. Delivery is fast, updates are reliable and customers are satisfied with organizations that make use of these practices. Outlined below are important DevOps practices.

Continuous integration
With this software development practice; developers can as much as possible merge their code changes into a central repository before running automated builds and tests. Continuous integration ensures that bugs are quickly found and addressed, the quality of software improved, and time isn't wasted in validating and releasing new software updates.

Continuous delivery
Prior the release of a production, continuous delivery automatically builds, tests and prepares code changes. This software development practice deploys all code changes to a testing environment and a productive environment after the build stage, by expanding upon continuous integration. The right implementation of continuous delivery provides developers with a deployment-ready build artifact that has undergone series of standardized tests.

Microservices
The microservices architecture runs a set of small services in a single application. These services are independent of each other and communication between these services is by means of a well-defined interface that uses a lightweight mechanism--an HTTP-based application programming interface (API). Each service has a single function which matches microservices with business needs. There are different Frameworks or programming languages that can be used to write microservices and they can also be set to either function as a single or group of services.

Infrastructure as code
Code and software development techniques like version control and continuous integration are used to merge and provision infrastructure under this practice. The interaction with infrastructure is programmer based and at scale rather than a manual setup and configuration resource. The API-driven model of its cloud makes it possible for system administrators and developers to interact with the infrastructure as such. Code-based tools are used by engineers to interface with infrastructure; hence it is treated like an application code. There being code based makes it possible for infrastructure and servers to be quickly deployed, using fixed standards, also the latest patches and versions can either be updated or repetitively duplicated.

Configuration management
The operating system, host configuration, operational tasks etc. are automated with codes by developers and system administrators. As codes are used, configuration changes become standard and repeatable. This relieves developers and system administrators of the burden of configuring the operating system, system applications or server software manually.

Policy as code
The configuration of infrastructure and infrastructure itself are codified with the cloud. This makes it possible for organizations to dynamically monitor and enforce compliance. It enables the automatic tracking, validation, and reconfiguration of infrastructure. In that way, organizations can easily control changes over resources and security measures are properly and distributively enforced. The fact that resources that do not comply can be flagged automatically for further investigation or automatically restarted to comply, increases the speed level of teams within an organization.

Monitoring and logging
To gauge the impact that the performance of application and infrastructure have on consumers, organizations monitor metrics and logs. The data and logs generated by applications and infrastructure are captured, categorized and then analyzed by organizations to understand how users are impacted by changes or updates. This makes it easy to detect sources of unexpected problems or changes. It is necessary that there be a constant monitoring, to ensure a steady availability of services and an increment in the speed at which infrastructure is updated. When these data are analyzed in real-time, organizations proficiently monitor their services

Communication and collaboration
This is the key feature of DevOps model; as development and operations come together and share their responsibilities, team spirit is enhanced and communication skills are facilitated. Chat applications, project tracking systems, and wikis are some of the tools that can be used by not just developers and operations but also other teams like marketing or sales. This brings all parts of the organization closely together as they cooperate to see to the realization of goals and projects.

Read more…