Skip to main content

This article is part 6 of an 8 part series of the Agile Mindset. All 8 principles work together to ensure that you are able to implement an agile framework successfully. You can read part 1 here.

Regarding Change

One of the core reasons why the agile manifesto was developed was to better deal and allow for change in development efforts. As technology advances improved, the ability to change things mid-stream grew with it. When computer programs were first written, the actual computer was shared among a variety of people and access was limited. This was back in the day when punch cards were used and the computer was actually the size of a large room. Because time and access was limited, traditional approaches to software design made sense. Things had to be built completely before you could actually run the program and test it in the shared computer.

For an in-depth history of the computer and all the challenges that yielded a traditional waterfall methodology read up on it here. Also, you can read up on the original paper that outlined the waterfall methodology by Winston W. Royce here (it’s fascinating that even Dr. Royce stated that this methodology is prone to a lot of risk and failure).

A shift in technology

But, when technology became more accessible, and development efforts became more efficient, people were able to see results sooner. This change in the development and technology environments outpaced our ability to frame a process around it. Thus, we continued to use a traditional waterfall method when it no longer made sense given the technology context. The ability to change became more and more important. To address this difference, the agile manifesto was introduced so that we could incorporate and manage change in a value-driven way.

The second listed principle of the agile manifesto states this,

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

All of the frameworks within the Agile umbrella exist to manage and deal with change. Change is literally part of the process.

Change and You

So, if change is part of the process, where does that leave the individuals that are working on an agile team? Well, the best way to deal with change is to be able to change yourself. That is why the last principle of the agile manifesto states,

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Continuous improvement is the means by which change is facilitated by people. If you are not continually improving, you are becoming a human road block. You are going to hate your work, annoy your team, and slow things down. Additionally, if you are on an “agile” team where continuous improvement is not happening, the process will feel meaningless and empty. The team will never reach its potential, and will never become an asset to the business. This is where developers feel like code monkeys, analysts feel like order-takers, and days are long.

Tips For Continuous Improvement

The first thing to know is that continuous improvement doesn’t come naturally. Maintaining your comfort is the status quo of the human condition. Improvement takes work, and work takes discipline. However, you can become better and it might even be an enjoyable process. Below are some tips to help you improve.

Forget Goals; Create Systems

People break goals all the time. They are lofty aspirations, but insufficient to produce change in behavior. Also, this idea isn’t new. Its been around and featured on various blogs and platforms. From my personal experience, the only goals I’ve been able to reach are the ones where a system exists to achieve them. This seems like common sense, but the majority of us still don’t get it.

Do a Self Inventory

You can’t improve if you don’t know where you stand. Do you know where you are weak? Where do you fall flat? What one thing would you like to improve?

People re-invent themselves all the time. You can make yourself a little better, but you need to do a self-inventory first. Once you’ve identified things that you can improve on, you need the courage to start. Just pick one thing and start on that. Don’t like public speaking? Go to toastmasters and take a course. Do you have deficiencies of understanding with concepts at work? Get a tutorial or book about it and study up. Along with your self-inventory, identify some small steps for improvement. Completing these small steps will boost your confidence. With larger amounts of confidence in the unknown, you can take larger steps towards improvement.

Constantly Learn

One of the keys to continuous improvement is to constantly be learning new things. Go to conferences, meetups, read articles, follow news and developments on an continual basis. You can’t know where you stand if you never know where the path leads. Learning new things and seeing new ideas gives you a direction. Continuous improvement, in the context of agile frameworks, assumes you have a direction in mind.

Don’t Got it Alone

One of my goals that I’ve had for a while was improving my health. In the last half of last year, I decided to become more healthy by trying a rowing sprint. I shared the results with my friends at work and continued on another rowing sprint. Soon, over time, sharing my results led to a sort of accountability.

At the end of the year, my goal amplified with our new health insurance program at work that encourages the use of a fitness tracking app. On that app we can all see each other’s fitness activities. This friendly mutual accountability increases my continual improvement in health.

So, the takeaway here is that networking with others on trying to improve yourself gives you the extra motivation to keep going (even when you want to quit).

Final Thoughts

Continuous improvement is a vital component of agile frameworks and agile teams. Individuals should be improving themselves and by extension their teams. The team should be improving the product and process over time. The business should be improving their customer’s reach and relationships, culture, and environment. When these things happen, by volition rather than force, everyone wins.

David Bjarnson

David is an agile practitioner for 6 years in various capacities working specifically on software development for a number of different companies. David has his CSM, CSPO, CSP-PO, CSP-SM, and PMI-ACP certifications.

One Comment

Leave a Reply