Blog

  • Back To Basics – Getting A Project Back On Track

    Back To Basics – Getting A Project Back On Track

    When you listen to a professional or college sports team discuss a bad stretch, they often mention that they will get back to basics.  These statements are not a knock on the players.  They understand the basics.  It is instead a focus on doing the things that have to be done.  It is a return to their foundation so they can simplify and then work on building again.  This approach happens to work well for software projects as well.

    Spinning Out Of Control

    The good and bad news is that software projects almost never go just a little off-track.  A slight stumble in a project either gets righted quickly or it starts to spiral away.  Thus, it tends to be easy to see that a plan is out of control when you look at it on paper.  There will be features that are not implemented, slipped dates, and requirements that have been ignored.

    Like the coach of a team struggling to succeed, we can simplify without getting bogged down in blame or questioning the skills of the team.  This approach is not just saving the feelings of the team members; it also happens to be an excellent way to triage the situation.

    Back To Basics = Simplify

    I think the best benefit that comes from this approach is that it forces us to simplify and focus.  The first step is to look at the requirements and assess where the software is about them.  When I say requirements, I am talking about the original, not the ones with a pile of change requests.  Those change requests may be vitally important, but let’s ignore them for now.

    Once you have the gap analysis complete on the software and the starting requirements, it is time to tackle the scope creep and change requests.  As you move through these items, start each one by asking if it is required.  Nice-to-have features often show up in early change requests because we have a lower bar of entry.  When things are on schedule and expectations are met, we are happy to add a feature or two.  That changes once we are behind schedule or on a death march.

    The Baby and The Bathwater

    There will almost always be changes that can be made to the scope at this point.  Things have gone for a reason.  There are cases where a technical issue or challenge causes a project to go off the rails.  However, I have rarely experienced this.  It is far more prevalent to have a project die due to a thousand cuts.  There are all sorts of little slips and additions that have led us to this wreck.

    That being said, our gap analysis will almost always highlight opportunities for removing features and simplifying the project.  When we tackle these, it needs to be with discretion.  Some features can be turned off to reduce scope without much effort.  However, many will have tentacles reaching into other areas.  Thus, unlike a sports team, we may have features that we need to keep due to the complexity.  Of course, if we have good adherence to version control best practices, we should not run into this problem.  If you just fell on the floor laughing, you are not alone.

    It is important to note that this is a perfect example of where good version control practices can help.  You can use branches and tags to group and categorize the features as you remove them.  This will allow you to attempt merging those features back in for a future release.

     

    The Bottom Line

    When you find yourself in the middle a project catastrophe, get back to basics.  Focus on the requirements you have to meet and a simplified target.  You do not get to cut out some of the basics.  Thus, testing, code reviews, comments/documentation, and those other areas of the SDLC we like to skimp on are not valid targets for getting on track.  You may do these in a less flowery way and simplify some of those processes, but throwing them out is only going to get you back to this position in the future.

    Are you struggling with a project today?  Take a shot at going back to basics and see if that doesn’t quickly give you a path to success.  This is not a silver bullet.  There is still work to be done and corrections to be made.  However, this can get you headed to the light at the end of a tunnel instead of the next oncoming train.

  • Remote Work and The Value of a “Go” Bag

    Remote Work and The Value of a “Go” Bag

    Although there are still holdouts, we are moving to a world where remote work is typical.  The regulars at local coffee houses, Starbucks, and Panera are just part of the proof.  You can also find some “rent-a-space” options in many cities where a temporary office is available for travelers or those that need a change of scenery.  When you have a job that is sometimes at an office and sometimes on the road, it can be frustrating to keep up with all of your tech and office supplies.  These times are when a “go” bag comes in handy.

    Remote Work Still Requires Power

    Paper and writing implements are important in a go bag, but power plugs and cables are even more critical.  We are a connected generation that needs our electronic tools.  Whether it is a tablet, a smartphone, or a laptop, power is essential.  Even though battery life for these devices is getting better, you never know when you will need more.  In fact, Murphy’s law tells us that we will need that plug or cable most when we do not have one available.

    That leads to the first thing that is good for your bag.  A cable, plug and maybe even recharging block for your primary devices.  I have found these to be highly useful over the last few years.  I have also purchased these items solely for my “go” backpack.  That way I never take them out (and risk the chance of forgetting where I put them) unless I need them away from my office.  If you share time in an office and at home, then a second or third power cable for your laptop is essential.  It is too easy to rush out the door and leave a cable behind.  That can ruin a weekend trip where you were going to catch up on work.

    Travel Comfortably

    I have been surprised at how useful an extra set of earbuds and a headphone-mic combo have been in recent years as well.  It is hard not to take calls and holding a phone while taking notes is almost impossible.  Of course, you can always use the phone or device speaker, but that can make it easy for others to eavesdrop.  Oh yeah, it also is annoying to be “that guy” that is having a conversation everyone in the room has to listen to.

    As a bonus, carrying headphones makes it easy to relax to music, listen to a podcast, or catch up on your favorite movie or TV show when on long trips or commutes.  I recommend you have a few select apps, albums, or movies for those longer trips.  There is a world full of audio-visual options to match your every mood.  These can be a great way to relax even while traveling.

    It Is Easy To Create Your Bag

    A “go” bag might be your laptop bag or backpack.  That is often a great solution since you are not likely to forget to throw your laptop in its bag.  That is how useful such accessories are.  You may have noticed that these sort of bags have pockets and compartments for all sorts of tools and accessories.  Take advantage of these.  Throw a spare of things you use a lot.  These spares might be batteries, cables, pencils, or “emergency” items like some aspirin or toothpicks.  Kleenex is one of those things we can always use and small tools like an eyeglass repair kit can be a lifesaver.  The better stocked your bag, the less likely you will find yourself caught short during your remote work.

    I would be remiss if I did not mention a few items that are not needed very often, but valuable nevertheless.  Adapter plugs for things like a video display or power supply are important for those that do presentations.  You can always use your laptop or tablet display, but it looks more polished to be able to plug into the local large screen display.  USB powered items can save you headaches as well.  Many laptops have a backlight on the keyboard, but if yours does not then I recommend a USB light clip.  These can allow you to work in low-light situations like riding in a vehicle at night.

    Everyone has their own favorite tools and accessories so your list may vary considerably from mine.  The key is to have the things you need most in a place that is easily accessible as you are running out the door to a client meeting.  Try creating your own “go” bag and see how much it helps you do a better job on the road or your remote work office.

  • 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.