Questions about continuous agile from the viewpoint of a big financial services enterprise

A person who works at a big financial services company wrote: I very much enjoyed Andy Singleton’s presentation last Wed [about continuous agile with FCB] … I would love to get Andy’s response to these:

1) I would like to learn more about what he meant by ‘eliminating management’ in the Continuous Delivery environment

2) I would have loved to hear what process or procedural changes companies have to undergo when they adopt a continuous delivery and implement smaller agile sprints. If I recall correctly, Andy suggested testing becomes critical and teams need to be ready to do a lot of testing on the spot! What happens when teams are not in the same building/city/continent?

3) What suggestions do you have for companies encumbered with many disparate legacy systems and a poor experience with Agile?

1) I think I said “automate away layers of management.” Obviously, management is important and valuable. But, I think that it is possible to automate away much of the work that human managers do. This is especially true for work that humans find confusing at scale, like dependency management — organizing projects so that people get what they need, when they need it. If you use the ideas in SAFe, then you end up with a lot of people doing this work. You have extra layers for program management, plus you have people doing “scrum of scrum” type peer to peer negotiation. You can skip a lot of that work if you do continuous integration between all of your services. The CI system is essentially a big machine that checks to see if there is a dependency problem. If there is a problem, the machine can notify the relevant team leaders, and those people can work it out. It’s a simple and brilliant solution to the Mythical Man Month problem.

I should also noted that a modern DevOps system gives developers responsibility for monitoring and fixing production systems. A lot of things get fixed as just part of a sense-and-respond reflex, so those things don’t need to go through planning and management. This is a double win- faster response, and less management work.

2) Good question. I specifically became interested in continuous methods because they are better for distributed teams. They require fewer meetings. Our mission at Assembla is to support distributed teams, and we practice this ourselves, with 40 people working in 12 different countries. Actually, there are two reasons that I think the continuous methods are better for distributed teams:

• Fewer meetings
• Everyone is working on the same thing. You have fewer branches and versions. This is very important for unifying the team

For us, testing is not an obstacle to working in distributed teams. The main testing loops can all run asynchronously. For example:

• Code review- often with a local buddy, or team of 3
• Automated tests — run whenever changes are made
• QA consulting — human QA person is called in to check something for a developer. This should go on a ticket/issue so that the QA person has a place to write the result and recommendations.

The process that I would use to move from sprints to continuous does involve building up the continuous and automated test workflows.

• Scrumban, where you skip the sprint plan. You pull tasks when ready, release them into the test system, and then run a feature-freeze and stabilization phase to get a tested release.
• Incrementally improve automated and on-demand testing for the test system. There are some specific tactics for this: 1) continuous integration 2) code review, so that you can ask for tests; 3) build automation; 4) transferring the release decision from QA to developers; 4) more test layers (which now your developers are motivated to maintain).
• When all of these things are working well on your test system, you will be in a position to do releases on-demand without the stabilization phase

Another way to look at it is just to “release more frequently” and incrementally improve. It’s always possible for your team to figure out how to incrementally shorten the release cycle. Your team will adopt similar tactics, but they might do it in a different order. I do workshops with teams to help them figure this out.

3) I’m not a big fan of “agile transformation”. As a CEO myself, I would hesitate to push something like that on my own organization. I look for incremental improvements, such as the “release more frequently” theory. These incremental improvements can add up quickly and convincingly. I also think that it’s important to respect the mission of each person in the organization. In my presentation, I noted that a lot of IT people work on “Core IT” and have a mission for reliability and security. It might not be practical or appropriate to try to persuade those people to make frequent and rapid changes. However, every organization also has an increasing amount of “Fast IT”. These are mobile, Web, SaaS integration, and digital marketing projects that run on a much faster cycle. Mobile apps use an API to access core systems in a non-disruptive way. In a services architecture, Core and Fast can exist harmoniously. You slap an API on the core systems, and include them in the continuous integration as part of the integrated set of services. Then you move more and more of the action into the Fast zone. This is happening naturally as people move systems to cloud architectures. The legacy systems stay in place with API’s, but the cloud systems will be built with continuous methods.