Tag Archives: Agile

Mastering Performance Management in Engineering Teams

Posted on by

As engineering leaders, one of our most critical responsibilities is effectively managing and developing our team’s performance. This goes beyond simply tracking metrics or conducting annual reviews. It’s about creating a culture of continuous improvement, open communication, and clear expectations. Let’s dive into some key aspects of performance management that can help you elevate your team’s effectiveness and job satisfaction.

The Art of Feedback

Feedback is the lifeblood of performance management. It should flow freely within your team, not just from manager to engineer. Many organizations offer training to help team members give and receive feedback effectively. As a manager, aim to provide feedback to your engineers at least biweekly. While technical feedback is important, don’t get too caught up in the technical details. Focus on broader aspects of performance and development.

A word of caution: be wary of feedback that’s overly positive or non-actionable. While positivity is great, feedback should always include areas for improvement or specific actions to maintain high performance. Remember, the goal is growth, not just praise.

Setting Behavior Expectations

When it comes to performance management, we often fall into the trap of creating “to-do” lists for promotion. However, what we’re really after is a change in mindset. We want our team members to be self-motivated, incorporating best practices into their daily work not because they’re chasing a promotion, but because it’s become part of their professional identity.

But how do we measure or change someone’s mindset? The truth is, we can’t directly measure it. However, the behaviors people exhibit serve as an excellent proxy. By setting expectations around day-to-day behaviors, especially in engineering-specific scenarios, we can create goals that foster the mindset we’re after.

This approach is inspired by Ben Horowitz’s famous “Good PM, Bad PM” blog post, which applied similar principles to product managers in the 90s and 00s. By focusing on behaviors rather than just outcomes, we create a culture of continuous improvement that becomes ingrained in daily routines.

The Power of Coaching

Effective coaching is a cornerstone of performance management and a critical skill for any engineering leader. It’s not just about solving problems for your team members; it’s about empowering them to solve problems themselves and grow in the process.

The Socratic Method: Questions as a Tool for Growth

One powerful approach to coaching is the Socratic method. Named after the classical Greek philosopher Socrates, this method involves asking probing questions to stimulate critical thinking and illuminate ideas. Instead of simply telling your team members what to do, ask questions that guide them to their own conclusions.

For example, if an engineer is struggling with a complex bug, instead of immediately offering a solution, you might ask:

  • “What have you tried so far?”
  • “Where do you think the problem might be originating?”
  • “What would be the impact if we approached it this way?”

This approach not only helps team members develop problem-solving skills but also increases their confidence and buy-in for the solutions they come up with. It transforms the coaching process from a one-way directive into a collaborative exploration.

The Importance of Explicit Language

Explicit Language isn’t about swearing, but on rare occasions that helps, but that’s a topic for another post.

When coaching, the clarity of your communication is paramount. Use explicit language to ensure your message is understood clearly. Be specific about what you’re observing, what needs to change, and what success looks like. Vague feedback or instructions can lead to confusion and frustration.

For instance, instead of saying “Your code needs improvement,” you might say “I noticed that the function on line 57 is handling multiple responsibilities. Let’s discuss how we can refactor this to improve its single responsibility and readability.”

Coaching for Technical and Soft Skills

While technical skills are crucial in engineering, don’t neglect coaching on soft skills. Leadership, communication, and collaboration are equally important for career growth. Help your team members identify areas for improvement in both technical and soft skills, and provide targeted coaching or resources for each.

The Continuous Nature of Coaching

Remember that coaching is not a one-time event, but a continuous process. Make it a regular part of your interactions with your team. This could be through scheduled one-on-one sessions, impromptu conversations, or even in the context of code reviews or project discussions.

By embracing the power of coaching, you’re not just solving immediate problems; you’re building a team of self-sufficient, confident engineers who are equipped to handle future challenges. This approach to leadership can dramatically improve team performance, job satisfaction, and overall success in your engineering organization.

Career Development: A Collaborative Effort

Career development should be a collaborative process between you and your team members. Start by creating individual development plans, or getting them to create them scales more and will have more meaning for them. These should be breathing documents that outline goals, areas for improvement, and action steps.

As a manager, it’s your job to provide opportunities for training and upskilling. Remember, you won’t always be the one who can directly train your team members. Most of the time, your role will be to identify and facilitate learning opportunities, whether that’s through courses, conferences, or mentorship programs.

Both you and your team members should have a clear understanding of what’s needed to reach the next level. An exceptional manager has a good sense of when all of their direct reports will be ready for their next promotion. This foresight allows you to provide targeted development opportunities and set realistic expectations.

Conclusion

Effective performance management is about more than just evaluating work. It’s about creating an environment where feedback flows freely, expectations are clear, and everyone is committed to continuous improvement. By focusing on behaviors, providing regular feedback, coaching effectively, and collaboratively planning career development, you can create a high-performing team that’s not just productive, but also engaged and satisfied in their work.

Remember, the goal of performance management isn’t just to improve output—it’s to help each team member grow, both professionally and personally. When done right, it’s a powerful tool for building an engineering team.

The Art of Hiring in Building Awesome Engineering Teams

Posted on by

As engineering managers, one of our most crucial responsibilities is building and maintaining high-performing teams. In this post, we’ll explore some key insights and strategies for effective hiring as a part of team building in the tech industry.

The Myth of the All-Star Team

Many of us dream of assembling a team full of tech leads, but the reality is that such a strategy is rarely feasible or even desirable, except perhaps in very small startups. The market simply doesn’t have enough of these high-level professionals to go around, and even if it did, there are compelling reasons to build a more diverse team.

Embracing Diversity in Experience and Skills

A truly effective team balances youth and experience, varied skill sets, and diverse backgrounds. While it’s tempting to hire only seasoned professionals, too much experience in one team can lead to conflicts and stagnation. On the flip hand, experienced team members often find fulfillment in mentoring younger colleagues.

It’s also crucial to avoid the pitfall of building a homogeneous team in terms of technical skills. A team of “all Java engineers,” for instance, might excel in their specific domain but struggle when faced with challenges that require a broader skill set, this makes them less able to respond to change, less Agile. Instead, aim for a mix of professionals who can work across different stacks, encouraging cross-pollination of ideas and skills within the team.

The T-Shaped Professional

“Overspecialization breeds weakness.” – Major Motoko Kusanagi

This philosophy applies perfectly to building tech teams. We should aim to cultivate and hire T-shaped professionals – individuals with deep expertise in one area (the vertical bar of the T) and a broad understanding of other related fields (the horizontal bar).

This approach not only creates a more adaptable team but also fosters an environment of continuous learning.

The biggest jump in my engineering knowledge was when I had to work with engineers that came from a different language background. It forced me to learn abstract language concepts to communicate effectively, which is a major step to becoming a polyglot.

Growing Your Own Talent

Sometimes, the best hire is the one you don’t make. As Ben Horowitz famously said, “When you can’t hire them, you need to grow them.” If you’re struggling to find the right external candidates, consider investing in developing your existing team members. Ask yourself: What would it take to turn your IC3 engineers into IC5s? This approach not only builds loyalty but can also be more cost-effective in the long run as hiring takes time and resources.

The Art of Headhunting

Never underestimate the power of your personal and professional networks when it comes to hiring. If you don’t have an extensive network, make one. Engage more actively on professional platforms like LinkedIn, get out into the community to conferences and meet people, leverage social media for hires.

Personal connections can significantly improve your hiring success rate. For instance, I maintain an almost 100% offer acceptance rate because I know most of my candidates through either my or my directs’ social networks. This allows for open conversations about expectations well before we reach the offer stage.

Common Hiring Pitfalls to Avoid

  1. Overemphasis on Technical Skills: While technical prowess is important, it shouldn’t be the sole criterion. Remember, it’s often easier to teach technical skills than to change someone’s personality or cultural fit. We hare engineering manager’s not psychologists.
  2. Rigid Skill Checklists: Instead of ticking boxes on a predefined list of skills, focus on understanding how a candidate can add unique value to your team. Some of my best hires have come from unexpected backgrounds, like Linux kernel experts or embedded systems specialists, simply because they were excellent engineers with the ability to adapt and learn. Embedded systems was an interesting one, you need to build in a lot of redundancy for things in remote location to have backups in the event of failure, its not unlike the web scale production systems we deal with.

The Crucial Probation Period

The probation period is your opportunity to evaluate a new hire in action. Use this time wisely:

  • Set clear expectations from the start
  • Create a structured onboarding plan with built-in evaluation points
  • Don’t hesitate to make tough decisions if necessary

Remember, passing someone you’re unsure about can have long-lasting consequences.

What if you pass someone you aren’t sure on? What are the consequences?

If you have to let them go later its impactful, not only on them but the team. They start to form social bonds to members of the team, letting someone go is never a good experience, and what ever experience they have they’ll be sharing with all their friends on the team after they leave, letting someone go they don’t just disappear. It’s much easier on the staff and the team if this happens earlier.

Conclusion

Hire is a core part of building an effective engineering team, and is both an art and a science. By focusing on diversity, adaptability, and cultural fit, while avoiding common pitfalls, you can create a team that’s not just technically proficient, but also innovative, collaborative, and poised for long-term success.

Building Awesome Teams: An Engineering Manager’s Guide

Posted on by

Welcome to our comprehensive series on the art and science of building exceptional engineering teams. As we embark on this journey together, let’s start with a fundamental question that lies at the heart of engineering leadership:

“What is the job of an Engineering Manager?”

If you were to ask me this question, my answer would be simple yet profound: “Building Awesome Teams.”

This straightforward statement encapsulates the essence of engineering management, a role that extends beyond technical oversight or project management. Building awesome teams is a continuous process that begins the moment you start hiring and continues through every stage of an engineer’s journey with your team, right up to and including the point when they move on to new challenges.

Tech: A People Problem in Disguise

One of the most crucial insights that any engineering leader can gain is this: Tech is, first and foremost, a people problem. The sooner you realize this truth, the sooner you’ll start winning at tech.

Yes, we work with complex systems, intricate code, and cutting-edge technologies. But at the end of the day, it’s people who write the code, design the systems, and push the boundaries of what’s possible. It’s people who collaborate, innovate, and turn ideas into reality. And it’s people who can make or break a project, a product, or even an entire company.

Exploring the Art of Team Building

In this series, we’ll dive deep into all aspects of building awesome teams. We’ll cover topics such as:

  1. Hiring: How to attract, identify, and onboard the right talent for your team.
  2. Performance Management: Strategies for nurturing growth, providing feedback, and helping your team members excel.
  3. Execution: Techniques for forming effective teams, collaborating across departments, and delivering results.
  4. Managing Exits: How to handle both voluntary and involuntary departures in a way that respects individuals and maintains team morale.

Each of these topics is crucial in its own right, but they also interlink and influence each other. By mastering these areas, you’ll be well on your way to building and maintaining truly awesome teams.

Why This Matters

In the fast-paced world of technology, having a high-performing team isn’t just a nice-to-have—it’s a necessity. They’re better equipped to solve complex problems, adapt to changing circumstances, and deliver value to your organization and its customers.

Moreover, awesome teams create a positive feedback loop. They attract more great talent, inspire each other to greater heights, and create an environment where everyone can do their best work. As an engineering manager, there’s no greater satisfaction than seeing your team thrive and achieve things they never thought possible.

Join Us on This Journey

Whether you’re a seasoned engineering leader or just starting your management journey, this series has something for you. We’ll blend theoretical insights with practical advice, drawing on real-world experiences and best practices from the field.

So, are you ready to dive in and start building awesome teams? Let’s begin this exciting journey together!

Stay tuned for our first installment in the series

Too Many Meetings?

Posted on by

I ran a survey recently with my engineers about their pain points. The number one pain point was too many meetings. This is a common complaint with teams that do Scrum, but our Scrum is pretty lightweight, so I started to dig a bit further – “go see.”

I sat down with a few of my engineers and, after confirming they agreed that they have too many meetings, I bluntly said to them, “Show me your calendar.” As I suspected, in all cases, it was pretty sparse, except for one of my tech leads, which I understood. What I did notice, though, is that they had meetings mid-morning and mid-afternoon consistently.

So my hypothesis was: it’s not that they have too many meetings; it’s that they get interrupted and don’t have long periods of focus to work. Working as an engineer before, I understand this. You need a good few uninterrupted hours every day to get into your zone and get stuff done.

I’ve had to deal with this before (as I said, it’s a common complaint in Scrum) and also have colleagues that have as well. Based on past experience, I was able to put together something that we tried. It starts off a bit draconian, but I think you have to because people always bend the rules. So here’s the guidance we came up with:

Practices around Meetings

Please observe the following practices around meetings to enhance productivity and maintain focus.

No Meetings after Lunch

Engineers need at least 2-3 uninterrupted hours straight each day, more if possible. This uninterrupted time is crucial for deep work and maintaining a flow state, which becomes essential for problem-solving and creativity in engineering tasks. According to Cal Newport, author of “Deep Work,” uninterrupted work periods significantly enhance productivity and job satisfaction.

While this may be challenging on sprint planning days, consider making one day per sprint an exception to this rule for sprint ceremonies. Getting other teams into this habit might also be difficult, but targeting one director area at a time can make it more manageable. Here are some tips to deal with it.

Alternative: If morning meetings are challenging, consider scheduling additional meetings at 5 pm to ensure uninterrupted work periods during the day until at least 5 pm.

Default Meeting Time is 30 Minutes

Avoid scheduling 1+ hour meetings at all costs, unless absolutely necessary. Shorter meetings encourage people to arrive on time and be efficient. It also pushes attendees to get to the point quickly and wrap up discussions promptly. Parkinson’s Law states that work expands to fill the time available for its completion. Therefore, shorter meetings can help in focusing discussions and give more time back to attendees.

Tip: If a meeting finishes early, LEAVE, rather than extending discussions unnecessarily.

Review the Purpose of Each Meeting

Assess the necessity of every meeting. If the meeting’s purpose can be achieved via an email or a Slack chat, do this instead. This helps reduce the number of unnecessary meetings and allows more time for focused work.

Tip: Establish clear agendas and goals for meetings to determine if they are truly necessary.

Combine Meetings with the Same Attendees

If you have two meetings that require the same people, schedule them back-to-back in the same room. This approach not only ensures everyone is on time for the second meeting, but if the first meeting ends early, you can start the second one earlier, and potentially give people back more free time.

Supporting Information and Citations
Newport, C. (2016). Deep Work: Rules for Focused Success in a Distracted World. Grand Central Publishing.
Parkinson, C. N. (1955). Parkinson’s Law. The Economist.
Harvard Business Review. (2017). Stop the Meeting Madness. Retrieved from Harvard Business Review.

[Previous content remains unchanged]

Conclusion

Implementing these meeting practices can significantly improve team productivity and engineer satisfaction. By prioritizing uninterrupted work time, keeping meetings focused and efficient, and critically evaluating the necessity of each meeting, we can create an environment that fosters deep work and creativity.

Remember, the goal is not to eliminate meetings entirely, but to make them more purposeful and less disruptive to the flow of work. As we adopt these practices, we should:

  1. Regularly check in with the team to assess the impact of these changes
  2. Be flexible and willing to adjust the practices as needed
  3. Lead by example, adhering to these guidelines ourselves

It’s important to recognize that changing ingrained habits takes time and persistence. There may be initial resistance or challenges, especially when coordinating with other teams or departments. However, the potential benefits – increased productivity, improved job satisfaction, and higher quality work – make this effort worthwhile.

By fostering a culture that values focused work time and efficient communication, we can help our engineers thrive and deliver their best work. Let’s view this as an ongoing process of optimization, always seeking ways to improve our work environment and practices.

Push Groups: Encouraging Adoption of New Tools and Technologies

Posted on by

Another process I’ve been trialling I wanted to share:

Sometimes when you want people to try something new you need to be a bit pushy to get them out of their comfort zone. This is where Push groups get their names.

Push Groups are structured sessions designed to encourage and facilitate the adoption of new tools and technologies within software engineering company. These groups typically consist of 3-4 people from different teams who come together to learn, install, and practice using a new tool or technology.

In the session is “very” hands on. We generally start with the installing the tool on everyone’s laptops, then run through some exercises that participants are required to complete in front of the organiser and share their immediate feedback of why the tool does or does not work.

This serves two purposes

  1. It pushes people to try something they otherwise would not have
  2. It gives the orgnaiser immediate feedback of issues they might not have know

In one example where we used this, we noticed many of our engineers in one area where not using customs shells they were just using vanilla Bash terminal on Mac or Powershell on windows. So we ran a session on Terminal tooling with ohmyposh, windows terminal etc. (we did a separate session with other tech for mac users, I’m using the windows one as an example because its the one geriatric old me that’s familiar with windows tooling ran).

In the first session we got them to install it, pick their themes/fonts (a bit of fun), try some common tasks, like git clone and run one of their repos using npm cli etc. demoing common quality of life features like git/k8s/etc information in the cli, statement completion, etc.

During the session one of the of the devs raised to me, he said: “Look, this is cool, but I never use the terminal outside my IDE, I only use it inside. I then realised its a totally different setup to customise the terminal inside the IDE, but in the session we worked it out and updated the content so that we supported both.

After the session there’s two goals

  1. Use it! – try honestly to use this new thing over the next two weeks, push yourself a bit to try it. And provide feedback about what does and doesnt work.
  2. Run another session for your team the same – even if it doesnt work for you, and get them to do the same thing and provide feedback

Most of the time we find that tools that are useful take off and reach critical mass and become ubiquitous, sometimes though things dont work, and that’s ok, as long as you get the feedback and learn.

Tethics Moments

Posted on by

A long time ago we had to do this exercise called “Ethics Moments”, I think many companies run these, they are pretty common. I liked the format, the scenarios though were not relevant to my engineers. They never face issues with Bribes from local government officials for example. They do however, everyday face what I would call “Technical Ethical” issues around technical debt, collaboration with other teams, execution decisions, etc.

So I decided to use the format but create scenarios more relevant to day-to-day for engineers. And as a play on words used the Term “Tethics”. And got engineers talking about what to do in certain scenarios relevant to day to day.

So let’s dig into some details.

Why are we here?

As engineers, we do things the right way, but we often seem to only limit this to a moral and ethical scope. With Tethics moments, we want to open this discussion of integrity also to the technical work we do. What is the right way to deal with technical dilemmas without hurting the product in the short term or long term? This can be very subjective, and on top of that, we also want to move fast, so how do we solve these problems so we can move fast tomorrow as well?

Create the Scenarios

A scenario should be a dilemma, and something that happens day-today.

I regularly have beers with my engineers, and sometimes when I do, I hear some crazy stories about code reviews, design reviews, etc generally when people are working with teams less mature or under pressure. Pressure is one of the main reason for technical debt in my opinion.

You dont have to be a beer drinker to create scenarios, but you do need to create a comfortable environment (RE: psychological safety, topic for another post) where your engineers feel comfortable speaking out, and this will help you find these things, the ones that come up more often are the ones you want to use for senarios.

I break these up into 3 sections title, description, and notes for the session leader, the notes help guide the conversation in the right direction, which should happen in a leader session anyway, which I’ll go into next. But the reason you need guidance is sometimes your engineers dont understand that they can push back, sometimes they think “this is the way things are” and when this is the case, you need some guidance so the session leader is confident to break them out of this.

I’ll give you an example of one of ours that I think will be relatable to a lot of orgs.

Scenario:
Owner vs Contributor

Description:
You are a system owner for “Generic Frontend System 2”.​
A backend team has sent you a large pull request for review, without a prior design review or any notice the work is coming. ​

It looks clear from their PR that they don’t have the best ReactJS skills, and it needs a lot of reworking, they’ve even managed to introduce a new state management library in their work. On top of this, the fact that it’s so large means it will probably take the team many days, or even weeks, to make all the needed changes.​

When you raise this with them, they say that they are on a hard deadline with Product changes, need to get this into production fast to meet their KPI for the quarter, and argue that it’s still functionally working, even though the code is not up to standards, so they ask if you can let it pass anyway.​

What should you do?

Notes for leader:
In the end it up to the system owner (you in this scenario) how they handle this, if you have push back against what you want (e.g. them fixing their code) and you don’t like it, escalate straight away to manager and higher if you need.​​ You’ll get support for this.

A common practice though, is that if its not “too” bad, getting a commitment from the team that they will immediately work on a fix after it’s merge, and bringing their manager AND PO into the room to make sure everyone is clear on the commitment. The PO is the one that a) has the most control over the sprint backlog and b) is most concerned with getting it into production that fastest, and may also be the one that tells every “its ok to wait”, you’ll be surprised.

<end senario>

So you can see we are leaving it pretty open here, in our company, system owners are the one that ultimately are responsible for the technical debt of their system, it’s part of our ownership culture, so it’s up to them how they handle it, there is guidance there because sometimes our system owners dont feel empowered, sometimes teams are under a lot of pressure and get into ruts, so this type of encouragement helps them get out of it.

The second part of the notes is talking about compromise, because sometimes you need it, but its ultimately up to you how you do this, its just one suggestion.

How to distribute sessions top down

“Top down” is usually a trigger word for me, living in South East Asia, where many companies have a bad top-down cultures. But in this case its not, its important for leaders to help shape a good culture, and this is one tool for helping.

The first session you should run is one with your leaders or managers, run them through the scenarios. Then they get your direct feedback on what is your expectations of how engineer should be dealing with these through the conversations. This is needed because ultimately if an engineer sees a problem and escalates and everyone is aligned they’ll get support from the top, if we arent aligned they might not and this will cause a problem for them.

After this tell them to run with their directs, and so on, for larger numbers of direct report you can run session with leads and send them out, or run multiple session, varies with your org structure.

Finally the session itself

How to run a session?

  • Use the deck of scenarios (have at least 6-7). As a Tethics leader, you should read through them and pick 3-4 you feel are most relevant for your direct reports or team members (depending on how you are running it).
  • Schedule a 1-hour session with direct reports
  • Limit session size to 4-5 people maximum – if you have more people, then schedule multiple sessions.
  • Fewer people means more people will speak out.
  • Read a scenario together, then 15-20 minutes go around the group to ask what each person thinks the right thing to do in that scenario would be. – There is no right or wrong answer to most; it’s about an open discussion.
  • Repeat the process for your selected other Tethics leaders to run with other people.

Are you the moderator?

  • Ask each person to talk and have their say one at a time.
    • Choose a different person to start talking for each scenario.
  • Don’t interrupt people as they are talking.
  • Save your personal opinions on the subject for the end of everyone else talking.
  • Focus more on commenting on others’ opinions than voicing your own.
  • Try Lead people to a better conclusion by questioning (RE: Socratic method of coaching, another topic post) rather than disagreeing.

And that’s it, please let me know if you try this and what your stories are in the comments.

One Story, One Day. Agile Process

Posted on by

This is a process I’ve tried a few times over the years and wanted to share, its great for teaching your team to teach themselves about common problems and blockers they have, and also getting them to understand how to work better as a team rather than a group of individuals.

This is how it goes:

Take a medium-sized story, put the team in a room, and get them to try to do it in a single day working together. Most of the time they will fail, but they’ll learn.

This helps answer the question, why can’t we get a story done in a short period of time?

Why is this important? During a two-week sprint, sometimes you have to wait for things, so you wait and go work on something else, and it doesn’t matter because you have a full 2 weeks, right? You don’t notice or try to fix these things. These things slow you down, examples are:

  • The flaky CI that you rerun a few times and 6 hours later it’s ready.
  • The code review ping pong that goes for 6 days.
  • The multiple systems that need to merge/deploy in order because for 1 story you need to change 3 systems.
  • The systems that take a whole day to get working on your laptop because you haven’t touched them in a month.

On top of finding the problems, the team also learns how to collaborate on a single story. This helps with not only faster delivery but also sharing of knowledge within the team.

This is good if you see this type of behaviour in your team:

  • At the start of the sprint, each dev picks up a single story and works in isolation
  • Standup meetings seem unimportant because everyone is working on different things
  • During the day your team is not talking; in office situations, they may put headphones on and ignore the rest of the team for the whole day
  • When questioned, you consistently get feedback “we can’t get more than one person working on this”, which usually means they’ve never tried

Note: It’s ok for devs to do short periods in isolation, they should not be “pairing all day” as some extreme companies encourage, but an entire day or more is a warning sign.

Expanded Process

1. Pre-exercise briefing (if it’s the first time)
   – Set expectations and explain the purpose.
   – Get buy-in from the team; if they don’t believe it’s a good idea, they will make it fail.

2. Story Selection:
   – Team agrees on a medium-sized story that would typically take several days to complete.
   – The story should be challenging but potentially achievable.
   – Choose a number of man-days similar to the people in the team if you use man-day estimation.

3. Team Composition:
   – Ensure the team has diverse skills to cover all aspects of the story.
   – Possibly including people that are needed for code review approval, deployment, etc.

4. Environment Setup:
   – Prepare a dedicated workspace where the team can work without interruptions.
   – Book a large meeting room.
– Set up Pairing Stations for a day.

5. The Day:

   – Set a strict one-day time limit, e.g., 8 hours.
   – Begin with a brief planning session to break down the story into tasks, 30min time box.
   – Execute, encourage pairing, and regular communication, time box 7 hours.
   – Call it on time, tell the devs “hands/pens/keyboards down”, at the end of the day, the goal is to learn rather than finish, don’t let them work into the evening, even if they want to. You need time for retro.
   – Conclude with a team retrospective to discuss learnings, challenges, and insights, 30min time box. This is the most important part, they can run overtime on this 🙂

Implementation Notes:

1. Frequency: Implement this approach periodically, not as a daily practice.
2. Follow-up: Use insights gained to improve regular work processes.
3. Balance: Combine with other agile practices for a well-rounded approach.

Agile-Scrum Interview Questions to a Company from a Candidate

Posted on by

I recently went for a job interview with a company and wanted to know how evolved they were with respect to agile practices. So using the Agile manifesto I created a series of questions to ask them in the interview to rank how evolved they were in following Agile/Scrum processes.

I think if you are looking at your own company you could use these as a method to judge your own progress in your journey into Agile/Scrum.

Below is listed each Principle follow by the question i asked.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

How do you do you do a release? Do you hand over to another team for releases? Do you practice continuous delivery?

With the rise of Dev Ops, pushing releases should be easy these days, if you have a complex process in place for pushing releases to live, it might be a sign that you need change.

How I’ve seen people try to justify complex release and release/approval process before is when you have critical systems that any sort of downtime will have a large business impact. You will hear them say things like “We work in E-Commerce, any minute offline is lost money” or “We are in finance, one wrong number could cost us large amounts of money”. These statements are true, but in an evolved company you have things implemented such as A/B testing, tests that run in the deployment process to verify applications on an inactive node before live traffic is cut over to. AWS’s Elastic Beanstalk out of the box will run you up a new set of servers in the deployment process that tests can be preformed on before a DNS cut over is done and the old environment completely shut down.

While you do need to take into account the context, there is few companies I have seen that could not aim for continuous delivery.

Zero-Downtime deployment, and Continuous delivery are the two key words that give you a big tick here.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage

How do you handle change in requirements after development work has started, or finished?

If they tell you that they have “Change Requests” that’s a sure sign they aren’t following Agile/Scrum process.

Another common mistake I see people do is track this and report on it so they can “improve planning”, while I am not saying that you shouldn’t try to plan ahead where possible, trying this will give you a lot of false positives, because one of the theories of scrum is that “the customer doesn’t know what the right product is, until they’ve seen the wrong product”.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

How often do you release? How long roughly does it take you do do a release of your product?

Similar to the first question, releases should be done “on demand” by the team, if there is any hand over process in place, or senior management that needs to be involved beyond Acceptance testing in the demos then this might be a sign of problems.

Business people and developers must work together daily throughout the project

Where do your requirements come from? Where are they stored? Who manages them? What contact does this person have with the team?

This question in summary is “Do you have product Owners? and are they doing their job?”. Product owners should have daily contact with the team, however having them in the same room might be too much. The company I went for the interview with has their Team, PO and scrum master all in the same desk cluster, I’m not sure about this 🙂

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Who manages your teams and makes sure they are keeping focused day-to-day?

This is a loaded question. Unmotivated people need people to motivated them and don’t make for a good dev team.

The answer should be no one, because our teams are self-motivated and self organizing, our scrum master checks in with them daily to make sure they don’t have any impediments and keeps the team from distractions.

Do you have any regular reporting to upper management that needs to be done inside the sprint?

The answer here should be no, the measure of progress is working software, which is reported in the demo. There maybe reports to the business of a rolled up result of sprints, for example one feature make take 3 sprints to complete, so at the end of those 3 sprints some additional reporting needs to be done. But beware of anyone that says something like “The output of our daily stand-up on in the chat room is emailed to all senior managers in the business”, this means that there is a lack of trust in the organisation.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Inquire about which ceremonies they conduct, Daily stand-up, retrospective, etc.

Is there any they don’t do? Is there any they do in a chat room? Where is the scrum master and product owner located? Does the team have easy access to them and vice versa?

In some teams that aren’t co-located this is difficult, but let me tell you from experience that video conferencing is the answer if you aren’t co-located.

While I think chat rooms are an important part of a modern team (Go download slack or hipchat now if you aren’t using them already, but don’t ask me which is better), they should NOT be used for your ceremonies. When you do a planning meeting and you are in the same office as someone you see and hear the emotion in their voice when they are talking, this is vital to good communications.

Also talking as opposed to typing lets people go off on tangents more easily, which generally leads to better innovation. The same is true of Stand ups, retrospectives and so on.

Working software is the primary measure of progress.

How do you measure progress of your dev team?

This one is pretty easy, if they say from the deployed running software then they get a tick.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

How often do you staff work overtime? is any weekend work required? if so how often?

If you have staff regularly working overtime or weekends, and this is accepted by the organisation, this is a sign that your pace is not sustainable. You will burn your staff out, they will look for new jobs.

Continuous attention to technical excellence and good design enhances agility.

This is hard to put into a single question, I would start with asking them where they are at with practices like:

  • Unit Testing
  • Test Automation
  • Do they use Dependency Injection
  • etc

These types of technology will change over time, but once you have an indication of where they are at, how do they improve? Good answers will be things like involvement in open source projects, user groups (VMWare, etc), partner programs (Microsoft, RedHat,etc) and so on.

One of the processes we used to use was “Friday Afternoon Channel9” each week the team members would take turns picking a video from MSDN Channel9 (and sometimes other sources) and we would all watch it together.

 

The best architectures, requirements, and designs emerge from self-organizing teams.

Do you have team leaders or managers?

If you have a manager then you are not self organised. By the same token Leaders are bad too, a lot of people are astounded by this concept and would argue that leadership is a good thing.

If you promote leadership then you give your team a head that can be cut off, what happens when you leader goes on holiday for 3 weeks?

It also prevents your team from taking ownership if the are working under someones directions. You will end up with a product architected from a single persons view as opposed to the entire team. This also allows the team to say things such as “I was just doing what I was told”, your team needs to own their work, this in the long run will give them more job satisfaction as well.

In short, everyone on your team should be a leader, and the scrum master should be their to mediate any conflicts of direction.

Your scrum master should not be a member of the team also, he/she needs to be impartial to the team’s decisions to allow him/her to give good guidance. If your scrum master is a team member he will end up becoming a leader and you will have problems.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What is the most astounding changes one of your teams has proposed from a retrospective that you can remember?

A bit of a loaded question again. If you simply ask them “Do you do retrospectives” this won’t tell you much, what you need to be asking them is what impact their retrospectives have.

The answer to the above will give you an indication of if they are following the Scrum retrospective process and seeing a positive outcome from it.

One of the Keys of Scrum is Empirical Process Control, if the team is not in charge of themselves, then they do not own their actions, retrospectives is a key point in the team shaping their own direction.