Agile and Technical Complexity

This content is syndicated from [email protected]: Strategies for Scaling Agile Software Development by ScottAmbler. To view the original post in full, click here.

One of the scaling factors of the Agile Scaling Model (ASM) is technical complexity.  The fundamental observation is that the underlying technology of solutions varies and as a result your approach to developing a solution will also need to vary.  It's fairly straightforward to achieve high-levels of quality if you're building a new system from scratch on a known technology platform, but not so easy when there are several technologies, the technologies are not well known, or legacy assets are involved.  

There are several potential technical complexities which a Disciplined Agile Delivery (DAD) team may face:

  1. New technology platforms.  Your team may choose to work with a technology platform which is either new to the team or sometimes even new to the industry.  In the past few years new technology platforms include the Android operating system, Apple's iPad platform, and various cloud computing ( platforms.  Working with these platforms may require you to adopt new development tools and techniques, not to mention the need to train and mentor your staff in their usage.  Furthermore, your team may need to allocate time for architectural spikes to explore how to use the new technology and to prove the overall architecture with working code early in the project lifecycle (this is a DAD milestone).   
  2. Multiple technology platforms.  IT solutions often run on multiple platforms.  For example, a system's user interface (UI) could run in a browser, access business logic implemented using J2EE on Websphere which in turn invokes web services implemented in COBOL running on a Z-series mainframe, and stores data in an Oracle database, a DB2 database, and in several XML files.  Implementing new business functionality, or updating existing functionality, could require changes made on several of these platforms in parallel.  The implication is that you'll need to adopt tools and strategies which enable your team to develop, test, and deploy functionality on all of these platforms.  Testing and debugging in particular will become more difficult as the number of technology platforms increases, potentially requiring you to adopt the practice of parallel independent testing.  The Agility at Scale survey found that 34% of respondents indicated that their agile teams were working with multiple technology platforms.
  3. Legacy data.  IT solutions should leverage existing, legacy data wherever possible to reduce the number of data sources and thereby increase data quality within your organization.  Also, using existing data sources can potentially speed up development, assuming your team has a good relationship with the owners of the legacy data sources (sadly, this often isn't the case as the Data Management Survey found).  Working with legacy data sources may require improved database regression testing, practices, database refactoring practices, and agile approaches to data administration. The Agility at Scale survey found that 42% of respondents indicated that their agile teams were working with legacy data sources (personally, I'm shocked that this figure is so low, and fear that many agile teams are contributing to data quality problems within their organization as a result).
  4. Legacy systems.  There are several potential challenges with legacy systems.  First, the code quality may not be the best either because it was never really that good to begin with or because it's degraded over the years as multiple people worked with it.  You know you've got a quality problem if you're either afraid to update the code or if when you do so you have to spend a lot of time debugging and then fixing problems revealed when doing the update.  If the legacy system is a true asset for your organization you will want to pay off some of this technical debt by refactoring the code to make it of higher quality.  Second, you may not have a full regression test suite in place, making it difficult to find problems when you do update the code let alone when you refactor it.  Third, your development tools for your legacy code may be a bit behind the times.  For example, I often run across mainframe COBOL developers still working with basic code editors instead of modern IDEs such as Rational Developer for System Z.   Some of the strategies to deal effectively with legacy systems are to adopt a modern development toolset if you haven't already done so (better yet, if possible adopt a common IDE across platforms and thereby reduce overall licensing and support costs) and to adopt agile practices such as static code analysis, dynamic software analysis, and continuous integration (CI).  The Agile Project Initiation Survey found that 57% of respondents were integrating their new code with legacy systems and 51% were evolving legacy systems.
  5. Commercial off-the-shelf (COTS) solutions.  COTS solutions, also called package applications, can add in a few complexities for agile teams.  The packages rarely come with regression test suites, they often have rules about what you can modify and what you shouldn't (rules that are ignored at your peril), and they're often architected with the assumption that they're the center of the architectural universe (which is a valid assumption if they're the only major system within your organization).  As I describe in my article Agile Package Implementations it is possible to take an agile approach to COTS implementations, although it may require a significant paradigm shift for the people involved. The Agility at Scale survey found that 15% of respondents indicated that their agile teams were working with COTS solutions.  
  6. System/embedded solutions.  For the sake of simplicity, if your team is developing a solution with both hardware and software aspects to it then you're a systems project.  Embedded systems are a specialization where the system has a few dedicated functions often with real-time constraints.  Bottom line is that systems/embedded projects are typically more challenging than software-only projects -- it gets really interesting when laws of physics starts to kick in, such as when you're building satellites or space probes.  I highly suggest Bruce Douglass's book Real-Time Agility if you are interested in taking an agile approach to systems/embedded solution delivery.
The technical complexity faced by a project team is contextual -- Working with four technology platforms is straightforward for someone used to dealing with seven, but difficult for someone used to dealing with just one.

Recommended Reading:

Leave a Reply

What is 9 + 5 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”