A featured contribution from Leadership Perspectives, a curated forum for enterprise technology leaders, nominated by our subscribers and vetted by the CIOApplications Editorial Board.
USCIS
What does it Mean for a Development Team to be Agile
Most teams begin the journey to agility by adopting proven methodologies such as Scrum. Mature Scrum teams work the software test and build processes. This is a good start but it will get you only so far, as Scrum is punctuated by too many ceremonies – a sprint planning session, daily stand-up, sprint review, and retrospectives. This works Ok when a team is releasing every 2-4 weeks but becomes burdensome when they try to release more frequently.
The daily stand-up itself is another problem. The classic Scrum guidance is: What did I do yesterday?; What do I plan to do today?; and What are my blockers? This is a good place to start but, over time, it usually makes for a very boring and pro forma discussion. If the team is communicating effectively throughout the day then team members should already have a good sense of the work that is done. And if you are waiting until the daily stand-up meeting to raise a blocker then something else is wrong.
More important, as test and build processes become more efficient and user stories, features, units of business value, or whatever you call them get to done faster, it becomes natural for product owners and other team members to ask why deployment should wait to the end of the sprint. The simple answer is that work that is done should not wait at all.
For this reason, more seasoned agile teams often move away from Scrum to Kanban as a working process. Some teams begin by adopting a hybrid of Scrum and Kanban, often called ScrumBan, until they are more comfortable with the Kanban process – but let’s ignore that.
Why Kanban?
Well, for starters, Kanban is a continuous flow process that encourages team to work a very limited number of stories until they are done. It does this though Work-In-Process (WIP) limited for each stage of development. Properly executed, WIP limits allow teams to focus, eliminate task switching delays, and swarm on tasks to get each story to done as soon as possible. This leads to more frequent deployments. In fact, it is not unusual for well-run Kanban teams to deploy new features every day – and often several times each day.
Most agile teams automate functional testing early on but, in order to deploy daily, many teams find they must also automate code quality testing, security testing, and other testing required to ensure successful deployments.
Kanban also makes the daily stand-up meeting more productive. Scrum stand-ups tend to focus on people; Kanban stand-ups focus on work on the board. Since attendees can see the stories that have advanced, there is no need to discuss work progress. If the board has a lane or some other visual indicator for blocked tasks – as it should – then that should be evident too. Well-run Kanban stand-ups focus on work that is closest to done, work that has been on the board longest, and work that is ready to start next. The whole focus is how to advance each item on the board to get to deployment.
Unfortunately, Kanban is just one step on the road to continuous integration and deployment success. What are some others?
Well, teams usually need to invest in a much broader range of automation practices. Most agile teams automate functional testing early on but, in order to deploy daily, many teams find they must also automate code quality testing, security testing, accessibility testing, and other kinds of testing required to ensure successful deployments.
Next, development teams must fully automate the deployment process. This goes beyond software builds to provisioning for the target environment – often building a new production environment from the ground up. This is especially handy when a team is working zero downtime deployments using the blue-green deployment method. This is an approach where a release is provisioned to a new environment where databases are synced up, followed by changes to domain name services for deployments that are transparent to end users.
Another technique that continuous integration projects can employ to speed up development is to break up monolithic applications into functional pieces. This ranges from presentation layer affects such as cascading style sheets to an entire option for the end user such as updating account information. Most Web applications are designed this way from the start but more mature teams often work to pull functionality common to many applications out into micro-services. Common examples include a ZIP code lookup and validation function or password reset; instead of writing these functions for each application, why not write them once and make them available as a service to any application that needs it?
In addition to quick deployments, there are three other attributes that distinguish high-agility teams:
First, high-agility teams actually do respond well to change. They are able to accept new requirements that arise during development with a minimum of delay. The Kanban methodology and short lead times to deployment facilitate this but it still requires a significant cultural shift.
Second, they are not only able to defer low-value changes indefinitely, but regularly groom their backlog to remove items that have lain dormant for too long regardless of how promising they may have seemed before.
Finally, they pay attention to faint signals and other signs of trouble, act quickly to resolve them, and use all information available to continuously improve development. If you want to learn more about our work in this area, you may want to review the talk we gave at the DevOps 2018 conference in Las Vega.
