I have been working with the Jenkins build management system since last July and helping our internal Java, iOS and some .NET development teams to implement Continuous Integration. The objective is to also coordinate their builds with SonarQube so we can get cross-collection visibility to status in some projects that span multiple teams.
Microsoft has recently released the ability to have Jenkins builds in VSO through service hooks:
If we had this for TFS on premises a year ago we might have followed a different route for our Jenkins/SonarQube implementation, as it is the composite report of all our application builds and deployments (through pipeline statuses) that we are mostly interested in.
For my own work in the cloud I have been using the new fantastically flexible new Build.vNext system. And that composite Build/Release report: you get it almost effortless if using VSO/Azure, in contrast with our current solution which is manually intensive.
Let’s see how our work evolves. I will be looking at this again, specially if it makes into TFS on premises in the near future.
ScrummerFall, WaterScrum, WaterScrumFall: over the years, and as recently as last month, I have seen many referring to these Scrum "aberrations" as if being the same. Here is it for the record, what each one means:
- ScrummerFall: "embedding Waterfall inside of Scrum. This often manifests in what I call the One-Two-One pattern: one week of design, two weeks of coding, one week of test and integration. I've yet to see a team that was long term successful with such a system, especially if they are strongly rooted in historical Waterfall." Aaron Erickson calls it the World's Worst Software Development Methodology. But in my opinion it is so because it is unethically deceptive: it promises renewal, but built on top of a complete mirage of Agile adoption. Picture it this way: it is as if you are thirsty for a fresh flow of Agile ideas in a "Waterfall" desert, and as you get closer it disappears as you slams your face in the sand.
- WaterScrum: "Co-dependent Waterfall and Scrum projects. Similar to trying to play (American) football and soccer on the same field at the same time, requiring extra levels of coordination and timing." That is, you are trying at the same time to abide by Scrum at the team level, and Waterfall at the corporate level.
- WaterScrumFall: "1) Water – Defines the upfront project planning process that typically happens between IT and the business. 2) Scrum – An iterative and adaptive approach to achieving the overall plan that was first laid out in the 'Water' stage. 3) Fall – A controlled, infrequent production release cycle that is governed by organizational policy and infrastructure limitations."
ScrummerFall and WaterScrum, are in reallity team dysfunctions caused by lack of experience in Agile. They can be fixed at the team level by a good Scrum Master or Agile Coach who can guide the team towards optimized, clean Agile practices.
On the WaterScrumFall, Manoj Sanhotra found some silver-lining by using it for incremental adoption of Agile practices, and even proposed a way to take it to the next level. The picture below is from his post, and it explains graphically what the general idea of WaterScrumFall is:
But as Dave West said, this is still the development processes of most companies, and has in my experience been the most frequent source of friction when adopting Agile. From what I have seen at 100 plus customers, Agile teams tends to end up stifled and suffocated with bureaucracy and controls created by all the hand-offs between the silos. In all my years working with ALM, centralized PMO and QA teams have been both the last mile of Agile adoption everywhere I have been. I however do not agree with Sanjeev Sharma that WaterScrumFall is here to stay.
WaterScrumFall stems from confusing Governance phases with Execution steps. Some have tried to fix this situation at the PMO level by adopting an Agile Portfolio Management strategy, others by adopting a DevOps oriented approach QA and Deployment.
Scale up frameworks such as SAFe, and Enterprise Scrum focus on optimizing from PMO to Operations. The only frameworks I am familiar with that handle this optimization from idea inception are Lean and Nexus, because it is the business itself that has to become Agile, and until that happens, the "throw-it-over-the-wall" handoff attitude will continue to exist among the fiefdoms of modern enterprise.
Paul Barham from Microsoft wrote an article about how Visual Studio Online Supports True Cross-Platform Development. As I had mentioned in a previous blog post, this has been a nice new trend coming from Microsoft as they expand cross-platform capabilities, enhancing the usage of VSO for big enterprise with heterogeneous environments. Notice the list of available service hooks:
The article does a brief summary of the many ways that VSO enables cross-platform development, from using git as the source control format, and thus supporting, for instance, XCode, to allowing different build systems such as Jenkins to enable Continuous Integration to getting it all tied together and traceable using a Team web backlog.