Tag: software development

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

  • Building a Team For The Long Term – Keeping Core Staff

    Building a Team For The Long Term – Keeping Core Staff

    There are so many factors that go into a successful development team that it can seem like an impossible task.  The technology and requirements seem to change daily, and there are always options for staff to move to another job.  All that being said, there is a considerable value in keeping core staff in the team and creating long-term stability.  This is not a goal that will just magically be accomplished.  It takes some planning and effort as well as communication with the team.

    A Career Path

    One of the traits that all good developers share is a passion for advancing their career.  It is important to recognize that career advancement is not just a title or higher pay.  Both of those are important, if not critical.  However, there is far more to a successful career path.

    It may seem obvious, but the best among IT staff tend to the technical.  They may advance to where they do not write code every day, but that does not mean they will not be technologists.  There are managerial, mentor, and architect roles that can be very technical in day-to-day tasks.  Thus, the career path you offer should be a steady growth towards scaling the skills of your best staff, not a choppy series of steps.

    This approach does make titles sort of “fuzzy” in their application.  That can be a challenge, but it does allow for a natural progression of skills, experience, and responsibilities.  For example, There should be a lead role that is not a senior developer nor a manager.  This provides a path into testing (and refining) management and leadership skills from a developer.  The staff can progress without a trial by fire approach where they are thrown into a role 100% and without much support.

    Perpetual Mentoring Everywhere

    A good team starts at the top and carries through to the bottom a culture of nurture or mentoring.  Every role must include a mentorship or teaching aspect.  Thus, the team will have an internal drive to improve itself by improving every member.  When you have this sort of environment you have one that is not only positive for the team, it also attracts the best from elsewhere.

    The thing about an environment that fosters growth is that it is not easy to find.  When a “guru” or “superstar” developer hears about a job that exists in this environment, they are immediately attracted to it.  Of course, that creates a snowball effect where the team that builds itself draws those that desire to develop the team.  Before you know it, you have an organization like Google or Amazon where everyone is knocking on your door to be a part of your story.

    Money Talks

    For better or worse, money is an important part of keeping core staff.  You can be an incredible organization that does not pay very well.  However, that will soon fade as the best on your team are lured away by better compensation.  On the other hand, developers often like to stay where they are and avoid the “headaches” involved in moving to a new job.

    This is where momentum works to your advantage.  You do not have to be the best deal in town.  A compensation plan and approach that shows your respect for the team members will offset that deficiency.  Likewise, stay competitive in how you compensate staff and include some bonuses that factor in the savings associated with a stable team.  I love the idea of retention bonuses that payout based on staying with the company for another year.  This sort of plan can do wonders in keeping staff around for a while.  Better yet, it often stops them from looking for another job based on cold calls.  Yes, they will still leave a negative situation.  They just will not be as likely to consider out-of-the-blue offers throughout the year as they will be steadily focused on the next bonus day.

    In the same way, there should be regular reviews and raises.  It is difficult to wait until a team member complains about their situation before acting.  They may have already decided to leave no matter what your response whereas being proactive can win back a member before they are lost for good.

    Value Them

    The bottom line in all of this is to value your team members. Show them the respect you have for them as people and workers on a regular basis.  Make it evident that they are appreciated and that you desire them to grow as individuals, not just as a team.  This goal can be achieved without spending much more money.  However, it cannot be reached without being intentional about bringing forth the best from every member.

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