Author: Rob Broadhead

  • Winning With Agile

    Winning With Agile

    The Agile methodology has a lot of pros and cons.  In fact, it is one of the most common argument/discussions I have with a mentor of mine.  He likes to point out (correctly in most instances) that the Agile approach skips out on important design.  It causes a lot of re-work because of that lack of up-front design.  This re-work is only partially a problem.  The Agile method assumes that changes will come during the implementation of a project.  Instead of spending time up front in design on things that end up being thrown away, Agile takes a just-in-time approach to all phases of a project.  I have witnessed a lot of good and bad in these type of projects and found a few ways to help your Agile project improve its success rate while still delivering quickly.

    Design is not an Option

    Although the design phase is not front loaded for Agile like it is for Waterfall it is still required.  Coding without design is like driving without a map.  You might have an exciting journey, but it will almost never be the most direct route.  Teams that have seen success using Agile also have a design portion of every sprint.  This step does not have to be highly formal, nor does it have to take long.  A day or two of design at the front of a two-week sprint will do wonders for quality and help you meet the estimates.  Do not take my word for it, give it a shot for a couple of sprints.  This period does need a quick turn around though as there will likely be clarification requested of the business side or critical stakeholders.

    Testing is not an Option

    In the same vein, testing along the way is critical to Agile success.  A primary aspect of this approach is that things will change.  A good bed of unit tests and regression testing will allow the changes to made while minimizing the impact on quality.  Yes, the tests will have to change and might even need to be rewritten.  However, they will be critical for assessing that a change has not broken other areas of code.  A team that uses Agile and regularly has to “refix” a bug from QA can help themselves with a good set of unit tests.  Of course, tests must be run to be useful so incorporate them into the build process.

    Ask About Always or Never

    Since Agile assumes requirements will change we need to do our best to limit the impact of those changes on implementation.  When processes or objects are being designed that means we need to be careful of our assumptions.  Simplicity and performance may imply that we take a design path because of certain assumptions.  However, when those assumptions prove incorrect we can find ourselves coded into a proverbial corner.  Thus, when faced with the possibility of coding a tight solution based on assumptions it is good to ask the “always or never” question.

    This takes the form of “are you sure this will never happen?” or “are you sure this will always happen?”  It is worth it to emphasize the question and the assumptions to assure you that the right approach is being taken.  When in doubt, avoid coding yourself into a corner.  Functionality correct, but less than perfect performance is better than non-functionality.  That is what refactoring is designed for.

    What This Looks Like

    There are many ways to follow these guidelines in practice.  Of course, Agile is all about limiting documentation and speeding implementation.  I have found that pseudo-code and comments at the start of implementation help enforce both design and testing.  When you insist that all functions and methods include comments about inputs, outputs, error-handling and a brief description of functionality all of these concerns will be addressed.

    It is not a perfect solution.  Nevertheless, it will help with documentation while asking the developer to think about the code before they write it.  I have not seen it done, but I think you could even do a comment task on implementation items early in a sprint.  Ask the developers to write out the comments, test conditions and parameters for everything first, then the code can follow.  This is much like test-driven development.  In a similar fashion, it pushes implementors to think about design before they get into the coding.

  • Configuration Vs. Coding – Modern Software Systems

    Configuration Vs. Coding – Modern Software Systems

    Over the years that I have been in the software development profession, I have watched solutions evolve dramatically.  The progress has gone from code to libraries to frameworks and now configurable systems.  However, there are trade-offs to consider when you look at a configurable system instead of one that allows for customization with code.  This is becoming a more common dilemma for businesses.  Thus, it is good to look at the pros and cons of each approach.  Here are some points to consider when measuring configuration vs. coding.

    The Power of Configuration

    Let’s start with the positives a configurable system brings to the table.  Configurable customization is where software of all sorts is heading.  Part of it is likely due to changing interfaces and keyboards becoming relics of the past.  However, there is far more value included.  I have found that the most significant value companies place in these systems is the lower cost of maintenance.  A configurable system constrains how changes are made.  Thus, it is easier to test those options thoroughly.  You also are less likely to have typo related issues.  The inputs can be highly constrained and validated.  For example, a drop-down selection item is not susceptible to a typo.

    There is also a lower technical threshold for configurable systems.  Administrators can often learn all they need to know with a few days of training.  As opposed to years required to build stable and scalable code.  This approach has the side effect of reducing the number of points of failure in many cases.  Less information has to be communicated across departments.  Thus, for example, a marketing employee can make changes to the system.  The alternative is to relate them to a developer to code.  Business users can focus on their business rather than how to communicate to the technical staff.

    Coding is Here to Stay

    With all that configurable systems have to offer, there is still a level of control given up.  The limits that make these systems so powerful also keep them from doing precisely what is needed.  A customer is also at the mercy of the vendor for these systems.  A required feature may be a long time coming, and critical functions may disappear.  These may be worst-case scenarios, but that is enough for many to choose a custom coded solution.

    Every business is different, and coding allows for software to be built to precise specifications.  Your priorities can be crafted into the software.  Then, it can change as your business needs change.  There is also ownership of the product to consider.  A custom solution is owned by the creator and not a vendor.  You can change it as needed and do not need to worry about the future stability of the vendor.  Better yet, any problems that occur are your own.  There is one place to look for solutions.   Thus, no time wasted on support calls to get a response to meet your schedule.

    Configuration vs. Coding – The Bottom Line

    I could list dozens more pros and cons for each side.  However, the decision is pretty simple.  A configurable system is the better solution in most cases.  One has to recognize that the 80-20 rule holds for these systems.  Therefore, configuration is an excellent choice.  The configurable piece of the solutions often allows a company to get 90-95+ percent of its needs met adequately while avoiding the costs and headaches of custom software.  It also allows you to buy the experience of the teams that created the software.  They used their expertise to solve common problems.  This may not get you to one hundred percent coverage, but it will provide tested solutions for eighty-plus.

    Finally, do not underestimate the value of fixed cost solutions.  Your vendor is providing you a solution that is complete.  There are no concerns of improper estimates, scope creep, or schedule overruns.  Therefore, the focus is on using the solution, not creating one.

  • Making 2018 Your Best Year Yet

    Making 2018 Your Best Year Yet

    The beautiful thing about a new year is that it gives us an excellent milestone for change.  Of course, there are always resolutions to make this the best year ever.  However, we will look beyond declarations.  This article presents a more intentional approach to improvement based on thoughtful consideration.  We are not just picking a popular trend and jumping on or an obvious, but broad, improvement.

    Careful Assessment

    The first step in planning our best year is to assess where we are.  Take some time to look at the trends and challenges of the last twelve months.  This action is not a cursory glance like checking the scale and deciding to lose weight.  It is a deeper dive into not only the results but the causes.  We want to treat the core problem, not the consequences.  Thus, build a list of issues and then review whether they are problems or symptoms.  Dig down to create a list of challenges that are slowing your progress down.

    Simple and Specific

    The scope is always a challenge when changing course or solving problems.  We want to go for the big wins.  However, that has the negative impact of keeping us from gains that quick wins can provide.  A few little successes often outweigh a big win, particularly when you consider the time for those wins to “bake in.”  For example, if I can save a dollar a day now or ten dollars a day in a year I will have missed out on 365 dollars of savings before I get that more significant win.  Keep that in mind while looking at the problem list you created.  Maybe there are some easy wins or partial improvements that can be completed in the first quarter.  Move these up on the priority list and allow the more significant enhancements to wait.

    Avoid being vague in your goals and improvements.  A good list will have deadlines, milestones, deliverables, and be measurable.  This list will help you be held accountable from the very start.  A plan has been created.  Thus, get to work on it.  When you leave things vague like, improve sales this year, the lack of details makes it hard to get started on that goal.  Your first step, in that case, is to decide what the first step is.

    Finding The Clues

    Sometimes things look ok on the surface.  The problems you are facing can take some extra research to see them.  A good approach for this task is to look at where the money went.  We often can find out a lot when we “follow the money,” even when it is our own spending.  When you have useful metrics on resource utilization that is another potential clue in how to improve your business.  The math is simple.  Look for ways to reduce costs, improve productivity, or increase revenue.  When you attack these areas, you will see a business grow.