Tag: consulting

  • Keeping The Agile Development Approach Flexible and Increasing Velocity

    Keeping The Agile Development Approach Flexible and Increasing Velocity

    The Agile development approach is a hot topic and has been for a while.  Although it is adopted in a lot of shops and well-documented, there are still some issues with it.  The way we implement the Agile approach can defeat the purpose of a flexible model that allows a high velocity of production.  That assumes you have enough resources to effectively do more than one thing at a time.  However, there are some ways to adjust your scrums and sprints to get the most out of this methodology.

    Agile as Small Waterfall

    One of the flaws I have come across is that teams treat a sprint as a short waterfall process.  It does include all of the same steps as the waterfall approach (gather requirements, design, implement, test, deploy) but does not need to be as linear.  For example, a waterfall approach to a sprint would be a few days for requirements, then to design, then implement for a while, then test, and end with a deployment.  All you gained in this is reducing the scope of the requirements and what is deployed.  I am over-simplifying a little bit.  However, this is close enough to a lot of sprints I have seen.

    The productivity problem is that you have resources during the sprint that are not used.  Testing is not done until the end, so testers are idle at the start.  Designers are not needed much during implementation, so they are almost unused.  Team members do a lot of work at a high pace during their portion of the sprint and hang around the rest of the time.  You can use that spare time for training and skills improvement (not a bad idea), but there are better uses of your resources.

    Continuous Progress

    The goal is likely to keep all of your resources working on a steady and constant basis.  This can be partially achieved by including everyone in every step.  It makes sense for testers and developers to be involved in design and designers engaged in implementation, testing, and deployment.  However, this is almost like busywork in some of those cases.  A better approach is to overlap your sprints.  This is easy to do with multiple teams.  Nevertheless, it can be accomplished with a single unit as well.

    The effect is that you will have more than one sprint active at a time.  Multiple teams will have this, but a single group may as well.  With multiple units, a productive approach is to have members be a part of more than one sprint at a time.  The implementation team will be the only group that tends to have a single sprint focus most of the time.

    Overlap For Productivity

    Let’s use a two-week sprint as an example of how this works.  Sprint A starts on week one and requirements are gathered (from the backlog).  The implementation and testing team go over the items for the sprint and provide feedback, estimates, and ask for clarifications as needed.  This is the first few days of the sprint (we will assume two).  Next, we move into implementation.  For this example, implementation is six days which leaves two for integration testing and deployment.  That is not enough time for sufficient testing so we will have our testers running through scripts where possible as tickets are completed during this phase.

    The designers will be supporting the implementation phase, as needed.  However, they will also be looking ahead to the next sprint.  The design team can dig deep into designing for the next sprint and use this time to get feedback on design decisions as well as poll customers/users.  That should make it easy to keep the selection and clarification part of the next sprint go smoothly (maybe a day instead of a couple).

    As we move into testing, then the implementation team and designers will start work on the next sprint.  They will be selecting and clarifying tasks while the testers test.  As we move into deployment for Sprint One, we will also be working on implementation in Sprint Two.  Rinse and repeat.  The overlap of a few days will help keep designers busy and the developers implementing.

    If you have two or more teams, you can overlap implementation, keep design short and assign designers to possibly several sprints at a time.  This will also allow for more design time to be allocated to each sprint.  That will pay off in clarity around requirements as well as reduced design related flaws.

    Minor Tweaks

    As you can see, these changes are not earth-shattering, nor are they complicated to introduce.  Your scrum master and designers might have a little more asked of them.  Nevertheless, the payoff is worthwhile, and they will find a rhythm with this process early on.  It also helps avoid a roller coaster of activity that can often occur with team members when you do not find ways to keep them busy and focused throughout a sprint.  Better yet, this is an easy change to try for a few sprints to see if it works for you and your team.

    I would love to hear other suggestions and feedback on how your attempts at improving your agile development velocity turn out.  We can all learn from the successes (and failures) of others.

  • Exploring Your Tool and Application Options

    Exploring Your Tool and Application Options

    In the last few years, I have often found myself researching application options and tools a customer is interested in.  This usually starts with a suggested tool or two that they like (or have a few specific dislikes).  Then I am asked to see what is available that is similar but better.  The fruits of those little projects are a good start for this article and will likely surprise you.

    A Target-Rich Environment

    The first thing that jumps out at me when I start these projects is the number of application options that can be found with a search or two.  Even “niche” applications like visitor recording, B2B e-commerce, and database development tools will return several options.  Better yet, most of the alternatives I come across have at least a free trial period of a few weeks while often providing an unlimited free option.  Cost is rarely an issue.  The tools available these days are regularly priced in a way that allows customers to start simple and inexpensive or go all-out for a high-end solution.

    Worth the Investment

    I mentioned a trial period available for most solutions.  When you combine some of the training material often provided with the ability to “play” with these applications the time requirements can become overwhelming.  However, an hour or two will typically be more than enough to evaluate the usefulness of these tools.  At times, you will be able to eliminate options in fifteen minutes or less.

    This time spent perusing your options is well worth the investment.  Your initial list of a few possibilities can grow to several.  Then they can be pared back down to a short list.  At this point,  each solution is likely a good fit (or better) for your needs.

    Evaluating The Options

    The number of viable application options makes the selection process easy to overlook.  When you feel you cannot wrong with any of the available choices, then it is logical to keep your investment small and avoid going deep into the evaluation.  At this point, it is worth looking at the reasons that started the search process.  Some requirements were not being met by the original solution.  They should be verified in the short list of options.  The search process will also provide new elements that are desired in the solution.  That is just the nature of reviewing solutions in any vertical.  Your comfort with a prior solution can keep you from considering what new advances and features can do for your productivity and company.

    Make sure your list of requirements is kept up-to-date with what the research has taught you.  In my case, I am often in a position where I cannot make the call on that list of requirements.  Instead, I make a note of features and enhancements listed by some of the solutions that may appeal to my client.  As part of the review deliverables, I always include these features as an addendum to the requirements list or as “other things to consider.”

    The More The Merrier

    Many tools have a way to invite others into a demo period.  Take advantage of this and find some other people that can give you feedback on the product.  They do not need to spend much time at all in the product.  Instead, they can quickly provide their initial reactions to the features and interface.  This is a great way to avoid making decisions in a vacuum while also sending a form of a trial balloon to determine how open others are to this change.

    I hope these brief suggestions spark you to re-consider your current tools and evaluate how the landscape has changed.  A considerable productivity boost might be just around the corner for you and your team.  Of course, I also am happy to help you in evaluating your options and finding the best tool currently available.  I would love to discuss your specific requirements and how to find the best solution.

  • Incremental vs. All-in Change and Enhancement Strategies

    Incremental vs. All-in Change and Enhancement Strategies

    Sooner or later we have to consider how to change our systems.  This situation can come from growth in business, changes in technology (or requirements), or systems that have aged poorly.  When we reach the point of deciding on a move we often have to decide on the incremental vs. all-in approach to achieve our goal.  There are times when one choice or the other is obvious.  However, I have found that we almost always have both of these options available.  So let’s look at the risks and rewards commonly available to each decision.

    An Incremental Approach

    I find this option to be the most popular.  In fact, you might be able to rattle off some rewards and a few risks faster than it takes to read this article.  Nevertheless, it is helpful to go through the exercise and maybe a few items from either list will be new to your experience.

    Pros

    • The Risk is Reduced: Less change and more options to bail out or adapt.
    • Less Time Before Starting: Smaller changes can allow for less upfront planning.
    • Time To Bake In: Users have small changes to learn rather than large ones.
    • Less to Consider: Small scope of changes means less to worry about with each change cycle.
    • Easier to Budget: Tighter range of change and time frames make it easier to budget for changes and cash flow the project.
    • Avoid Re-inventing the Wheel: This approach allows pieces of the original system to survive and remain untouched.  Thus, business rules and proven validations do not have to be re-created.

    Cons

    • Total Cost is Higher: Overhead for each cycle adds up.  Therefore, more testing, deployment, and other phases will be repeated for each incremental change.
    • Longer Schedule: Much like the above item, the time to be done with changes is going to further in the future with an incremental approach.
    • Legacy Decisions/Constraints of the System: An incremental approach will always be tied to the original system in some way.  It does not allow for a fresh start or utterly new thinking.
    • System Stability: Regular change can make the system appear unstable to users and might be the reality as repeated touching of the core system offers opportunities for simple mistakes and human error to degrade the system.
    • Integrate Changes: No system is static.  Changes are required for a variety of reasons, and an incremental approach does not allow us to ignore change requests.  Extra effort is needed to manage change requirements and fixes along with the new/improved features being implemented.

    An All-In Approach

    This is a more courageous decision in almost every case.  In fact, this approach often results (directly or indirectly) as one that makes or breaks a job (or career).  The rewards are higher when this is correctly executed as there is more freedom to make huge strides.  That said, there is a lot to worry about as well.  Here are some of the pros and cons of this decision.

    Pros

    • Total Cost is Lower: A significant change requires a lot of testing and deployment work.  However, it amounts to fewer cycles and general overhead than an incremental approach.
    • Freedom to Innovate: The lack of ties to a legacy system allows us to learn from past successes while avoiding past mistakes. Substantial and meaningful changes can be made in this effort.
    • Shorter Time to Completion: There is not a need to run in serial as is needed in the incremental approach.  Resources can be poured into the all-in solution.  Thus, progress can be made in parallel with the current systems continuing to run.
    • More Stability For Users: This approach will result in a significant change when it goes live.  However, other than that point in time, the users will experience a stable and reliable system.
    • Less Elegant Utilities: A one-time step of significant change means the tools and utilities to do so only need to work once.  This is the opposite of the design required to make the same tools work when you know there will be multiple, smaller, executions of them.

    Cons

    • The Risk is Higher: When you make a significant change and choose wrong, it can result in a crippling loss to the company.  This can have productivity and financial repercussions.
    • More Time Before Starting: Planning and design are needed for the entire system to properly execute the all-in approach.  Every little detail needs to be addressed to reduce the risk of a complete failure.
    • More significant and Impactful Change: The substantial change of an all-in approach is hard to hide.  Often it will require training for the users to help them utilize the new system.  Alterations of business rules and procedures are often part of the content for deploying this solution.
    • Total Review and Design: The broad scope of changes require the entire system to be reviewed and understood.
    • Large Budget: A substantial project like this is harder to estimate and often includes more funding in a short period.  Incremental allows us to stretch out costs.
    • Re-inventing the Wheel: Often this approach requires core functionality to be rebuilt or re-coded and tested again.  This amounts to re-inventing the wheel for business rules and other functions.

    As you can see, there is a lot to consider with either approach.  The pros and cons balance out more often than we think they do.  Therefore, it is worth it to leave both options on the table on at least a periodic basis.  This will ensure we avoid knee-jerk reactions to one approach or the other.  As always, the more we know, the more we consider, the higher the likelihood of a successful decision.

    Going Deeper

    Incremental Changes

    When you look at the pros and cons of this approach, there are some essential assumptions made.  If you take a path that does not follow the premises, then the pros and cons will differ.  The “time before starting” and “less to consider” pros, in particular, are impacted by your approach to design. The assumption for incremental changes is that you will plan and design as you go.  This may not be the case.  Some organizations prefer to create and plan out their entire series of changes up front.  While this is a good approach, there are also valid reasons to hold off on a complete design when you are not sure far you want to progress.

    Similarly, the time to bake in and system stability items may vary in your experience.  There are ways to drag out an incremental approach so that the users do not experience noticeable changes.  Instead, they see undergo the changes as occasional enhancements.  However, this approach can significantly increase the time to completion and may increase the limits to what can be done (due to ties to the current system).

    Finally, let’s look at the re-inventing the wheel item.  An incremental approach can do this as well.  Typically, an organization will avoid touching the things that “work.”  The argument is that there is no reason to put effort into fixing something that is not broken.  On the other hand, when a core functionality can be improved, then it may be worth taking on that change at some point.  There is also the side effect that can occur where a core and stable piece of functionality is changed or even broken through changing other areas of the application.

    All-In Advances

    It should be clear that the all-in approach, in this case, is deploying all the changes in virtually a single push to production.  This can be a large number of changes to an existing solution, replacing one with another system, or starting from scratch.  Each of these three options has a very different set of pros and cons along with those mentioned.

    An important note about the all-in approach is that the sunk-cost fallacy should always be avoided.  There are many cases where companies dismiss an all-in change because they start with the idea of value for the existing solution.  Yes, there is knowledge and expertise and even momentum that the current system has.  However, if those aspects are all driving you over a cliff then how valuable are they?  Along with this, technology is always changing.  The options we had a few years ago are not the same today.  There are new solutions and standards available that might bring overwhelming value to an original or from-scratch system.  It is easy to stay with the momentum we have, but sometimes all that provides us with is false confidence.

    Final Thought

    The bottom line in considering the pros and cons of these approaches is that your mileage may vary.  In order to make these aspects real some intentionality is required.  For example, if you want to reduce risk through an incremental approach to change, then each step needs to be examined thoroughly.  This examination includes looking for potential side effects and downstream impact.  None of these pros or cons are automatic, and the right approach can highlight the pros while reducing the cons.