Monday, February 19, 2018

Project portfolio throughput

Too many organizations try to save money on projects (cost efficiency) when the benefits of completing the project earlier far outweigh the potential cost savings.

You might, for example, be able to complete a project with perfect resource management (all staff is perfectly busy) in 12 months for $1 million. Alternatively, you could hire some extra people and have them sitting around occasionally at a total cost of $1.5 million, but the project would be completed in only 6 months.

What's that 6 months difference worth? Well, if the project is strategic in nature, it could be worth everything. It could mean being first to market with a new product or possessing a required capability for an upcoming bid which you don't even know about yet. It could mean impressing the heck out of some skeptical new client or being prepared for an external audit. There are many scenarios were the benefits outweigh the cost savings (see "Cost of delay").

Additional to delivering the project faster, when you are done after 6 months instead of 12 months you can use the existing team for a different project delivering even more benefits for your organization. So not only do you get your benefits for your original project sooner and/or longer, you will get those for your next project sooner as well because it starts earlier and is staffed with an experienced team. 

An important goal of your project portfolio management strategy should be to have a high throughput. Get projects delivered fast so you start reaping your benefits, and your organization is freed up for new projects to deliver additional benefits.

For a typical organization this means three things;

1) Doing fewer projects (in parallel). On average only half of what you are doing now.
2) Focus on doing the right projects.
3) Focus on improving your project delivery capability.

Read more…

Monday, February 12, 2018

What is project recovery?

As soon as a project is identified as in trouble you can start thinking about project recovery. This sentence already states a very important precondition for a successful project recovery process, namely identifying a project as troubled. It takes a great deal of political savvy and courage to admit that a project is in serious trouble.

Results of a project recovery

A project recovery process can have three possible outcomes:

1) Delivery of the project without significant changes in scope, time and/or costs. This is very rarely and only possible when trouble is identified early and action is taken immediately. For me, this is actually part of regular project management and is not really part of project recovery.  

2) Delivery of the project with significant changes in scope, time and/or costs. There will be an impact on the business case. 

3) Termination of the project because costs and benefits or value are no longer aligned. Note that termination does not necessarily mean that everything done up to this point should be written off as sunk costs. Some part might be salvageable.

Seldom projects get into trouble overnight. There are early warning signs, but most companies seem to overlook them or misunderstand them. Some companies simply ignore the tell-tale signs and continue on hoping for a miracle. Failure to recognize these signs early can make the cost of downstream corrections a very costly endeavor. Also, the longer you wait to make the corrections, the costlier the changes become.

When a project gets way off track, the cost of recovery is high. Recovery costs come in the form of additional costs, reduced scope, longer time to market, changed business case, and others. Additional internal and external resources may be required for corrections and filling skill gaps. In these cases, the ultimate goal for project recovery is no longer to finish on time but to finish with reasonable benefits and value for the customer and the stakeholders. 

Not all troubled projects can be recovered (nor should they). When the project is not regulatory or essential for business continuation, termination is (and should) always be an option.

The project recovery manager

As soon as the decision has been made that a recovery process will be started there will be the need for a project recovery manager. It is not always necessary (or smart) to give the recovery manager also the role of actual project manager. 

Taking over a troubled project is not the same as starting up a new project. Project recovery managers must have a good understanding of what they are about to inherit. This includes:

- A burned out and emotionally drained team
- Poor morale
- An exodus of the talented team members that are always in high demand elsewhere
- A team that may have a lack of faith in the recovery process
- Angry customers
- Nervous management
- Invisible sponsorship and governance
- Either completely passive or highly active stakeholders

Project managers that do not understand what is involved in the recovery of a troubled project can make matters worse by hoping for a miracle and allowing the "death spiral" to continue to a point where recovery is no longer possible. The death spiral continues if we:

- Force employees to work excessive hours unnecessarily
- Create unnecessary additional work
- Replace team members at an inappropriate time.
- Increase team stress and pressure without understanding the ramifications
- Search for new "miracle" tools to solve some of the issues
- Hire consultants that cannot help or make matters worse by taking too long to understand the issues

The project recovery process

A typical project recovery process consists of five phases

1) Mandate phase
2) Review phase
3) Tradeoff & Negotiation phase
4) Correcting & Delivery phase
5) Transition phase

The mandate phase

The purpose of the mandate phase is simple. The project should be identified as troubled, and a project recovery manager should be identified. The mandate of the project recovery manager should be defined clearly. Especially when the recovery manager is working with the current or new project manager instead of replacing him/her. Afterwards, the project recovery manager and his/her should be introduced to everybody that needs to know. 

The review phase

Now that we have a clear mandate, we enter the review phase, which is a critical assessment of the project's existing status. You will look at what went wrong and what can be corrected rather than looking for someone to blame. A project review is all about the probability of project success. A project review will give you a good understanding of the current status of the project and how it is on track to deliver against your definition of project success on three levels:

1) Project delivery success
2) Product or service success
3) Business success

You will find a detailed outline of such a project review in my article "What is a project review?". Note that if the project has a technical component, the project recovery manager should have a strong technical background so that he or she can talk with the technical team on its own level, gaining trust as someone who understands the challenges. This must be coupled with an independent critical eye questioning the direction. Many aspects of technology development can contribute or even cause trouble on a project.

The tradeoff & negotiation phase

Hopefully, by this point, you have the necessary information for decision making as well as the team's support for the recovery. 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 your stakeholders.

When the project first began, the constraints were most likely the traditional triple constraints. 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 troubled, 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. See "The reverse triple constraint of troubled projects" for more background on this.

After defining the tradeoffs, the project recovery manager is ready for stakeholder negotiations provided that there still exists a valid business case. If the review phase indicates that the recovery is not possible and a valid business case does not exist, then there may be no point to negotiate with the stakeholders unless there are issues with which the project recovery manager is not familiar.

The intervention phase

Assuming the stakeholders have agreed to a recovery plan, you are now ready to start the intervention phase of the project. This means: 

- Briefing the team on the outcome of the negotiations 
- Making sure the team learns from past mistakes 
- Introducing the team to the stakeholders' agreed-upon recovery plan including the agreed-upon milestones 
- Introducing any changes to the way the project will be managed 
- Fully engaging the project sponsor as well as the key stakeholders for their support
- Identifying any changes to the roles and responsibilities of the team members 
- Restore team confidence 

"We cannot solve our problems with the same thinking we used when we created them." - Albert Einstein
The way I set up the delivery part of the project with my team(s) at almost every intervention phase I start I described in "A simple and effective project delivery framework". 

The transition phase

As soon as the project is in a normal state again the project recovery manager (when he/she does not have the project manager role) can transfer the responsibility for the recovered project and closes the recovery process. When the project recovery manager also has the role of project manager he/she can decide to close the recovery process and manage the project as if it was a freshly started project or keep the project in a recovery process until the project is finished. 

Read more…

Sunday, February 11, 2018

What is a troubled project?

Most of my work is with what you can call "troubled projects". But what does this actually mean? Many teams I have worked with seem to be stuck in the PMI view of things. The PMBOK® Guide defines the successful project as a project that meets its objective in terms of quality, schedule, budget, and scope (or customer satisfaction), while a project is a temporary endeavor undertaken to create a unique product, service or result. The guide does not define a troubled project but by taking the opposite of the above you can formulate a starting definition for troubled projects:

A troubled project is a project with overrun in quality, schedule, budget and scope that exceeds the acceptable tolerance limit and might be recovered.
Therefore, a specific effort is required to either define and execute a possible recovery or deciding for an early project termination, as both options are considered a solution for troubled projects. 

The meaning of trouble

From my point of view this definition of a troubled project is not useful because it only captures a very small part of what a successful project is. As discussed in a previous article, project success is defined across three levels:

1) Project delivery success: this is about the process of delivering the project is successful. Essentially this addresses the classic triangle "scope time, budget, and quality?" It is limited to the duration of the project and success can be measured as soon as the project is officially completed. Intermediary measures are easy to do as part of project control processes. Besides the typical project delivery KPIs you can also look at KPIs like overtime, project member satisfaction, stakeholder satisfaction, lessons learned (improved project delivery capabilities), etc.


2) Product or service success: this is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.). These criteria need to be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured during or directly at the end of the project itself.


3) Business success: this is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (5% market share won, technology advantage), etc. In most cases these business success factors can only be measured once the product/service is implemented and over a longer period of time. 


These three levels combined (and therefore measured by the combined set of KPI's from these levels) will determine your overall project success. Once you have taken the effort of defining all your project success criteria on each level (KPIs) you can define min, max and target values for them. Success is rarely a single point or value. 

The PMI view only looks at the first level: project delivery success. Personally, I think this level matters very little if level 2 and 3 are not met. Another issue with focusing on level 1 is that you measure success against estimations. I can have the best team, doing the absolute best work for 7 months, delivering great results for the client and company "failing" because some project manager without a clue about software development, without a team in place, and no deep understanding of the client requirements, decided that the scope could be delivered in 6 months.

In my opinion, a troubled project should be defined by the same three levels and KPIs as a successful project. Hence a troubled project can be defined as a project where the difference between what it is defined to be (your KPIs), and what can be expected to be (your measurements and projections) exceeds the acceptable tolerance limits (your min and max values), pushing it into a course that will inevitably lead to failure.

A troubled project is a project where the difference between what it is defined to be, and what can be expected to be, exceeds the acceptable tolerance limits, pushing it into a course that will inevitably lead to failure.

How does this help me?

So now we have a definition for troubled projects, but how does this help me recognizing, or even better, preventing one? It doesn't. It is just the first step of a longer process. The PMI view on troubled projects is easy to implement and measure. As shown above all project delivery success criteria can be measured during and directly at the end of a project. But product/service success and business success cannot. So we have to work with leading indicators and assumption validations in order to make meaningful measurements for those criteria during the project. This will be covered in a future article. To give you a start have a look at my article that discusses project validation.

Read more…

Wednesday, February 07, 2018

A simple and effective project delivery framework

A few years ago I stumbled on the website of Olaf Lewitz. Olaf is a Certified Enterprise Coach that approaches Scrum a little different as most. He has written a guide to Scrum in a way that is capturing the essence of Scrum and I think he did this very well. He calls it Liquid Scrum.

I recognized a lot of my own way of project delivery during project recoveries in it, and the last few years I have applied the process with a few adjustments with much success on large software development and financial modeling projects in distress.

Note this is only the delivery part, there is a whole lot more to a successful project then just delivery.

Assumption

Everyone involved takes shared responsibility for success. Focused interests (see below) never imply that something is not within your responsibility.

Advice

Assume everyone is contributing the best they can. Focus your conversations on options you have right now, not on what should be or should have been. Choose wisely: decide using consent or better. As soon as the assumption is proven to be untrue, act fast. The team is more important than its individuals.

Constrain your system with a timebox

Set a timebox of two weeks. This will give you rhythm and enable you to see what emerges, and give you options to focus:

Options

1) Deliver.

2) Visualise what you do in a way that supports your understanding of how you do it.

3) Reflect daily on what you see, decide on choices you have. Adapt the rhythm if that makes reflecting more effective. Only execute these three options until you can reliably deliver every two weeks. Everything else may confuse you.

4) Experiment within the bi-weekly timeboxes. Detail the options you discovered to set clear goals up front and indicators for success and failure. Decide what to invest and how to limit risk. Never run an experiment without making explicit what you want to achieve or learn.

5) Focus on what to deliver.

6) Reflect on what you did, and how you did it, and discover options to get better.

7) Communicate what you are doing, and what you did, to people outside the team.

Focused Interests

Your system may get better faster at making a difference if you focus on these three interests:

1) Do the right thing. (Value)

2) Do things right. (Quality)

3) Get better and better every day. (Speed)

- Better at delivering faster.
- Better at doing the right things faster.
- Better at doing things right faster.
- Better at deciding which of these is important, right now.(some people call this effectiveness, and it’s blurry)

In many or most systems having people take explicit responsibility for one of these works well. By-the-book Scrum, for example, prescribes one voice for 1. (Product Owner) and 3. (Scrum Master). In most contexts, that’s good advice and a good choice to start with.

For me, project delivery is about continuous improvement, scope flexibility, team input, and delivering essential quality outcomes. Methodologies I use and adapt include Scrum, LeSS, eXtreme Programming (XP), Kanban, Systems ThinkingLean Software Development and Lean Six Sigma.

Read more…

Monday, February 05, 2018

What is a project review?

- You want do to know where you are standing with that large, multi-year, strategic project?
- You think one of your key projects is in trouble?
- Or you know that one of your key projects is in trouble?

Then a project review is what you are looking for.

So what is a project review?

When we talk about a project review there are many names thrown around to indicate the same thing: project review, project health check, project audit, project retrospective, project postmortem. But are they really the same? Not really.

A project audit is about being compliant and about the now. An audit aims to show the extent to which your project conforms to the required organizational and project standards. So, if your organization uses PRINCE2 or their own project management methodology, an audit will look at how closely you follow the processes. An audit can take place during or after the project.

A project retrospective, or postmortem, is about lessons learned so that your next projects will run better or equally well. A project retrospective will be done after the project, so has no use for the project itself.

A project review is all about the future probability of project success. A project review will give you a good understanding of the current status of your project and how it is on track to deliver against your definition of project success on three levels:

1) Project delivery success: will the process of delivering the project be successful? Essentially this addresses the classic triangle "scope time, budget, and quality?"

2) Product or service success: this is about when the product or service to be delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.).

3) Business success: this is about how the product or service to be delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business.

A project review can take place at any time during or after the project, although it has very limited value at the start of a project.

Why do a project review?

A project review will give you:

- An outside 360-degree view on the current status of your project
- The information you need for good decision making
- An outside opinion on the success chances of the project (project delivery success, product/service success, and business success)
- Suggestions for corrective actions on the discovered project issues and challenges

When should you do a project review?

The three main reasons for doing a project review are:

1) Periodic review of large, multi-year, strategic projects to verify all work is on track and the business case(s) are still valid.
2) When you think one of your key projects is in trouble.
3) When you know one of your key projects is in trouble.

What will be done during a project review?

Below are the building blocks of a project review. The row order is not graved in stone and can be adapted based on availability and priorities. Results of one building block will be an input of another.

1) Understanding the project success criteria
2) Understanding the project stakeholders
3) Team Review
4) Scope Review
5) Financial Review
6) Timeline Review
7) Steering Committee and Governance Review (decision log)
8) Technology & Architecture Review
9) Engineering & Quality Review
10) Impact Analysis
11) Risk Assessment
12) Communication Review
13) Contract & Procurement Review

What will be the outcome of a project review?

1) An up to date assumption List
2) An up to date issue list
3) An up to date risk assessment
4) A detailed report with findings and suggested corrective actions
5) Presentation and discussion of findings and suggested actions

Read more…

Monday, January 22, 2018

When is my project a success?

We talk a lot about projects that were a failure. Hey, most of us have experienced a number of them. But when exactly is a project a failure, and more important, when is a project a success?

A project can only be successful if the success criteria are defined. And this ideally upfront. Unfortunately, I have seen many projects that skipped this part completely. When starting on a project, it's essential to work actively with the organization that owns the project to define success across three levels:

1) Project delivery
2) Product or service
3) Business

1 Project delivery success: this is about defining the criteria by which the process of delivering the project is successful. Essentially this addresses the classic triangle "scope time, budget, and quality?" It is limited to the duration of the project and success can be measured as soon as the project is officially completed (with intermediary measures being taken of course as part of project control processes). Besides the typical project delivery KPIs you can also look at KPIs like overtime, project member satisfaction, stakeholder satisfaction, lessons learned (improved project delivery capabilities), etc.


2 Product or service success: this is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.). These criteria need to be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured at the end of the project itself.


3 Business success: this is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (5% market share won, technology advantage), etc.


These levels combined will determine your overall project success. You can be successful on one level but not others. Personally, I think level 1 matters very little if level 2 and 3 are not met. Unfortunately, many companies emphasize level 1, instead of level 2 and 3 when it comes to project decisions.  


When it comes to accountabilities for success, they are different for each level:

1) Project delivery success: PM (and project team).
2) Product or service success: Product/Service Owner.
3) Business success: Project Sponsor.

The process of "success definition" should also cover how the different criteria will be measured (targets, measurements, time, responsible, etc.). Project success may be identified as all points within a certain range of these defined measurements. Success is not just a single point.

The hard part is identifying the criteria, importance, and boundaries of the different success areas. But only when you have done this you are able to manage and identify your project as a success.

Read more…

Wednesday, January 03, 2018

The only test plan you will ever need.

Assuming an iteration between two and four weeks:

1) Programmers will write unit tests in the code to ensure product technically behaves. The team will perform QA activities to ensure these are valid tests.

2) In the iteration planning meeting and in the iteration itself, tests cases will be defined as acceptance criteria for each product backlog item / requirement.

3) Acceptance criteria will be implemented as automated tests.

4) Every code check-in on the release branch will trigger all automated (unit and functional) tests to run as to perform full automated regression tests.

5) Tests will be implemented in the iteration where the requirement is being built.

6) Tools for performance, load and security tests will run at the end of each iteration.

7) Manual exploratory testing will be done at the end of an iteration in an attempt to identify missed tested cases.

8) At the iteration review meeting, stakeholders will verify that the solution is what they envisioned and will give feedback for the next iteration(s).

9) After deployment into production, you can implement A/B testing and review your product analytics to look at how users actually use your new functionality.

Read more…

Sunday, August 20, 2017

14 Essential software engineering practices for your agile project.

14 Essential Software Engineering Practices for Agility
Agile initiatives are found in almost any company that build software. Many of these initiatives have not brought the results that were expected. Nor are the people much happier in their work. This has many reasons, and a quick search on Google or LinkedIn will give you a plethora of them. But the one that I am confronted with almost every project I work on is the lack of experience with modern software engineering practices.

Flexibility (agility) can only happen when you are able to make changes to your product in an easy, fast, and flexible way. That is why:

Organizational Agility is constrained by Technical Agility





In other words, when you are slow in making changes to your product, then it doesn’t matter how you structure your teams, your organization or what framework you adopt, you will be slow to respond to changes. These changes include bug fixes, performance issues, feature requests, changed user behavior, new business opportunities, pivots, etc.

Luckily, there are a set of software engineering practices that will help your team to deliver a high-quality product in a flexible state. These practices are not limited to building software, they cover the whole process until actual delivery of working software to the end user.

Unfortunately, many software engineers I have met in the financial service industry have had very limited exposure to these practices and their supporting tools. And don't get me started on the newly born army of agile coaches and Scrum Masters that have not produced a single line of working code in their life. Besides hindering agility, it frustrates the teams because without these practices it is almost impossible to deliver working software in high quality within one Sprint. 

Your organization will need to invest in these software engineering practices by training, infrastructure, tools, coaching and continuous improvement when you want your agile initiatives to actually able to deliver agility.

1. Unit Testing

The purpose of unit testing is not for finding bugs. It is a specification for the expected behaviors of the code under test. The code under test is the implementation for those expected behaviors. So unit test and the code under test are used to check the correctness of each other and protect each other. Later when someone changed the code under test, and it changed the behavior that is expected by the original author, the test will fail. If you code is covered by a reasonable amount of unit tests, you can maintain the code without breaking the existing feature. That’s why Michael Feathers define legacy code in his book as code without unit tests. Without unit tests your refactoring efforts will be a major risk every time you do it.


2. Continuous Integration

Martin Fowler defines Continuous Integration (CI) in his key article as follows: "Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly." You see, without unit tests and test automation, it is impossible to do CI right. And only when you do CI right you might be able to succeed at Continuous Deployment.


3. Collective Code Ownership

Collective Ownership encourages everyone to contribute new ideas to all segments of the project. Any developer can change any line of code to add functionality, fix bugs, improve designs or refactor. No one person becomes a bottle neck for changes. This is easy to do when you have all your code covered with unit tests and automated acceptance tests.


4. Refactoring

Code should be written to solve the known problem at the time. Often, teams become wiser about the problem they are solving, and continuously refactoring and changing code ensures the code base is forever meeting the most current needs of the business in the most efficient way. In order to guarantee that changes do not break existing functionality, your regression tests should be automated. I.e. unit tests are essential.


5. Test Driven Development

Test-driven development is a development style that drives the design by tests developed in short cycles of: 



1. Write one test,
 
2. Implement just enough code to make it pass,

3. Refactor the code so it is clean.



Ward Cunningham argues that test-first coding is not testing. Test-first coding is not new. It is nearly as old as programming. It is an analysis technique. We decide what we are programming and what we are not programming, and we decide what answers we expect. Test-first is also a design technique.


6. Automated Acceptance Testing

Also known as Specification by Example. Specification by Example or Acceptance test-driven development (A-TDD) is a collaborative requirements discovery approach where examples and automatable tests are used for specifying requirements—creating executable specifications. These are created with the team, Product Owner, and other stakeholders in requirements workshops. I have written about a successful implementation of this technique within Actuarial Modeling.


7. Chaos Engineering

Even when all of the individual services in a distributed system are functioning properly, the interactions between those services can cause unpredictable outcomes. Unpredictable outcomes, compounded by rare but disruptive real-world events that affect production environments, make these distributed systems inherently chaotic.

You need to identify weaknesses before they manifest in system-wide, aberrant behaviors. Systemic weaknesses could take the form of: improper fallback settings when a service is unavailable; retry storms from improperly tuned timeouts; outages when a downstream dependency receives too much traffic; cascading failures when a single point of failure crashes; etc.  You must address the most significant weaknesses proactively before they affect our customers in production.  You need a way to manage the chaos inherent in these systems, take advantage of increased flexibility and velocity, and have confidence in your production deployments despite the complexity that they represent.

An empirical, systems-based approach addresses the chaos in distributed systems at scale and builds confidence in the ability of those systems to withstand realistic conditions. We learn about the behavior of a distributed system by observing it during a controlled experiment. This is called Chaos Engineering. A good example of this would be the Chaos Monkey of Netflix. 

8. Continuous Deployment

Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready. Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.



9. Micro Services

The micro services 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, for example, a REST API. Each service has a single function which matches micro services with business needs. There are different frameworks or programming languages that can be used to write micro services and they can also be set to either function as a single or group of services.


10. 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.


11. 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.


12. 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.


13. 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


14. Communication and Collaboration

This is the key feature of any Agile and/or DevOps model; as development, test, security, 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…