Can Scrum and CMMI live together?

TL;DR version – yes.

Many think that Scrum (and Agile in general) and CMMI cannot live together. After some years researching about that, my opinion is that this assumption is false.

Let’s keep things simple – CMMI is based on a binary process: planning plus execution. We have a (sometimes very) high level planning, each hierarchy level with its requirements and so on.

Can the execution phase keep on with that? It can – breaking down large features into smaller PBIs and then tasks is not something exclusive to Scrum but it can be applied to CMMI as well, with great results.

The Definition of Done as well can be integrated as a part of the CMMI Requirements and criteria, this is another simple yet effective example.

The CMMI Institute has a very interesting article digest on the topic – I really like this quote from the above:

As an Agile method, Scrum promotes frequent inspection and adaptation, teamwork, self-organization, and accountability. CMMI focuses on improving processes to improve performance.

And what about TFS? Well…all the tools are standard regardless of the Process Template, so the answer is obvious again.

How did I manage to get on well with Git

Having to deal with Git when you come from years of another Version Control System can be hard – I was very comfortable with the Team Foundation Version Control and in the rare cases I needed a distributed VCS my choice went to Mercurial.

I was very biased against Git, for several reasons. But then, after using it and dealing with it at work, I managed to find a position for it in my toolbox. Let’s see the reasons which made me accepting Git

Git is different

Yes, indeed. It was born with a specific purpose (VCS for the Linux kernel) and with a specific target in mind – kernel developers. Git is sometimes counterintuitive and not consistent, you have to learn it from the ground up without comparing it with other VCSs.
Despite it is a VCS, you can change the history of your source tree for example. You just have to understand that it is different, that’s all.

It is a great tool to be used with Team Foundation Server

Team Foundation Server is maybe one of the most interoperable product at Microsoft, and including Git inside it has been a marvellous choice.
You can have heterogeneous projects thanks to it, and even use it together with the TFVC if you want – with git-tf. And do not forget the migration capability – there are countless tools for migrating from other VCSs to Git.

It is lightweight and fast

Despite its steep learning curve, once you are familiar with the basic commands Git is blazingly fast and lightweight – thanks to its distributed nature.

These are the main reasons which led me to live with Git without fighting with it. I am still a learner on the subject though, maybe in the future there might be a revised version of the list. Let’s see

How to check for Team Foundation Server’s job running time

This is very quick but helpful IMHO.

Scenario: you are an external consultant and you need to run a job from the Team Foundation Server web services (ProcessWarehouse, just to mention one of them), but you cannot access the server itself because of some security policy.

You ask someone in the IT department to run it on behalf of you, but of course you want to check how long does it take. How?

By using the TFS Operational Intelligence. If you check the Job Queue list, you will get all the running and scheduled jobs for the server.

If a job is running you will get the actual running time, otherwise the last execution’s time.

Review – Professional Visual Studio 2013

Another year, a new IDE, a new book about it.

Do you want to compare it to the last year’s one? Fair enough – it is an updated overview of the Microsoft development stack. This is enough to justify it in full.

Bruce Johnson (Visual C# MVP) refreshed the 2012 one, covering a huge (1050 pages) amount of topics. Of course it is not a deep dive style book, it is not its target, but it gives the right amount of information on everything surrounds the core topic – Visual Studio itself.

To summarize in one idea: if you see something in the IDE, it is covered here.

Again at the end, Visual Studio Ultimate and Team Foundation Server are separately reviewed in order to avoid polluting the core stuff. A great choice I fully back, by the way.

It is a book every developer should have on the shelf, because sometimes picking up a specific chapter is better than just searching on the MSDN or a search engine.