As an Agile Leader, ScrumMaster, Product Owner, Agile Project Manager or Engineering Manager your hardest mountain to climb remains the road to Agility from Chaos.

The state of Chaos provides a great sense of creativity to many individuals.  And there is some truth to the notion that chaos births innovation.  In the reading that I’ve done and the experience that I’ve had, creating valuable applications that meet a need result from a careful study of customers and users rather than having a creative, chaotic brainstorming development team.

In fact, most of the customer that I talk to already live in chaos in that their teams work on the most urgent thing put in front of them.  Teams that work like this can suffer from never achieving strategic goals or, in the best case, seldom achieving strategic goals. Often the chaos of creating the latest cool idea get’s absorbed by an urgent customer request.

This article provides tested methods for making sure a development team creates both tactical value (today’s urgent need) and strategic value for customers or companies.  I categorize strategic development as the following: internal infrastructure needing updating, old applications requiring modernization, refactoring around the axis of change or strategic new products needed for company growth.  Typically “modernization,” or reduction in “technical debt” are hard to achieve under the chaos paradigm because planning, estimating and executing don’t have clear boundaries, so strategic items always get trumped by the “hottest” issue.

The following tips enable teams and organizations to develop on a more predictable timeline by understanding the velocity of the team and thus allow the team to figure out if they have appropriate staff to achieve both tactical and strategic goals.

1. Create a Timebox

Working on the most urgent item rather than the most important thing (e.g. firefighting) remains the biggest challenge when trying to transform an organization from Chaos to Scrum.

No matter what else happens, the sprint timebox needs to be established and agreed upon by the organizations’ internal and external customers.  For the organization I’m in, the timebox was a very distasteful concept for our internal customers.  They were used to a high paced constant delivery pipeline that produced things on-demand.  The downside for this organization was two-fold: 1) no test environments 2) very little strategic development.

The transition from Chaos to Scrum required deal making in the form of “If there is an outage, it get’s solved immediately. But if it’s a development item, then a story gets created and put into the backlog and planned into the next sprint.”

For particularly Chaotic organizations, a sprint cycle of 2 weeks might stretch the patients of the customer to her acceptable limit.  Three weeks could result in a no-go.  For teams that undergo turbulent input from their customers, and though it might be painful, one-week sprints could work to keep things turning fast enough to control the chaotic input, produce results without too much delay, and result in a satisfied customer.

2. Enable Production Delivery

In the midst of creating strategic applications or infrastructure, the team does not abandon the tactical.  Customers, whether internal or external, require that the “show must go on.”  Just because you are engaging in transformational activities does not mean you close Boardway.

The backlogs must include the following.

• Continuous integration tooling to perform automated build and deploy

• Automated test technology

• Secondary deployment environment in which to test the whole system (e.g. User Acceptance Test or Integration or Production Standby or Blue-Green Deployment)

Gosh, that sounds like a lot if you are starting from zero.  In this day and age, it’s highly unlikely that an organization is starting from scratch.  If you are in that situation, then you have lots to learn and the transition requires more time and pretty steep education curve.

3. Always Deliver

When a team feels they have the daunting task of refactoring or evolving their current technology or processes into a new design or modernized system they often feel like the work requires long periods of development time and deliverables seem out of the question for weeks or even months.  As an Agile Leader, you need tremendous courage and patience to walk through the agonizing process in Step 4.  For right now, the team needs to understand that a sustainable pace as a transformation goal requires consistency in delivering value to the customer. Consistency in delivering even small things every sprint results in happy customers and a mechanism to improve the environment.   When teams and customer alike begin to find their stride with consistent quality deliverables, the team gets breathing room, and the customer finds satisfying incremental value.

4. Decompose the Scrum Backlog into Small Chuncks

Of all the task a scrum master, product owner or agile leader must perform, the job of coaching a team to deliver in small chunks ranks among the highest.  Software developers who have habits of working on something for lengthy periods of time without a release or integration test find it hard to break apart deliverables creatively.

Developers don’t resist small stories when surrounded by a nimble architecture, in fact, they embrace incremental change and delivering every sprint.  And when it comes to refactoring, a flexible architecture creates a runway to eradicate technical debt.

But when architecture changes require old and new infrastructure side-by-side developers find this highly annoying.  And they are accurate.  Sustaining old and new architecture or half-refactored code in a production system can pose some rather inefficient design choices.

Lessons learned from treading this difficult road are long-lived and guide the developer to see the axis of change.  The nimbleness of the architect succeeds or fails based on how well the application architecture accommodates the axis of change.

As an Agile Leader, you must insist and help teams decompose the most difficult backlogs into single sprint production ready chunks even if you must endure pain and long conversations.  In this situation, you demonstrate the character traits of the agile leader: Courage, tenacity and servant leadership.

5. Iterate and refine

Retrospectives keep you learning and changing behaviors in a positive direction.  If you feel pressed for time and don’t schedule retrospectives, you will not profit in the long term.

STOP.  Book at least one hour on the team’s calendar at sprint end and use simple facilitated retrospectives to help move forward.

Keep it simple by only attacking a single item per sprint.  Don’t create a long list of things that will never get done.   Take only the highest priority issue and bake it into the sprint backlog.

Bottomline: As an Agile Leader grit your teeth, work with individuals, team leaders and software developers to break down stories.  Use every ounce of your creativity, technical knowledge, and excellent interpersonal skills to move individuals toward small backlog items and consistent delivery. They payoff supplies your team confidence, and your customers’ belief in your effective agile transformation will blossom.