Tag: best practices

  • Managing Upgrades and Software Versions

    Managing Upgrades and Software Versions

    Managing upgrades is something we all face. That. is true whether you are running your software in your house, at a small business, or for an enterprise. There are versions released regularly as often as quarterly, and sometimes we get the new version “free,” sometimes not. There are many things to consider when crafting a version roadmap for your software. Here are some things to help with that. These suggestions and warnings come from a broad experience with software and highlight some paths that can make your life easier.

    Managing Upgrades Through Major Versions

    The “old school” approach to managing upgrades was often made via major versions. Software companies would release a major version every year or so. Then you would take the time to get up to date. That approach quickly morphed into a leapfrog approach for many companies. The disruption of performing upgrades and costs of installs were enough that the benefits were often not worth the effort. There were also licensing constraints that made an “every other version” approach much more effective in time and cost.

    That approach is an excellent model for planning a version roadmap. There is always a cost to embracing/installing a new version. Often it works better for us to take on more changes less frequently rather than smaller changes more frequently. This approach also gives plenty of time for changes to “bake in” to the organization. Thus, allowing processes to evolve to embrace new features.

    Managing Upgrades Through Features

    Software used to promise needed features with every release. However, we have moved to a world where features are driven more by internal needs than marketing bullet points. Many organizations are content with staying on a version for years. These organizations prefer stability, and an upgrade tends to be large and feature-rich. That sometimes includes a push to move off of a version that is no longer supported.

    The risk with the above approach is running out of time before a release is unsupported. Likewise, the resources and upgrade paths can be limited. Less frequent upgrades can lead to much more complex paths and can put data at risk. Some applications go through “watershed” upgrades that require a significant data migration effort. Those typically require the users to be on a specific version before the migration is done rather than skipping through multiple versions.

    Obstacles and Road Signs

    The approaches listed are both valid, and either may be a perfect fit for your organization. We have already touched on some things to look out for. However, it is good to have a list to walk through in planning out your approach.

    • Be aware of watershed releases – When you have a release that will effectively be incompatible with prior versions, that can often be a “need to upgrade” marker.
    • Store Version media or packages – There are combinations of software required for a version that can become difficult to replace. Vendors move forward or may even cease to exist. Thus, it can be critical to access prior versions of software and even operating system tools when you delay your upgrades.
    • Know Your Features – I have found that it is rarely a good idea to take an upgrade just because it is available. While there is risk involved, there is also the factor of utilization. It is important to know what your software can do, and blindly upgrading can miss out on valuable features. Invest the time for reviewing release notes and training updates when available. This investment can pay for itself quickly and inform you of whether future upgrades are valuable or not for your needs.

    The Cloud Factor

    Software as a service and the Cloud can make these types of issues seem a thing of the past. However, even SAAS products have versions and upgrades. You might be in a situation where you can hold off on a version upgrade for a while, but that is rare. Even in those cases where you have a “choice,” it often is presented as a preview you can embrace sooner rather than later. While you lack choice, there are still actions you can take (and should) as part of your upgrade strategy.

    • Take advantage of backup options where possible.
    • Use and verify export options where possible. It is your data, make sure you have access to it outside of the SAAS product.
    • Keep current on planned upgrades, enhancements, and outages.
    • Plan for some time to test and verify updates.
    • Embrace the latest features as suitable to your needs.
    • Avoid company critical periods of work that coincide with a maintenance period or upgrade.

    The good and bad part of a SAAS product is that you are not responsible for the workings of that product. A lot of the management and administration tasks are taken out of your hands. Nevertheless, the steps above can help you mitigate risk at the cost of taking some of that management back on yourself. It is worth that trade-off. You will be happy to have a way to take your data elsewhere when a product becomes unusable, or a provider closes shop.

  • Resilience – A Strong Metric

    Resilience – A Strong Metric

    I was recently attending a conference (virtually, of course) that focuses on leadership and the related trends. Every year there is an idea or two that is the current hot topic. This focus has included familiar things like EQ and grit in the past years. One somewhat new theme this year was resilience. It is a trait we have all heard of, but it may be the next big thing to measure in getting the “best” employees. It may also be a metric you can use to determine how to improve yourself professionally and in your personal life.

    Resilience Assumes Challenges

    There is an old phrase, “hope for the best and plan for the worst.” It is safe to say that most of us accept that life will be full of challenges. It is hard to live very long without that being proven out. Therefore, our ability to react to and overcome obstacles is a critical factor in our success. You hear this concept in sports all the time. Every championship team had moments where they overcame a challenge and advanced on the path to becoming a champion. Every business’s success is the same. There are “overnight” successes that come faster than expected. However, most companies have a long and bumpy history that continues to the current moment.

    A Measure of Succes

    When you assume that every journey will include obstacles you must also accept that every journey has an opportunity for being derailed. There are substantial obstacles to face like the global shutdown due to COVID. However, there are more often smaller obstacles like a change in requirements or delays or miscommunication. We are required to overcome all of these to reach success. That logically flows to the idea of building a team that possesses resilience. This trait can come from individuals or it can be how the team members support each other. Sometimes there is not only safety in numbers, but also resilience.

    Positive Attitude

    The points made thus far are realistic, not pessimistic. Stuff happens. We can rail against it or bemoan our situation. Nevertheless, it is where we find ourselves. When we face these situations we can move forward or dwell on our misfortune. It seems obvious that moving forward is the best approach. However, we sometimes get stuck in these challenging moments. Resilient people take these sort of setbacks in stride. That is not only a valuable trait, it is also one that is relatively easy to see. Of course, levels of resilience can be difficult to measure, but it is not hard to see if someone possesses some level of it.

    Tactics and Approaches

    At the risk of being obvious, I think it is worthwhile to look at some of the things we see in resilient individuals or teams. There are actions that come from this trait and show that tendency to push forward. Here are some things to look for that can easily be worked into an interview (or self-reflection).

    • Acceptance – Moving requires action. Thus, the time spent on bemoaning a situation increases the time spent on it.
    • Blame – Looking for blame or a way to shift responsibility to others does not contribute to overcoming the obstacle.
    • Progress – Resilient people and teams move through options and avoid getting stuck on a single option as well as analysis paralysis.
    • Optimistic – It is hard to tackle a problem that you think is a lost cause. Resilience almost requires some element of a positive attitude or at least hope.
    • Analysis – One can spend too long analyzing a situation. However, resilient people have the ability to dig into a challenge in an unemotional way in order to see where things went wrong or look for ways out of it.
    • Roll With It – Much like acceptance, resilience often includes an ability to “shrug off” setbacks. Thus, challenges are assumed to exist and do not slow down teams or individuals with this trait. This factor points back to that “plan for the worst” concept.
    • Absolutes and Clarity – In my personal experience, I find that resilient people are less likely to talk in absolutes when talking about an approach. They leave open the idea that changes to their plans may (or will) be required.

    Nothing New Under The Sun

    All of us have been exposed to the resilient trait in people and teams. However, it can often be lost in the shuffle of other skills and attributes we look for in a team or hire. Therefore, it is worth our time to consider how it can factor into our approach and processes. There is no question that finding the right hire and building a team are complex and complicated feats. Likewise, we must avoid letting critical factors fall through the cracks.

  • The Agile Manifesto – A Practical Look

    The Agile Manifesto – A Practical Look

    The Agile manifesto started an entire industry. It has even been the focus of numerous “religious” debates and arguments. However, it has a lot of wisdom within it that is often overlooked. The main ideas are as relevant today as they were when it was first crafted. Therefore, it is worth our time to review some of these wise nuggets and consider applying them throughout our software development efforts.

    The Manifesto Is Not The Agile Methodology

    We need to start by clarifying that the Agile Manifesto is not the same as the Agile Methodology for building software. The manifesto was used to create the methodology. However, they are not one and the same. Think of the methodology as an attempt to turn the manifesto ideas into reality. It is easy to see where many agile or extreme programming techniques got their start in the manifesto. Nevertheless, your opinion (and experience) of one may be noticeably different from the other.

    The manifesto came out of a desire to create better software. The first point drives that concept home. The highest priority is to satisfy the customer. This statement should be the “why” of any application and cannot be turned into a process. The Agile methodology provides a lot of ways to assist in this goal but does not guarantee it. Looking at it that way, we can easily see where a team could use Agile methodology precisely as described and still fail to deliver a successful project.

    Work As A Realist, Focused on Delivery

    There are twelve points the Agile Manifesto lays out.  These emphasize producing a solution the customer wants while acknowledging the realities of software development.  The most important of these practicalities, to me, is delivering results along the way to the final solution.  This process recognizes that customers often change their minds, communication problems exist, and showing is better than explaining.

    We all know there is often a disconnect between business representatives and technical resources.  The language does not always translate and skilled liaisons are in short supply.  Thus, we can lower the bar by deciding to be flexible from the start.  This approach is not a way to ignore requirements gathering, design, or other due diligence.  Instead, it assumes we will need to revisit those steps.

    The Manifesto Points

    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

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

    Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    Business people and developers must work together daily throughout the project.

    Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    Working software is the primary measure of progress.

    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    Continuous attention to technical excellence and good design enhances agility.

    Simplicity–the art of maximizing the amount of work not done–is essential.

    The best architectures, requirements, and designs emerge from self-organizing teams.

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

    The Agile Manifesto

    Work Together For A Common Goal

     There are numerous rules of software development built into this manifesto that are needed for a successful product.  We already stated a focus on making the customer happy.  This statement is not arguable.  A product that does not please the customer is a failure by definition.  Another important concept that is woven throughout the manifesto is the Pareto Principle.  This rule says that 80% of our effort is spent in the last 20% of the product.  That means we can get “mostly there” relatively quickly. This focus on getting most of the way to the solution is highly valuable.  

    Let’s think about that a bit.  When you are almost done, you likely have a lot of the core functionality covered.  The “happy path” is complete and functional.  That is an essential factor in getting feedback.  You have a use for the product the customer can see and experience.  They have something concrete to assess and a solid basis for requesting changes.  

    Gaps In Knowledge

    It is not very different from taking a vehicle for a test drive.  You can get a feel for it and might even see some weaknesses.  This last factor is critical to the success of a product.  Customers should not be required to know edge cases and outliers in building a solution.  That is up to the developers.  However, these are issues that often fall into the “you do not know what you do not know” category.  When you provide a demo or partially complete solution, you give the customer a straw man to work with.  That is far more concrete and relatable than describing functionality or showing them a flow chart.

    Keep It Simple Somehow

    The focus on delivering regularly and the underlying Pareto principle ideas lead us to opportunities for the KISS approach.  It is amazing how often customers will scope out requirements to get working software in their hands sooner.  This carrot is dangled in front of them during regular demos and releases.  Yes, there are gaps.  However, a good relationship with a customer can lead to a shorter path to something they want and consider “done.”  Who would argue against that?

    Remain Flexible

    The last central theme I want to point out is the focus on change. When we create software, it is crucial to think about flexibility. We are not building a system to solve a specific problem and situation. Instead, we are trying to provide a solution that is useful in a broad range of configurations. The world is also constantly changing. Therefore, even though we can be assured of a need for new versions of our software, we need to be smart about it. A sound system is built with growth and change assumed. That means we need to prepare for it from the architecture through to each step of implementation.

    The Agile Manifesto has been around for many years. Nevertheless, it still is needed to remind software developers and teams of what is important. When we embrace these core concepts it reduces risk and improves our chances for success.