While continuous deployment implies continuous delivery the converse is not true. Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle – that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes. [...] In the world of continuous delivery, developers aren’t done with a feature when they hand some code over to testers, or when the feature is “QA passed”. They are done when it is working in production. That means no more testing or deployment phases, even within a sprint (if you’re using Scrum)...

The first obstacle we reached when we were setting up our continuous delivery pipeline was figuring out which branch to continuously deliver. We changed our minds a few times before settling on a pipeline that would run all the code from the development branch. Except production, that is, which would deploy from master. This was always a bit confusing and didn't make a whole lot of sense. The idea with git flow is that master always represents production while develop represents the current state of development. The idea of continuous delivery, though, is to reduce the time between what master represents and what develop represents. In the ideal case, develop and master would converge. These worldviews clash quite spectacularly when tried to use in conjunction.

The iteration is a cornerstone of agile development. It provides a heartbeat for the team and its stakeholders, and a structure for various routine activities that help keep development work aligned with what the customer needs. However, the way many teams run their iterations creates serious pitfalls which can keep them from delivering software as effectively as they could.

The orthodox approach to the iteration is to treat it as a timebox for delivering a batch of stories, which is the approach most Scrum teams take with sprints (the Scrum term for an iteration). In recent years many teams have scrapped this approach, either using iterations more as a checkpoint, as many ThoughtWorks teams do, or scrapping them entirely with Kanban and Lean software development.

Innovation may slow at public companies because IPOs trigger “brain drain” as employees cash in their holdings, the study suggests. By tracking about 13,000 of the inventors named in patent filings, Bernstein found that they were 18% more likely to leave after a company went public. Meanwhile, those who stayed behind produced inventions that were less valuable than before, receiving on average 48% fewer citations per patent.

The basic idea of story branching (sometimes referred to as “issue-driven development”) is that you create a development branch for each and every JIRA issue you implement.

Bug fixes, user stories, spikes… they all get their own branch.

Madness, you say!

And I would agree with you if we were still using a centralized version control system like SVN.

But branching in Git is very lightweight and merges don’t lock up the entire repository, making this crazy idea quite practical.

Teamwork and collaboration are critical to mission achievement in any organization that has to respond quickly to changing circumstances. My research in the U.S. intelligence community has not only affirmed that idea but also surfaced a number of mistaken beliefs about teamwork that can sidetrack productive collaboration. Here are six of them.

Many people who have managed projects with hours have a hard time understanding why story points are better. They have failed to understand some fundamental data that has been published for over 20 years in the industry literature as well as the latest research.

First, let's look at the latest data on project failures. Failure rates are increasing for IT projects during the current disruption of the global financial system. The latest Standish group analysis shows that agile projects have three times the success rate of traditional projects. Jim Johnson now recommends agile practice be used universally on all projects.

TeamWall will display only the important information your team needs on a big screen. It rotates through all of them and one can jump to a specific one if needed. It’s display is designed to be readable from all across the room by all team members.

TeamWall is a great tool for your team of programmers to get condensed information about your code base. It integrates with data providers like Sonar, Jira or Teamcity to get the information you need.

Many development teams are used to making heavy use of branches in version control. Distributed version control systems make this even more convenient. Thus one of the more controversial statements in Continuous Delivery is that you can’t do continuous integration and use branches. By definition, if you have code sitting on a branch, it isn’t integrated. One common case when it seems obvious to use branches in version control is when making a large-scale change to your application. However there is an alternative to using branches: a technique called branch by abstraction.

Evidence has long shown that getting a group of people to think individually about solutions, and then combining their ideas, can be more productive than getting them to think as a group. Some people are afraid of introducing radical ideas in front of a group and don’t speak up; in other cases, the group is either too small or too big to be effective.

But according to a recently published study, the real problem may be that participants’ [sic] get stuck on each others’ ideas. On Monday, the British Psychological Society highlighted a recent study by Nicholas Kohn and Steven Smith, two researchers at the University of Texas at Arlington and Texas A&M; University. [...] As expected, the “nominal” groups, or those made up of individual ideas that were later pulled together, outperformed the real chat groups, both with the number of ideas and the diversity of them.