June 20, 2016

Is Agile dead (already)?

I've been pushing Agile development for long time, as opposed to traditional methodologies like waterfall... or to no methodology.
I no longer deliver IT projects myself, but I help customers and partners to plan and deliver theirs.
The most important goal I set is achieving quick wins, like I described in become-cloud-provider-in-3-months.
A quick win encourages all the stakeholders (the project team, their clients, the lines of business that provide the budget, everybody up to the CEO).
Not only it demonstrates that the solution works, but it is a concrete measurement of the return on the investment.
Generally projects are not done because they are smart, but because they are supposed to generate a financial gain (more revenues or lower expenses). Even when the goal is described as a faster go to market, the ultimate target is generating more revenues.

Agile development make projects easier and faster

Agile development is not the only way to achieve a quick win, but it helps.
It also helps in reducing the project risk because, if you have to fail, you fail soon (and save a useless effort).
So, when a colleague sent me this article to solicit my comment, I almost felt insulted by the author... though I'm pretty sure he was not referring to me  :-)

A note on the author: 
Matthew Kern has a long experience in the field, so he knows what he's talking about.
He’s been writing many posts since 2015 to explain that Agile is dead.
Definitely he knows the Agile methodology and its usage, so he deserves respect.
More, he published a followup of that post offering the correct interpretation: probably he received too many protests.

Nevertheless my first impression was negative, because he was criticizing my fundamental believes.
But reading it carefully I understood that he's not wrong. He criticizes the evolution of the Agile methodology and the usage that someone made of it as a marketing tool, also in the light of newest trends like DevOps.

the feedback loop in devops

In my opinion, some overstatements in the article - starting with the title - are a mean to get visibility.
Indeed, in the conclusion he explains what he really means (and I partially agree): he refers to the “Agile” brand, to politics and to commercial usage (literature, consulting, marketing...).

When he says that agile don't work for large enterprises, I would distinguish between vendors of software products and customers doing it for their own project. 
The lifecycle of a software applications is completely different in these two scenarios, and so are the business requirements, the expected quality of the product, the variety of users, the frequency of the updates and bug fixes. 

When he says that many projects fail, he highlights a fact that is common to all methodologies.
But, at least, with Agile you fail soon (that is one of the objectives: better to fail in one month than after 1-2 years of unproductive activities eating your time and money).

it's better to fail before you fly too high

So, if we focus on the hype, on brands and marketing activity, Agile is being replaced by DevOps (that can be considered its evolution, taking care also of the Operations with continuous delivery and feedback) and later even DevOps will be replaced by next hype.

But they both produce a value for developers and for the IT: you can see it in the cultural shift and in the individual interpretation of the principles, rather than in  coded best practices. As an example, I’ve seen that my colleagues in Cisco Advanced Services started using Agile with visible benefits for both themselves (less bureaucracy) and customers (better and faster projects).

In conclusion, definitions are important and they help to spread the knowledge.
But theory is important for professors only, while a good practice makes developers and project managers happy.
If they adopt the principles of Agile, they work - even using Scrum informally - implementing those guidelines and produce good results, would you stop them?
It’s better to be Agile than not... 

it is better to be agile than not...


June 14, 2016

Why don't you try Openstack (without getting your hands dirty)?

Is Openstack ready?
But, more important: are you ready for Openstack? 


are you ready for Openstack?

Openstack is mature (but complex).

Surveys and statistics show that Openstack is mature and provides a number of benefit to a broad spectrum of users, from small to large enterprises and service providers.  
Almost every professional in the IT (including CIOs and CTOs) knows the advantage that Openstack would offer to his organization.
But many are also aware of the complexity of the technology, the need for new operational processes and skills to set up and operate Openstack.
A scalable and reliable production environment is different from a lab where you explore the capabilities of the new platform.
The journey to a mature adoption of Openstack is not easy and you need to invest time and money.
In addition, when you hire people (or train yours), there is a possibility that another company steals them with the offer of a better salary, given the scarcity on the market.

So, many IT organizations - excluding cloud service providers, because that’s exactly their business - started wondering if it’s worth spending time in running the infrastructure, rather than running their business applications.
If you are not a cloud provider, that makes money selling IaaS, why should you dedicate additional effort to installation, monitoring, troubleshooting and release upgrades to ensure reliability and performances to your applications (that’s the only asset you should care of, because your business relies on them)?

Focus on your real business.

Why don’t you delegate all the responsibility to a provider, signing a contract that puts the above tasks and SLA on them?
Doing so, you would be free to use Openstack, getting all the benefit that you expect from it, without the burden of the learning curve and the organization implied by the Openstack adoption.
You would focus on using the infrastructure to develop and run your applications, no longer on running the infrastructure itself.

delegate the responsability of the service to a specialized provider

That is called a managed service.

You own the infrastructure and exploit the value of your Data Center assets (you don’t just drop them to escape to a public cloud).
An expert team (it’s just their business) installs Openstack in your DC and operates it everyday in a HA (high availability) configuration, granting 99.99% uptime.
They take care of all the version upgrades and the compatibility of all the new features released by the community by using a certified configuration.
The user interface (the Horizon console, the Openstack API and command line interface) is available to you so you can deploy virtual server instances, networks, storage at will. You get complete and granular reporting on the health of the system and its performances.
You are the owner, but you don't get your hands dirty with the complex stuff   :-)
You pay them for the service, they grant you the SLA.

Just taste if you like Openstack.

The approach described above can be a strategical decision, because you want to focus on your business applications.
But you could also use this trick to stand up a Openstack environment in very short time, test it (I mean if your organization adapts to it, if your applications run well, if the operational model - IaaS at home, on your infrastructure, no cloud provider lock in - is good for you, if your developers are more productive) for a while, e.g. 3 or 6 months, and finally decide if you want to adopt it. 
At that time you can choose between continuing with the managed service or doing it yourself.
It is a zero risk trial of the technology and of the processes: if you don’t like, you haven’t wasted any time and effort to stand it up so you can happily retreat.
You simply do not renew the service contract and that’s all: you have made a real informed decision about the adoption of Openstack.

no provider lock in for your cloud

Cisco Metapod: Openstack as a managed service.

Cisco has a offer that allows you to do what I described above, that comes from the acquisition of a company whose business was exactly Openstack as a managed service, on your premises.
They had a Openstack distribution of their own, optimized and hardened to provide a smooth and effective service.
Now, thanks to a strong partnership with Red Hat, the team is using the Red Hat Enterprise Linux Openstack distribution (OSP8, based on Liberty).

The essential features of this service are:
- easy start: entry level contract for 90 days
- ready to go live in 2-3 weeks from the engagement
- HA included
- the infrastructure to run Openstack can either be yours or provided by Cisco
- both the Openstack API and the AWS API are exposed by the system

And the infrastructure to run it in production can be as simple as this:

the servers and the switches you need to run Openstack

The value you can get from it: a well defined SLA, installation included, maintenance and upgrade included, no cloud provider lock in.

advantages of the Cisco Openstack managed service: Metapod

I believe that Cisco Metapod is a very good option to start with Openstack.
You can put your foot in the water to test the temperature, then decide to take a bath if you like it.

you can decide if you like Openstack without investing in a big project


Openstack users survey 
Cisco Metapod official page
Cisco and Openstack on this blog