Author: Rob Broadhead

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

  • Use Research Time To Improve Your Team

    Use Research Time To Improve Your Team

    The schedule of every IT team I have worked with is full.  There is always a steady stream of tasks to be done and technical debt to address.  This makes it easy for a manager or team lead to keep the whole team working at 100% (or more) day in and day out.  The problem with this full steam ahead approach is that it does not provide time for research of new technologies and skill development.

    Popular Example

    Google made news many years ago when they scheduled a day a week for employees to research and develop skills.  Their instincts were tapped to the tune of 20% of their time.  This is not a small investment in employees and the company itself.  As it turns out, Google has been a pretty successful company.  You can see all sorts of products that have come out of that investment in their employees.  Just take a little time and browse the Google labs projects.  Many of these came out of that time allotted for research.

    This example is a good one for us to consider in scheduling projects and workloads.  Google is known for their innovation and skilled workers.  Some of this success comes from the employees that have been hired, but some of the credit goes to management.  This success did not come overnight but what if your organization is considered world-class a few years from now?

    Running The Numbers

    I am not sure a 20% investment of time is going to pass most companies.  However, what is the cost of 10% of their time?  Specifically, consider the typical IT worker does not work forty hours per week.  Fifty or more is common.  That is a 25% increase in “typical” work week hours.  Therefore, you can look at the hours worked Monday through Thursday, and that often meets the typical forty-hour workweek.  Providing a “research on Fridays” benefit would effectively be doing so with “free” hours.

    The cost of blocking out half the day on Friday for research or personal projects would be easy to absorb by any organization.  It used to be built into a lot of consulting companies.  They had a little thing called “bench time” that was non-billable work while waiting on a contract.  That has disappeared from many companies as they try to improve margins and reduce costs.  However, that has a price.  I worked at a company that used their bench time to create commercial software products.  They could have turned those consultants loose as soon as the billable jobs ended.  Instead, they turned them into resources to create another revenue stream.

    Making It Work

    A program like this is not to be taken lightly.  There is plenty of room for abuse and missing the point.  I have found that a few ground rules and some structure will go a long way.  The first step is to build in some accountability.  This has a danger of becoming micromanaged, but it is too valuable to ignore.

    The level of accountability I am talking about is regular status and setting goals.  Since this is research work, then the goals can be flexible.  However, there must be something for the employees to aim for.  This can be a challenge for those that are not self-starters.  Help them lay out a plan for what they want to accomplish.  Just make sure that you push them to lead the discussion and work on something that appeals to them.

    When you have a team that is working for you and has a “bonus” each week of doing something to advance their career everyone wins.  The employees will get better while becoming more loyal to your organization.  There is a danger of employees growing to the point where they leave to start their own companies, but I would argue that as good publicity.  When you have an environment that fosters success, you will have a steady stream of people that want to fill those holes.

  • Hours, Effort, Completed Tasks and Measuring Developer Value

    Hours, Effort, Completed Tasks and Measuring Developer Value

    It may be the line of business I am in (consulting), but it seems like finding how to evaluate developers is a common challenge.  There are discussions and even arguments about developer value that impact employees, projects, and even companies.  Although I do not have some divine insight to provide, I do have some food for thought as you consider this obstacle.

    Developer Value Varies Geometrically

    The most significant challenge in finding the correct mix of skills and adequate compensation is that the growth from low to high developers is not a straight line.  The increase in productivity is geometric.  Thus, a senior developer is often more productive than junior developers splitting the same compensation.  That means that pure math is not going to help you compare resources.

    We see this in the way off-shore teams produce when compared to local resources.  Not all off-shore teams are lower skilled than local talent.  However, they often are.  The whole model of off-shore is based on quantity over quality so you can get a team of developers for the price of a local one.  The odds would imply that this will always be a better approach (more is better).  Unfortunately, that is not the case.  Those lower cost resources are not going to bring as much value to the table.  There are a few cases where this will work out better, but those are rare.

    Solving Problems Is The Key

    The thing to focus on when evaluating software developers is that they are problem-solvers more than skilled technicians.  The ability to write more code in less time has no value if the code does not provide needed solutions.  I often use the terms coder and developer to distinguish between these skills.

    Therefore, the real developer value is not in their ability to write code or even understand a language.  The value comes from their ability to analyze and solve problems.  This is why coding tests are rarely useful in evaluating prospects.  On the other hand, interviews and long-form discussions will go further in helping you choose the best candidate for your team.

    Hours or Tasks?

    Now that we have looked at what gives the most developer value, it is time to consider compensation and bonuses.  This gets far more tricky.  Although you can argue on both sides of this (hours spent or tasks completed), it turns out that both are flawed.  Sometimes it takes many hours to slug through a solution,  at other times your best developer can crank out a solution in a tenth of the time of lesser skilled ones.

    I hate to say it, but I find that honesty on both sides is the best answer.  This also requires patience and understanding.  Even the best developers will occasionally lose hours of time on a minor issue or misconfiguration.  If you want to punish them for those “lost” hours, then you need to provide a bonus when they stumble across a solution in far less time than expected.

    Ok, Hours Works Best

    When you balance out the good and bad luck that impacts developers (and dealing with the mistakes of others) then it seems that hourly pay works best.  That assumes these things balance out.  The good news is that it reduces the level of scrutiny needed.  Hours are easy to track.

    When you want to compare developers, you will need to track progress over multiple challenges or projects.  If you have a small number of comparison points, then it is easier to make a mistake.  This is no different from any other form of evaluation.  You need to focus on their overall body of work.  This includes customer reviews and references.

    If you only check a reference or two (or see only one or two reviews) then the odds of making a mistake increase considerably.  Take your time and gather enough information to accurately assign a value to your developers.  It will help you build and retain the best team.