It’s Ok to be Agile-ish

In today’s competitive business climate, the “need for speed’ in unparalleled and widely acknowledged.  Many organizations have embraced agile transformations and are moving on to setting up DevOps teams and practices.   Most organizations that have not engaged in an agile transformation have implemented some form of agile methodology or attempted to “go agile” in some way are feeling the competitive pressure to consider it.

The Complexity of Agile Transformation

Agile transformations are complex, costly and time-consuming.  Employees need to take on new roles and learn new ways of working.  This requires training and potentially learning new skill sets.  New teams are formed and they will storm and norm and then hopefully perform.  New infrastructure and tools will be needed and those may require a significant financial investment.

A true agile transformation involves more than implementing new methodologies, processes and roles.  It is based on a culture transformation and changing culture is probably the most difficult initiative an organization will ever undertake.  An agile transformation must be approached from the top down; senior management must not only endorse but more importantly, they must lead by example.

In some verticals, the very nature of the business imposes impediments to agile transformations.  Organizations in regulated industries such as medical devices, pharmaceuticals and utilities find implementing agile methodologies especially challenging given the heavy testing and quality control documentation required of them.  Organizations whose products have safety critical components must adhere to strict quality assurance standards which require allocating time for full, non-risked based testing.  These organizations may find the pace of agile methodologies to be at odds with their quality standards.

Being Agile

With all the complexities and challenges of an agile transformation, the question becomes, is it possible to achieve agility and its benefits without full agile transformation?  Let’s answer the question with a question; what is agile?  Agility is the ability to move, react and change quickly.  It is not only about methodologies and processes but more importantly, it is a philosophy and approach to software development.  Agile philosophy is summed up succinctly in the manifesto and explained in the twelve principles.

The agile approach as well as its methodologies and processes are based on agile philosophy.  Agile is an approach to responding to the unpredictability of developing software by using small, self-managed teams to build software incrementally.  Builds are timeboxed and developed in successive work sequences or iterations.  Most importantly, functionality is delivered by feature and each feature is broken down in its smallest components.

Agility without Agile Transformation

It is definitely possible and a really innovative idea to take an agile approach to software development regardless of the development methodology espoused by the organization.  Any organization can move toward agility by implementing agile practices.  Let’s look at some agile practices that can be integrated into a traditional waterfall systems development lifecycle approach.  Agile practices can be introduced throughout the SDLC, especially in planning, project management and team development.

Let’s start with requirements development.  Break down requirements into the smallest increments possible. This shifts the focus from long term planning to planning for the results that are needed quickly.  Develop and maintain a prioritized backlog of streamlined requirements or user stories which allows for changing priorities easily.  And why not experiment with different estimation techniques to improve estimation accuracy?

Lots of agile practices can be implemented easily into project management. Shorten release cycles as much as is practical. This approach allows time for bug fixes, reduces technical debt, improves quality and increases speed to market.  Apply the concept of developing “Minimally Viable Products”. These are products with just enough features to satisfy requirements.  These products improve speed to market and they are faster to code and test.   Implementing frequent demonstrations of new features provides early feedback.  This means misunderstandings in requirements are caught early, decreasing costly design errors and rework.  Finally, implementing fixed timelines with variable requirements increases flexibility by allowing less critical requirements to be moved to the next release.

Another approach to begin the journey toward agility is to bring agile practices to your teams.  This is a great way to begin a culture shift in a non-threatening way.  Start by implementing daily standup meetings.  This increases transparency and gives everyone a shared understanding of the project status. Use a whiteboard with sticky notes to manage tasks and issues to increase transparency and visibility of the teams’ progress.  Try pair programming and/or pair developers with testers to facilitate the sharing of knowledge and enabling a truer understanding of each other’s roles.  Finally, champion continuous improvement by implementing retrospectives after each release.

The key to agility without an agile transformation lies in implementing the agile practices and processes that not only work within your organization’s culture and constraints but provide value by increasing speed to market and increasing quality.  Many successful organizations are agile-ish and that’s ok.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s