Tag: productivity

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

  • Catching Up On Documentation and Overdue Tasks During a Lull

    Catching Up On Documentation and Overdue Tasks During a Lull

    Summer can be a frustrating time.  Much like the end of the year, there are a lot of vacations to work around, and your team varies from week to week.  That makes this an excellent time to take your vacation as well.  However, when you find yourself at work with limited staff or tasks waiting for people to return, there is an opportunity for catching up.  Those secondary and less important tasks that never seem to get done are excellent targets during these slow times.

    Getting Ahead

    One of the areas where it is easy to get behind is planning.  You know the Fall and wrap up of the year will be busy.  It almost always is.  Thus, this is a perfect time to look ahead to those hectic months and search for tasks you can start or even complete in this slow time.  It can be a time to lay down plans for the push and create documentation outlines where possible.  The work may not be such that it can be completed and off your plate.  However, any steps you take now will be less time to spend during that rush.  This is also a time to set things in motion if you are going to need vendor buy-in, customer sign-offs, or other administrative tasks that can often drag out the completion of a project.

    Catching Up On Overdue Tasks

    Planning takes some thought and forecasting.  Overdue tasks do not suffer from these restrictions.  You know what needs to be done.  Many of these tasks are the kind that languishes on your to-do list for weeks or months.  Why not remove those headaches and stress by knocking out some of your “productivity debt?”  When you take action your days will move along quickly and you will be thankful in the months ahead that you did.

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