Tag: design

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

  • Software Design – Measure Twice and Cut Once

    Software Design – Measure Twice and Cut Once

    It takes very little time in the software business to see that implementation is king.  Software design and similar pursuits that lack a deliverable outside of documentation are pushed aside far too often.  One may look at the poor success rate of software projects and draw a connection.  In this post, I plan on doing exactly that.

     

    Software is Complicated

    The first thing we must agree on is that software has gotten complicated.  There are all kinds of tools that help with coding and implementation.  However, these do not eliminate the challenge of building a useful and stable system.  The lines of code written by humans may be dropping, but the overall size of modern systems is growing all the time.  Thus, software design is needed to plug all of those pieces together and provide a path for the implementation team to build a cohesive system.  There are tens of thousands of “moving parts” in most modern systems and that means the same number of potential points of failure.

    The Vision Problem

    Code complexity is just the technical part of the problem.  The more significant reason for spending time on software design is due to vision.  A client, end-user, stakeholder, and developer all have their vision of a solution.  Some of the differences are due to gaps in knowledge.  For example, a subject matter expert has a deeper understanding of the problems to be solver than other team members.  This is not an issue unless we skip the step where that knowledge is transferred to others.
    A more substantial challenge is that we do not know what we do not.  Thus, there must be a conversation around software design.  The designers and implementation team needs to be on the same page as the end users and stakeholders.  When this does not happen, it is like giving someone directions to meet you, but they use a different (and incorrect) set of instructions.  When the destination or goal is not the same, then failure is almost guaranteed.

    An Old Problem

    The astounding aspect of this situation is that it is an old problem.  Even worse, it is one that has been solved.  The idea of measure twice and cut once goes back a long time.  However, that is precisely the purpose of software design.  In this case, the action is implementation instead of cutting, but it is nearly as final.  When you make the wrong cut on a piece of wood, you need to get new wood.  You can not “un-cut” the wood. Code is more forgiving; you can undo an action.  Unfortunately, we often realize that we need an “undo” far down the road from the mistake.  This leads to a lot of back-tracking, lost work, and potentially a duplication of effort or worse. A good design is likely to point out mistakes earlier when they are far less effort to correct.

    Not An Agile Problem

    I would be remiss if I ended this post without mentioning the Agile process.  The goal of Agile is to reduce overhead related to design and documentation, not eliminate it all together.  A proper Agile approach still includes planning; it just limits the scope to the upcoming implementation.  This can cause issues and turn up problems later than desired.  However, the trade-off is a more fluid approach to creating software and turning a presentation approach to something more like a conversation.  Agile assumes that we cannot correctly create a complete design from step one, but it does still embrace software design.
    Next time you are pressured to dive into implementation have confidence in pushing back.  When you fight for the value of good design, you improve the chances of project success.  After all, that is the ultimate goal of everyone on the team.
  • Using Milestones For Project Communication and Success

    Using Milestones For Project Communication and Success

    One of the important parts of tracking project progress is defining milestones.  These are points during the project where the required tasks and the goals for time meet.  It only makes sense that the definition of milestones and how they are treated are an important part of project success.

    Defining Milestones Simplified

    Although these steps in the definition process are necessary, that does not mean they have to be complex.  Every project is different, but I have found these guidelines useful.  In fact, I use them every time we need to craft milestones.

    1. Milestones must have a deliverable

    Defining a deliverable for a milestone is rarely a problem.  However, I have seen vague descriptions like “complete the application UI” as the total of the objective.  This description is a start, but not truly definable.  Nor is there a deliverable mentioned.  We have to be able to say a milestone is complete (or not) without ambiguity.  This example is improved by including a UI demo to be delivered as part of the objective.

    2. The deliverable must be visible to the customer

    This point is often an issue during a project.  There will be a step that includes securing the site or building a backend database.  Unfortunately, the implementation does not have a visible result. That is not okay.  Find a way to craft the deliverable so that the customer can see that progress has been made.  The progress may be a login screen tied to an ACL or the result of some select statements to show default data in a database.  When in doubt, modify the milestones, so the “invisible” work is part of visible steps.

    3. Provide a Method For Feedback

    Milestones are more than just getting work done.  They are also an opportunity to gather customer feedback.  Use the milestone deliverables as a way to verify the implementation is still on track with the vision and goals of the client.  This option helps deliver a successful project instead of just delivering a project.

    Defining Milestones For Success

    We have already alluded to milestones being about more than progress.  They can also be designed to improve the chances of a successful project.  As mentioned earlier, the first step is to ensure that customer feedback is part of delivering any milestone.  This goal can be achieved through regular demos and review sessions that coincide with milestone deliverables.  I find that presenting milestone deliverables in some way is useful for drawing out feedback as well as a sort of test of the deliverables.  That extra look over the deliverable can be a sanity check well also revealing gaps.

    Scheduling the milestones in a way to reduce risk is recommended.  When the milestones that have the most risk are tackled early in a project, it allows for the less risky steps to be used to make up time.  Of course, that is not always possible.  In most cases, the work on challenging items early in a project is a way to bring up estimation issues and slippage sooner.

    Defining Milestones in a Vacuum

    We are not always a part of the project definition.  Thus, we run into those projects that are ill-defined and yet, we want to be successful.  In these cases, I find it is best to break the work you control (or are assigned) into milestones.  Your position in the team may not allow for customer feedback as part of milestone delivery.  However, you can usually find someone to which the deliverable can be presented.  Every little bit helps.

    Even the largest projects can be broken down into smaller “sub-projects.”  This step is where milestones come into play.  Thus, an over-whelming or “impossible” task becomes more manageable.  Since there are so many ways projects can go wrong we need to use tools like milestones to improve our chances for success wherever possible.