Tag: projects

  • Finding A Good Scrum Master

    Finding A Good Scrum Master

    It is hard to believe many readers have not heard of the Agile approach to development.  This methodology is a hot approach, and all of the players are in demand.  Of these roles, the most in-demand appears to be the scrum master.  The challenge in filling this role is often figuring out what sort of skills are best for it.  Is it a technical role? A manager? An analyst?  Let’s look at what the responsibilities are and then the skills a good scrum master should have.

    Responsibilities of a Scrum Master

    When you break down the role, it becomes easier to find matching skills.  Therefore, we will start with the typical duties of a scrum master.  Note that these are not universal, but part of the variance in requirements comes from a lack of understanding of the role.

    • Act as a liaison between the developers and business owners
    • Push the development team to be productive (velocity)
    • Help avoid pitfalls and design flaws (technical and architecture leadership)
    • Balance current work and demands with technical needs and ability to deliver (project management)
    • Provide a steady stream of updates for users to assess and see as progress

    There are other facets of the scrum master role.  However, these are the high-level tasks of one that will be highly successful.

    A Mixed Breed

    Note that some requirements are technical, some you would find with a Business Analyst (BA), and some management.  This is not a common combination.  You cannot just pull out a developer or assign a BA or assign the role to a manager.  The scrum master needs to be able to wear each of these hats without being too heavy-handed while wearing those hats.

    For example, a strong scrum master will drive the team to make aggressive but reasonable choices for the tasks in a sprint.  However, they will ensure the team has buy-in for those choices as well.  Ideally, they lead without being seen as a leader, more as a facilitator.  This role can help with design and architecture discussions but should not be the one that dictates solutions or approaches.  They need to be technically skilled enough to understand the details of what is being implemented and communicate concerns to business owners or technical architects.  Are you worried yet?

    Seasoned Veterans

    The best scrum masters I have worked with are not new to the SDLC.  They have worked on good and bad projects in the past.  There is also a broad range of team sizes they have worked with.  Typically, the experience as a developer is at least five years with some experience as a lead and architect as well.  They also need to have experience in gathering requirements and working with BAs.  In general, they should be a well-rounded developer or technical BA that is ready to step away from a role that involves mostly coding on a daily basis.

    This last point may be the hardest hurdle to overcome.  Developers that have progressed to the desired level for a scrum master are often going to be ready to move into a technical leadership or architect role.  The technical BAs are positioned for management or product owner roles.  This leaves you with people that may be perfect for the part, but they are not interested in it.  It may be seen as a step-down.  In reality, the salary expectations may be an actual step-down.

    A Narrow Window

    Now that we have looked at what sort of skill set works best we can start to describe the kind of person that will work best.  This also can help you set salary expectations for the role.  First, some scrum master positions do not require a full-time focus on those responsibilities.  I have found that you can often run a team in around twenty hours a week, maybe a little less.  That makes a scrum master a part-time position.  Therefore, you can add responsibilities to “sweeten” the post for more senior staff.  You can also work in tasks for the scrum master that allows them to continue to advance their career.

    Even with these options, your best scrum master is going to be one with six to ten years of experience in development teams and multiple roles.  That puts your salary band in the neighborhood of an upper mid to lower senior level developer.  I often find this to be close to project manager salaries.  If you go lower, then you will struggle to find someone with the technical and leadership chops to handle the position.  If you shoot too high, then you will be wasting an expensive skill set on the scrum master role or put someone in that position that is too intimidating to allow the team to make their own decisions.  Do not shy away from adding in additional work for the candidate that will enable them to “earn” a higher salary or sweetens the position with work they want to pursue.

    In the end, a scrum master is a difficult position to fill but not impossible.  Do not be confused by the title or “agile” label.  Stick to the job requirements and you will be able to find a good fit without searching for a purple unicorn.

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

  • A mentoring presentation on creating an effective RFP process and documents. (AKA RFP tutorial)

    A mentoring presentation on creating an effective RFP process and documents. (AKA RFP tutorial)

    I decided to go over lessons learned from my experience with several RFP projects over the last few years.  I learned a lot from an excellent mentor and have added my own touches to create a process and documents that have been highly effective in a broad range of situations.  This provides a form of RFP tutorial that is highly recommended for anyone going through one for the first time.

    You can find it here: https://youtu.be/dx8vlSoUXs0