Custom Development: The Evolution to Agile and DevOps

Custom Development: The Evolution to Agile and DevOps

/in , /by

The word “custom” sounds expensive—custom cabinets, custom-built homes, custom closets. That reputation is in part deserved, especially if you don’t do your homework up front to know who you were working with and how the project will be managed to ensure there are no “surprises.”

It’s really not too different in the world of custom software development. Many of us remember the 80s and 90s when excess was king, even for applications. Ever-expanding costs and missed deadlines were the standard and developers got a bad rap well into the 2000s for creating code that was vital to innovation yet in desperate need of effective controls. It was time to sober up and get mature. Advancements in the fields of software development with respect to project management, development, and delivery over the past several years have provided us with mature practices and tools with which to deliver better products within budget and time constraints.

Enter the Agile Methodology. In 2001, seventeen software developers met in Snowbird, Utah to discuss lightweight development methods and published the Agile Manifesto. No other methodology has revolutionized software development as much as Agile has. With Agile, requirements and solutions evolve through the collaborative efforts of self-organizing and cross-functional teams and their customers/end-users. The seventeen signatories wisely put forth their key values based on their combined experience in developing software and helping others to do that. In a nutshell, these values are:

  • Individuals and Interactions over process and tools
  • Working Software over comprehensive documentation
  • Customer Collaboration over contract negotiation
  • Responding to Change over following a plan

In other words, what we’ve learned from the past is that developers need a project management solution that enables better communication within the team, with the customer, and across process boundaries. At the same time, developers need a process that offers the flexibility to absorb the types of changes that have become ubiquitous in software development, such as misunderstood or incomplete requirements, changes in priority, and added or altered functionality that has already been written. Agile does this and has proven itself to be elastic enough to work in myriad environments and team configurations. While there still are valid reasons for other processes such as Waterfall, we are (as a whole) mostly using some version of Agile.

Another advancement in software development is modern DevOps (a compound of Development and Operations). DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. When applied to custom development, DevOps ensures developers and operations folks come together at the beginning of the development process (instead of at the end during testing) and stay in sync until the application or service is released in a production environment. This helps ensure every potential bug or new feature request is addressed along the way while removing the bottlenecks associated with legacy development practices. The key to successful DevOps is automation, and with the advent of cloud computing, Infrastructure as Code, and containerization, this is possible 100% of the time. Simply put, DevOps speeds up development and improves output quality without breaking the bank or killing your timeline.

A final nuance to consider when thinking about custom development is to ensure you are working with developers, not just coders. A coder is someone who knows programming language well and can bend it to his/her will to achieve the desired outcome. A developer is someone who understands the consequences of their decisions and how that will impact the overall system design. Unfortunately, developers are often faced with the dilemma of “just get it done” or “get it done right.” A coder will often surrender to the former while a good developer will ensure the latter.

So, if you’re considering a custom development project at your organization to spur innovation forward, make sure you’re working with true professionals that won’t cut corners, overrun your budget needlessly, and value collaborating with you, the customer.

At Xgility, we have a long track record of successful custom software development using Agile and DevOps methodologies, practices, and tools. Thanks to these advances, our teams embrace change within the development process using rapid iterations to reduce the complexity of the problem to be solved and delivering in a value-based, incremental fashion.

In fact, we recently created a custom development solution for a global insurer using Agile and DevOps methodologies and tools. We architected cloud-based solutions that employed App Services, Web APIs, Azure functions and other tools, and were able to quickly respond to and deliver bug fixes or new functionality in mere minutes. Using a shared-architecture approach, we stood up new products in weeks instead of months. In a competitive industry like insurance, getting code out to customers faster means beating the competition hands down.

To learn more about how we can help create a custom software development solution for your organization, more about Agile development, or simply to confirm you agree with me about coders versus developers, drop me a line.

How To Use Agile Email To Manage Customer Expectations

/in , /by

The Agile Development Methodology is a fairly well known, proven method for taking a large deliverable and breaking it down into smaller pieces (Sprints).  Then, using an iterative, incremental approach, each Sprint is completed in a relatively short period of time.  This allows the goal to be reached in tiny, flexible, responsive steps instead of one long, protracted assembly-line effort that typically takes longer and doesn’t allow for changes in requirements along the way.

That is an embarrassing oversimplification, but it lays the groundwork for a situation I found myself in recently.  Our teams use Agile when managing large development projects and our SharePoint teams use a modified agile approach in their SharePoint Center of Excellence Methodology.

In this case, I needed to interact with a particularly challenging customer.  I’ll call her “Gina” – not her real name.  None of my previous encounters with Gina resulted in a satisfactory result.  Miscommunications, misunderstandings, and misaligned expectations made encounters with her very stressful and always left me wishing I could find a way to successfully meet her requirements without things spiraling out of control.

I’m fairly skilled when it comes to communication.  I listen, I’m patient, I pay attention, I ask questions, and I try to make sure I understand the goal as well as the reasoning behind it.  But Gina somehow manages to push my buttons.  None of those things seem to work on my previous interactions with this customer.

Gina’s “requests” usually follow a pattern.  She stomps into my office (yes, she actually stomps) and comes to an abrupt halt at my desk.  With a stern frown, she demands that I deliver a specific result to her, immediately.  Usually, she does this about 3 minutes after having sent me an email with the exact same requirement spelled out in conflicting detail.

I realized what I really needed was a new communication tool.  I decided to create my own, which I call “Agile Email.”

I was actually reading Gina’s email when she made her customary appearance at my desk.  After she announced that she had just sent me an email, but before she could begin making any demands, I immediately thanked her, informed her that I was reviewing that email right now, and that I would respond as soon as I had a chance to finish looking it over.

It took more than that to get her to go away and give me time to read her email, but once she left I decided it was time to change the way I handle her requests.

My approach was very simple, and surprisingly effective.

I began by assigning a number to each and every request, demand, or requirement that she listed in her email.  She actually had started doing this herself, but was inconsistent in breaking out each item, some items didn’t have any numbers, and some of the numbers were out of order.  I corrected those things and began my reply.

This is where the simple magic came in.  All I did, over and over, for the next few days while we each hit Reply and Send, was to only provide status updates on the numbered items.  No other comments.  No additional information.

I always copied the numbered items to the top of my reply then responded directly to those things.

I gave her status, I asked questions, I provided clarification.  But most importantly, once I indicated that I had completed a numbered item I asked her to confirm.  Once she confirmed I NEVER referred to that item again for the remainder of our email conversation.  NEVER.

All subsequent replies that I made only referenced the remaining (open) items on the list.  I continued to give her status, ask questions and provide clarification, but only on the tasks that I had not yet completed.

This had a very interesting series of effects.

  1. I was able to focus on just what needed to be done
  2. My questions would often uncover a need to adjust the requirement and the deliverable
  3. She was getting what she asked for and was agreeing (in writing!) that I had given it to her
  4. The list kept getting smaller

At one point she latched on to two items that could not be resolved.  Both were due to scope creep.  One due to her misunderstanding, the other due to her wanting more than I could give.

Due to the extraordinary detail in our email thread I was very easily able to route her remaining concerns to my manager.  He promptly informed her that we had fulfilled (and actually surpassed) her original request, and that her supervisor was welcome to contact him directly regarding any additional concerns.

I realize this approach isn’t really all that amazing.  It’s not even a complete Agile method.  But it sure was effective!

  • Break down the request into small, Sprint-sized bites
  • Focus on just what needs to be done
  • Provide frequent status updates
  • Keep asking questions
  • Adjust your approach to meet any changes that come up
  • Get confirmation when you’ve completed something
  • Let completed items “fall off” the list
  • Bring the open items to the top and keep working on them
  • Don’t let scope creep prevent you from fulfilling the original request
  • Let upper management cover your back

 

If you would like more information, please contact us.

 

Author: Jeff Hepner

Editor: Alex Finkel and Kurt Greening