Steve Berczuk
Steve Berczuk
Member for
9 years 6 monthsSteve Berczuk is a Principal Software Engineer with experience as a manager, Scrum Master and technical lead in Boston, MA. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a Certified ScrumMaster. Contact Steve at [email protected] or visit berczuk.com and follow his blog at blog.berczuk.com.
Steve Berczuk is a Principal Software Engineer with experience as a manager, Scrum Master and technical lead in Boston, MA. The author of Software Configuration Management Patterns: Effective Teamwork, Practical Integration, he is a recognized expert in software configuration management and agile software development. Steve is passionate about helping teams work effectively to produce quality software. He has an M.S. in operations research from Stanford University and an S.B. in Electrical Engineering from MIT, and is a Certified ScrumMaster. Contact Steve at [email protected] or visit berczuk.com and follow his blog at blog.berczuk.com.
All Articles by Steve Berczuk
All Stories by Steve Berczuk
|
A Physical Metaphor for Quick Fixes and Root Cause Analysis If you deal with legacy code you’ve likely found yourself struggling to debug and fix a mysterious, intermittent problem. Along the way you may have discovered some code that didn’t quite make sense. |
|
Prioritizing Invisible Work There are work items that will give the team an operational boost and perhaps avoid a crisis, but that never make it to the top of the priority list—like build and deployment improvements, or paying down technical debt. For enabling work that is valuable but too invisible to be a priority, consider breaking it down. |
|
The Real Value of Cross-Functional Agile TeamsAgile teams know that cross-functional collaboration is central to the methodology, but there are often barriers to fully embracing this idea. If teams are used to handoffs, it may seem like it makes sense to maintain the status quo. Try collaborating on something small to realize the true value of cross-functional teams. |
|
Code Integration: When Moving Slowly Actually Has More RiskMany decisions about code branching models are made in the name of managing risk, and teams sometimes pick models that make integration harder in the name of safety. Moving slowly and placing barriers to change can seem safer, but agile teams work best when they acknowledge that there is also risk in deferring change. |
|
Defensive Design Strategies to Prevent Flaky TestsFlaky tests could be the result of issues in the code, but more often they are due to assumptions in the test code that lead to non-relatable results. There are many reasons that tests can fail intermittently, and some can be easily avoided by applying good defensive design strategies. It's all about making your code agile. |
|
Achieve Repeatable Builds with Continuous IntegrationContinuous integration is essential to provide the feedback needed to keep a team’s code agile. One crucial aspect to a successful CI process is a repeatable build. There are two parts to maintaining a repeatable build: the idioms and practices to define it, and the feedback cycle to maintain it. Here's what you need. |
|
Is the Problem with Your Agile Tool, or How You’re Using It?While using index cards and a wall can function just fine as a kanban or Scrum board, issue-tracking tools such as Jira can make it easier to manage a backlog, especially with a distributed team. But these tools are more complex to use and can add their own overhead to the process. You need to keep things simple. |
|
Good Process, Bad Process“Process” is a word that seems to have a lot of baggage. Depending on whom you ask, process is either essential to delivering value, or something that gets in the way. But this is the wrong way to frame the issue. A process is not inherently good or bad; it's how you use it, and whether it's right for your situation. |
|
Scrum Roles, Goals, and YouThe Scrum Guide specifies that there are three roles: product owner, developer, and ScrumMaster. It’s essential that a Scrum team have each of these roles to help it work well. But depending on how you implement the roles, you may end up hurting rather than helping your Scrum process. Focus on goals, not job titles. |
|
One-on-Ones: A Framework for FeedbackRegular one-on-one meetings between a manager and employee are a forum to provide safe, timely feedback. They can be short or longer, but you should discuss successes, challenges, and how to improve. Having a framework for the conversation helps you make sure that the meetings don’t routinely become chat sessions. |
|
From Documentation to AutomationA defined, repeatable process frees people from spending energy thinking about solved problems, and an automated one makes this even easier. While not all development steps can be easily automated, some can, and documentation is an essential first step. Automate what makes sense and you'll have reliable processes. |
|
Don’t Ask for Permission or Forgiveness—Use an Agile AlternativeSome teams get around bottlenecks by taking a “better to ask forgiveness than permission” approach. This may be expedient, but it doesn’t provide a path to changing the organizational dynamic, and it can lead to wrong decisions when wider input is advisable. A more agile way is to take an “I intend to” approach. |
|
Is Your Culture about Responsibility or Blame?When things go wrong, it can be helpful to understand what happened and who was involved. However, all too often organizations (and the managers within) confuse responsibility with assigning blame. The former is essential for improvement. The latter works against an effective, collaborative, productive culture. |
|
Building Good Scrum HabitsBuilding good habits is an important part of an effective Scrum team. Habits are a form of automation: The more basic processes we can automate, the more we can focus our energy on hard things. The Scrum process, with its focus on rituals, helps us by providing a framework for collaboration and making it second nature. |
|
Supporting Scrum: Adopt before You AdaptScrum is a fairly minimal agile process framework that you can adapt to work best for your team. But adaptation works best once the team has internalized the principles and values of the Scrum process, and that takes practice. In other words: Before you start to adapt Scrum, first try fully adopting the framework. |
|
Are Your Retrospectives Adding Value to Your Scrum Team?Sprint retrospectives are often skipped, compressed, or organized in a way that doesn't provide good feedback. This is unfortunate, as a well-planned retrospective is a great way to improve how you work. Good retrospectives enable engagement and safety, distill and prioritize ideas, and create concrete action items. |
|
How Embracing Differences Makes More Robust Agile TeamsOn any team, there are bound to be some differences. But even though work styles may differ from what you expect, they may not be problematic simply because they are different. Before making assumptions about what a teammate is doing or why, just ask to find out. Their differences may bring a helpful new perspective. |
|
The Myth of Too Many Scrum MeetingsA common complaint in organizations adopting Scrum is that Scrum has too many meetings. However, people may not be considering all the time they spent meeting before Scrum—and how effective that time really was. As long as you keep meetings focused, people should waste less time in meetings than they did before Scrum. |
|
The 3 Kinds of Learning That Influence Your WorkThe degree of confidence in your knowledge may vary, often due to the process you went through to learn the concept. An understanding of how different learning techniques affect the depth of your knowledge can help you with how you process information you already have and how to approach learning new things. |
|
Making Testing Work within Your SprintsA common problem for Scrum teams is having a good understanding of what work is complete by the end of the sprint. Teams often end with a few items coded but not fully tested, but since the goal of a sprint is to have a deliverable increment of work, skipping tests isn’t a good idea. Here's how you can fit them in. |
|
Scrum Can Help You See the Forest and the TreesIn project management, it's easy to focus on details to the extent that you lose track of the larger goal. Scrum can help you identify flaws and gaps, and skipping or trivializing Scrum events will just hide the fact that there are things you need to improve. Finding problems is something to be celebrated, not hidden. |
|
Beware Confidence Masquerading as CompetenceSelf-confidence is essential to tackling difficult problems. Where we need to be careful is not being falsely overconfident. What’s behind that overconfidence can either help or hinder your solving issues and achieving a good result. Here's how to make sure that confidence is backed up by competence in your team. |
|
The Agile Culture You Need for Faster Pull RequestsIs your process for pull requests compromising your team's agility? You can structure your changes in a way that facilitates more rapid feedback, but even then it is still possible to have a slow integration time if people don’t review pull requests promptly. Mechanics are part of it, but culture also matters. |
|
Getting Faster Pull Requests in an Agile EnvironmentPull requests may not seem to fit into agile development, but they can work well if done right. If you can maintain feedback on your working software from frequent integration, using PRs can help people understand your code. The speed at which PRs can be reviewed depends on three things: context, size, and atomicity. |
|
The Difference between Priority and Order in Your Agile WorkThe Scrum Guide talks about an ordered backlog, not a prioritized one. While order and priority are related, they are not the same, and understanding the difference and why people focus on one over the other can help your team be more effective at delivering business value. |
|
Aesop and Agile: A Moral for Effective TeamworkWhen a manager sees a problem on their team, they often want to act quickly to correct it. But if you take a “fix it” mentality too far, while you might get past the initial impediment, you have done little to help the team work better in the future. Let's look at another approach, based on one of Aesop's Fables. |
|
The Good, the Practical, and the ExpedientWhen a process isn't working, you'll have to make a choice that will help move things along. However, some choices are less about inspecting and adapting than about getting things done quickly, and that incurs risk. To manage this risk you need to be aware of the differences between "practical" and "expedient." |
| |
Do’s and Don’ts for Having a Technical Lead on a Scrum TeamTechnical leads can be useful, both within the dev team and as a go-between. But is that a good idea on a Scrum team, which should be self-organizing? There is nothing wrong with having a technical lead on your team, as long as the role doesn’t impede the team. Here's where a tech lead can help or hurt a Scrum team. |
|
An Agile Approach to Deciding When to DecideConsidering when to make certain decisions is just as important as how. “Inspect and adapt” is a valuable approach in agile, not only for product and process, but also for figuring out when to implement choices about your projects. Evaluating the reversibility, migration, and sustainability of decisions can help. |
| |
Refine Your Product Backlog Continuously to Improve FlowOne way to address poorly defined product backlog items is to spend time refining the items as you go. Refining the backlog continuously helps the team deliver consistently and can lead to shorter planning meetings at the start of the sprint. It can even help improve reliability, velocity, and the quality of work. |
| |
Solving Problems and Seeking Solutions on an Agile TeamWhile teams are composed of individuals, all of whom solve problems and make decisions, people on consistently successful teams understand that they can be more effective when the focus is on the team, not the individual. Making the best decisions collectively delivers the most value to customers in the long run. |
|
A Musical Metaphor for Agile EstimationMany explanations of relative sizing in agile estimation fail to capture the mix of knowledge, skill, and effort involved in completing a task. Learning to play a song seems to capture the core ideas of estimation. With a metaphor, it is easier to come up with baselines to estimate against for your own agile sizing. |
| |
Agile Collaboration on Remote TeamsThe first value in the Agile Manifesto is “Individuals and interactions over processes and tools,” and for many teams, being located in the same place facilitates these interactions. However, being part of an effective, collaborative team is less about location than it is about motivation and good practices. |
|
Feature Branching Is Not EvilSome people believe branching and pull requests are inherently bad. True, branching done poorly can slow down a team, but advocating for avoiding branching altogether can lead you to ignore the more important goal of an agile process: rapid integration of changes. First, make sure you're considering the right metrics. |
|
Creating a Cohesive Culture in a Distributed OrganizationWhen organizations are distributed across multiple locations, it brings questions about how much each location should have a unique identity relative to the larger company. While a theme of “we are one” is common, it’s better to embrace the differences and work toward being a cohesive group that celebrates diversity. |
| |
Agile for Everything: Taking the Manifesto beyond SoftwareThe values of the Agile Manifesto, while written to apply to software, can form a basis for an adaptive approach to any project. Going from specific to general and inspecting and adapting along the way are great design ideas, no matter what you’re working on. Here's how to use feedback to take agile beyond software. |
|
Learn Agile Principles Indirectly through PracticeOne of the primary questions for agile teams adopting a new approach such as Scrum is whether to start with principles or practices. Sometimes the best way to learn principles is indirectly, through practice. Experiences are a great way to learn, and sometimes they even teach you skills without your realizing it. |
|
If You Want Training to Take, Explore Experiential LearningPeople typically think of training classes as passive activities, where the instructor talks and the others listen. But experiential learning, where you learn through hands-on activities and then reflect on the experience, often gets the lesson to stick in people's brains better. Consider using interactive lessons. |
|
The Importance of People in Software: A Tribute to Jerry WeinbergGerald Weinberg's work inspired many to be better engineers and better leaders. Although he’s no longer with us, his message about the role of people in building quality software lives on in his writings and in those who have learned from him. Here, Steve Berczuk recalls some of Jerry Weinberg's most influential books. |
| |
An Agile Framework for Improving Your Hiring ProcessWhen hiring, adopting a framework to help you screen candidates can save a lot of time. However, much like adopting Scrum to improve your software development, following a framework won’t magically guarantee perfect results. But a framework will give you the tools to start off better, and to improve over time. |
|
Defining Velocity for Your Agile TeamWhen an agile team talks about velocity, it's usually how much functionality they'll deliver in a sprint, often based on historical data about the number of story points the team tends to finish. But you shouldn't use velocity as a measure of success for your agile process. Make sure everyone knows what's important. |
|
The Risk of Overemphasizing RisksWe are trained to identify and evaluate risks. This prevents teams from making decisions that are unlikely to work, saving time and money and helping the team move forward. However, a risk-avoidance mindset can also stop progress. Successful agile teams see risks as ways of starting a conversation, not stopping it. |
|
Refining Your Scrum Planning MeetingsScrum events are meant to be productive opportunities for collaboration that replace more tedious, wasteful meetings. If you find your planning meetings becoming passive events where no one is asking questions or actively seeking to understand the backlog, the problem might be in the execution or the preparation. |
|
Why Laughter Is a Sign of Creative, Productive TeamsLaughter is a sign that people feel relaxed and safe. In a workplace, safety leads to environments that enable more idea generation and innovation, so one approach to improving teammates' creativity and connection is to encourage laughter. But how can you do that so it doesn't feel forced? Steve Berczuk has some ideas. |
|
Is Your Agile Team Taking Every Opportunity for Communication?Scrum events are well-defined points where team members communicate, but they shouldn't be the only times. If you’re not considering coding, tests, and the delivery process as opportunities for a conversation, you are missing an important chance to leverage individuals and interactions, as the Agile Manifesto states. |
|
Creating an Environment That Encourages ResilienceCreating environments at work that acknowledge that failures will happen—and supporting the efforts team members make to recover—can help your organization become more effective. You cannot predict every challenge, but by embracing risk and providing opportunities for people to experiment, you can be more productive. |
|
Make Time for Learning with Deliberate PracticeAs software professionals, we need to work continuously to improve our skills. But two common challenges are how to best work to improve, and how to find the time to learn when we’re busy. The answer is deliberate practice—practice with a clear goal and defined measures for success that pushes your usual boundaries. |
|
The 5 Levels of Listening: Which Does Your Team Practice?The ways we listen—and not listen—are detailed in the Five Levels of Listening model, which goes from most distracted to most focused. Ideally, we’d all practice the fifth level: empathic listening, where we try to understand what matters to the person who is speaking, delaying our problem-solving and responsiveness. |
|
Self-Organization: What Your Scrum Team Can Learn from KindergartenersSome kindergartens are experimenting with new approaches to teaching, including letting students form groups to accomplish tasks that interest them, which also allows them to support and engage with each other. This is self-organization, the heart of Scrum. If five-year-olds can do it, your agile team likely can, too! |
|
For Distributed Team Success, Think Differently about WhenFor distributed teams, activities usually get scheduled based on constraints such as availability and time zone, but people don’t often take into account when the most effective time to meet would be. Neglecting people’s work tendencies and schedule preferences could make it harder for the team to be successful. |
| |
The Hidden Benefit of One-on-One Manager MeetingsManagers may frame one-on-one meetings as a way to “support employees” and check to see if the employee “needs to meet this week.” Supporting an employee is a primary goal of these meetings, but the value of one-on-one time to managers—and the importance of building trust with employees—also should be prioritized. |
|
The Manager’s Role on a Self-Organizing Agile TeamScrum and other agile methods focus on team roles and dynamics, and because of the emphasis on self-organizing teams, there’s sometimes a misconception that there’s no need for a manager. In reality, good people management can help an agile team thrive—the manager just has to know how to empower the team. |
|
Balancing Process and ToolsThe limits of a tool may lead us to realize that we are not working as effectively as we can, and often, changing a tool is part of the solution. But there are good and bad ways to select a tool and how you use it. In particular there are risks when you focus first on tools before considering the problem. |
|
An Agile Approach to Change ManagementMany organizations are reluctant to introduce new tools or technologies, or even to update existing ones. The reason is often framed in terms of risk management, but agile teams already have the tools to manage the risk of change: testing and experiments. These approaches together eliminate gaps in risk identification. |
|
Integrating Code in Agile Software Development: Start with the Goal in MindAgile software development works because of continuous feedback at various levels, and the most important form of feedback is working software. One way to achieve rapid feedback is to integrate and deploy code frequently. Rather than starting with the process, first decide what "frequently" should mean for your team. |
|
The Role of Testers on Agile TeamsSome agile teams have so fully embraced the idea of the development team owning quality that they don't hire anyone with a testing background, instead making software engineers responsible for all phases of quality. Still, testers add value to a team in many ways that don’t involve test execution. Where do they fit in? |
|
Fitting Specialists into Your Scrum TeamWhile you may try to create Scrum teams composed entirely of people with T-shaped skills, you might still have gaps in certain specialized areas. Consider forming “specialist teams” to organize experts in the areas that require certain skills. You can have these specialists temporarily become part of your Scrum team. |
|
Technical Debt, Product Value, and Risk Management Reports that the Equifax breach took advantage of a known issue in Apache Struts set the stage for a conversation about technical debt, product value, and risk management. Steve Berczuk shares his thoughts on how to help prioritize technical work in a way that balances short and long term value. |
|
Designing an Office to Nurture Innovative Agile Development TeamsAgile software development is a collaborative activity in many ways, but it also requires quiet time. While open office spaces foster communication and collaboration, it's still important for a workspace to have areas where people can buckle down and work. What is the best office configuration to nurture innovation? |
|
To Improve Agile Teamwork, Think about the IndividualsGiven the emphasis on teams, it can be easy to forget that agile has the value of individuals and interactions as a central principle. As much as an effective team dynamic is what makes Scrum work, teams are composed of individual people, and it’s important to acknowledge each person's role and to express appreciation. |
|
Can Remote Workers Ever Really Make Effective Agile Teams?As the Agile Manifesto states, agile teams should value individuals and interactions, and traditionally, this implies being in the same room. While technology makes collaboration at a distance more viable, some feel that collocation helps with delivering quickly. Can remote workers ever make effective agile teams? |
|
The Value of Testing SimplyPeople obsess over the number of tests and test coverage, but tests that cover more code don’t always improve quality. Some tests have low value and thus, implicitly, high cost. Simple tests may not seem impressive at first glance. But the goal of testing is to ensure quality, and simple tests can be very valuable. |
|
How to Communicate to Build Trust on a Scrum TeamTrust among the ScrumMaster, product owner, and development team is essential to making the process work. Transparency, inspection, and adaptation are the three pillars of Scrum, and you can't commit to these actions if everyone doesn’t have openness and respect for each other. Communication is the best way to do that. |
|
Choose Continuous Integration over Branching for Faster FeedbackContinuous integration is the best way to get feedback often on the state of your project. Running automated builds and tests after each integration improves reliability and predictability. Consequently, using task and feature branches, while useful in some cases, can be a distraction and delay getting information. |
|
In Praise of FailureFailure is measured by expectations. If we aim to be perfect, or set the expectation that only perfection is acceptable, we risk losing opportunities to get valuable feedback. Creating an expectation of perfection can lead to stagnation, not success. Instead, view failure as a learning experience. |
|
The Difference between Managers and LeadersYou often hear managers referred to as leaders, but the two terms are not synonymous. Managers can be leaders, but not always, and there are people who don’t have formal management positions who are leaders. Understanding the difference can help people in both roles—and their team members—be more effective. |
|
Do Software Teams Need Managers with Technical Expertise?Soft skills matter in how effective a manager is, but what about technical skills? If you're a software engineer, how important is it to you for your manager to have the same background and to fully understand your job? Ideally they would, but in some cases, that role can be better filled by a technical lead. |
|
Don’t Abolish Hierarchies—Change ThemHierarchies often get a bad rap, and that’s understandable. Bad hierarchies can increase bureaucracy and get in the way of getting work done. But when done correctly, good hierarchies can streamline processes and provide organizations with some much-needed structure. You just need to rethink how hierarchies can work. |
|
Finding a Home for Specialists on Cross-Functional Agile TeamsIt may seem like the best team would be composed of all specialists, but due to their proficiency in only one area, they can actually hold up an agile workflow. You can keep specialists on your cross-functional teams; you just need to structure their work. Here are four options for making good use of a specialist. |
|
Why Fun at Work MattersHaving fun at work is good for employees' happiness, satisfaction, and even health. But it also increases employee productivity; strengthens coworker relationships, which helps them be more innovative; and makes employees loyal to their organizations. So fun at work benefits employers and companies, too. |
|
Build a Successful Startup by Building a Better TeamWhile people can make a difference in any team, they are particularly important in startups. These small businesses should start with a clear company mission and vision and evaluate how well new members manage conflict and share the values of the team. It could be the difference between success and failure. |
|
Transparency Could Transform Your CompanyTransparency is a core Scrum value because it ensures everyone involved on a project has a common understanding of goals, progress, and deliverables. But what about extending transparency to the whole company, sharing revenue and client-related numbers, strategic product plans, and even individual salaries? |
|
Apply Design Thinking and Agile Principles to Your Life ChangesThe challenges people face when trying to make changes in their lives are similar to those faced by engineers and designers when developing novel products. Using design thinking, you can learn to work within limits, see how the choices you make affect your situation, and iterate until you find your direction. |
|
It’s Time to Evaluate Your Annual Performance ReviewsWhile annual performance reviews can add value when done right, they are often done in a way that does more harm than good. A helpful alternative to an annual review is more frequent feedback that focuses on successes in addition to areas for improvement. Reviews should be motivational and constructive. |
|
Make Your One-on-One Meetings More EffectiveOne-on-one meetings between managers and the people on their teams can be a very powerful tool, but it's also all too easy for these meetings to become routine, simply turning into regular status reports. One-on-ones should address career development, identify obstacles, and look at the big picture. |
|
Overcoming Resistance to Change in Agile TeamsFor agile software developers, acknowledging that change is inevitable is a core principle in how we work. Yet we often resist change—for a variety of reasons. By understanding human nature and being systematic about how we evaluate decisions, we can give ourselves a way of identifying changes that add value. |
|
How Group Norms Enable High-Performing TeamsGroup norms are the traditions, behavioral standards, and unwritten rules that govern how a team works together. They can be implied or openly acknowledged, but establishing a consistent way the team functions helps the individual members focus less on their own preferences and more on what works best. |
|
Collaborative, High-Functioning Teams Start with Agile ManagersWe often assume that management is pure overhead and adds little value. But management is necessary for teams to be successful. Teams sometimes need help creating environments where it’s easier to make the right decisions in a timely manner. A culture of delegation and trust starts with a good manager. |
|
Tips and Tools for Successfully Working RemotelyRemote work is becoming more common, so understanding how to work better remotely is valuable, especially if your company doesn’t have an established policy about it. Collaboration technology continues to improve, making communicating and cooperating with collocated coworkers even easier. |
|
Hiring for Your Best Software Team PossibleSoftware teams spend a lot of time thinking about processes and requirements for development so that we can build great software systems. However, we seem to think much less about how to hire the people for the teams that will build those systems. Consider these points to assemble your best possible team. |
|
Develop Your Listening Skills to Become a Better LeaderListening is key to effective people management and professional mastery, but it may be the most underrated leadership skill. Having a model for what good listening is, and some techniques to practice, can help you become not only a better listener, but also a better leader and learner. |
|
Want to Be More Productive? Work LessAlthough some organizations reward working long hours, that practice is actually counterproductive. After a certain point, more work does not mean more productivity. In fact, due to distractions and fatigue, eventually the more you work, the less productive you become. What's your ideal work-life balance? |
|
Balancing Culture Fit with Diversity: Hiring for SuccessCompany culture is important, but you shouldn't base hiring decisions solely on how well someone seems he'll fit in. This leads to conformity and a fragile organization. To increase diversity, consider people who may not at first appear to be a cultural fit, but who could be valuable additions to your team. |
|
The Secret Life of Team LeadsEngineering an environment that helps teams do their best work can be difficult. When the team works well, it can deliver better, and helping teams deliver more effectively is what being a team lead is all about. However, this role also comes with some responsibilities and challenges that aren't always clear. |
|
The Problem with Job TitlesJob titles are useful for giving a quick idea of a person’s skills and responsibilities. But nowadays in the tech world, a job title alone does not say as much as it used to. Some titles are ambiguous, and some can even encourage a kind of false hierarchy based on how fancy they are. Is there a better way? |
|
Fail Fast: Embrace Failure to Encourage SuccessFear of failure can hold you back from learning and creating new things. Conversely, creating an environment where it’s safe to fail shows that progress toward mastery is just as important as achieving mastery. A leader who encourages failing fast will have a team where everyone is performing at their best. |
|
Practical Strategies for Tackling the Tasks You DreadNot everything we do at work is enjoyable. We can try reframing the more irksome duties in terms of means to an end, but sometimes, even with a mindset adjustment, there are still jobs we dread—and that can make them difficult to finish effectively. Here are some tips for tackling your most tiresome tasks. |
|
The Art of Giving Feedback Your Team Will Act OnGiving good feedback is hard. A common pattern we follow—especially when we have to give negative feedback—is starting with something positive, addressing the problem, and ending with something else positive. But it turns out this "feedback sandwich" method isn't the most effective. Here are some better ways. |
|
To Deliver Value in Your IT Projects, Understand Context FirstStarting a project without understanding can lead to a mess from a usability perspective. Too often, we build what we can without taking the time to question whom we are building it for and why. A user story is a simple but effective tool to determine how much we understand about the context of a problem. |
|
Improve Your Software Organization’s Processes: Focus on the Right ThingWhile processes may seem like overhead, you need defined, documented procedures to avoid problems. It's when processes exist just because "we've always done it that way" that they become a problem. Keep processes useful by asking questions and constantly verifying that the purpose behind them is relevant. |
|
How Innovation Really HappensWe tend to seek out creative ideas that will result in innovation, thinking that will bring about success. But popular theories of how innovation happens are actually wrong; more work is required than some think. There is more to innovation than just great ideas—and there is more to success than innovation. |
|
Learning On: Making Time for New Software Skills Ongoing learning will help you remain relevant as the industry evolves, as well as be more productive at your job—but it can be hard to find the time. Steve Berczuk gives you some tips on how you can fit in education, what you can do to improve your skills, and what pitfalls to be sure to avoid. |
| |
Feedback Challenges in Self-Organizing TeamsSelf-organizing agile teams can present challenges when you want to give individual feedback. Everyone can see the results of what the team accomplished, but the contribution of each person is less apparent. Steve Berczuk has tips for managers and team members on noticing and getting noticed on agile teams. |
|
Making the Most of Your Team’s CreativityWhen people on your team have creative ideas, how do you decide which ones are worth pursuing? Research suggests that neither an idea's creator nor the creator's manager is the best person to predict whether an idea will be a success. Read on to learn what you should do to foster and evaluate creative ideas. |
|
What’s a Tech Lead? Decoding This Developer RoleThe role of technical lead can be hard to define, and in many cases people accept the role without knowing its definition. Because new tech leads are used to programming, many focus too much on the technical aspects and not enough on the people and the team. Read on to learn what's required of this role. |
|
Drawing Motivation for Software Development Teams from Unlikely PlacesWhat do football or a submarine command have to do with agile success? At first, you might say, "Nothing." But football coaches, submarine captains, and their teams all have to establish a clear vision, analyze and prepare, and manage risks and adapt. Metaphors from other fields can motivate agile teams. |
|
Book Review: More Fearless ChangeIt is not always easy to encourage people or organizations to adopt new ideas. More Fearless Change: Strategies for Making Your Ideas Happen can give you the tools to help you spread new ideas. This book has actionable advice you can apply as a change agent, regardless of your role or organization. |
|
Figuring Out What to Measure: Metrics for Agile Teams For agile to work, it's important to evaluate how your team and your project are doing. Qualitative feedback, such as from reviews and retrospectives, can be valuable. But at some point you may need more quantitative information to improve your project. How do you decide what metrics to gather? |
|
Make Sure Measuring Agile Metrics Is Really Leading to ImprovementIn your quest to figure out how your team is doing with its agile process, gathering data can be useful—as long as it does not add significant overhead to your project or get in the way of delivering customer value. Don't let the desire to quantify your improvement get in the way of improving. |
|
Office Space: What Arrangement Is Right for Your Workplace?Regardless of your office has a different configuration—be it a cubicle farm, open space, some configuration of offices, or a mix—it is likely that not everyone will be happy. While it's tempting to just shrug off these discussions, thinking about office layout is important for a number of reasons. |
|
Are You Focusing on the Right Thing in Your Sprint Reviews?The role of demonstration in a sprint review often takes on more importance than it should, even to the extent that some teams refer to the review as a demo. By focusing on the demo you risk having the team do all the talking, rather than a two-way conversation between the team and the stakeholders. |
|
“Post-Heroic” Leaders and Agile TeamsSelf-organizing agile teams still need management, but they need a different kind of management from the autocratic style many teams in nonagile organizations have. A "post-heroic" leader is able to shift from an authoritative manner to a collaborative one as needed to optimize team performance. |
|
Focus on the Most Challenging Parts of Your Project We estimate to make decisions and to give an answer to the question, "When will this be done?" But estimation has limits, and trying to estimate too precisely in an agile project is wasteful. By driving the backlog based on priority, you can better deliver what is valuable to the business. |
|
Meeting the Goal of Estimation The classic discussion for agile estimation is about whether points or hours are better. But there is now a third option: a movement called #NoEstimates. It actually does involve estimation, but you break down work in priority order and estimate only when you know enough to estimate accurately. |
|
Meetings: The Good, the Bad, and the UglyMeetings are a crucial part of the communication process, but they endure a lot of ridicule. You can’t do away with them entirely—meetings are essential to an agile process like Scrum. Rather than avoiding all meetings, it’s better to work at making the times you meet with people more effective. |
|
Managers Are Still Good for Self-Organizing Agile TeamsWhen teams self-organize to deliver software and solve problems, they can be more robust, effective, and directed. But this begs the question: If agile teams self-organize, do they really need managers? Yes, they do. Managers help create conditions that help teams thrive. Read on to find out how. |
|
Book Review: Getting Value out of Agile RetrospectivesRetrospectives are valuable but often neglected agile practices. Some teams struggle to take the time to hold them, and others don't know how. The book Getting Value out of Agile Retrospectives: A Toolbox of Retrospective Exercises can help you keep your retrospectives engaging and useful. |
|
Book Review: Management 3.0It's challenging to be a manager or a leader, much less both, and the challenges are greater on an agile team. Jurgen Appelo's book Management 3.0: Leading Agile Developers, Developing Agile Leaders explores what management and leadership mean in a world of agile and self-organizing teams. |
|
The Tech Industry's Problem with AgeismSteve Berczuk writes that a hallmark of many tech companies, particularly those practicing agile, is being a flat organization with a company culture based on a meritocracy. When hiring, however, this meritocracy is inconsistent with the importance some companies place on a person's age. |
|
Book Review: The Retrospective HandbookSteve Berczuk reviews Patrick Kua's book The Retrospective Handbook: A Guide for Agile Teams. Among the issues Kua addresses are how to lead a retrospective when you are part of the team and how to deal with retrospectives with distributed teams. |
|
Why Both Agile and Math Can Be Difficult to LearnAgile software development can be hard, but many of the challenges may be more about perception than actual constraints. Many teams find an agile environment to be both more productive and more pleasant. This sounds similar to current research studying people's math ability. |
|
Using Points and Hours for EstimatingSteve Berczuk writes that if you decide that there is some value to estimating, you have to decide which unit to measure with points, hours, or something else. Without estimation of any kind, it's difficult to understand how effective you can deliver. |
|
Gossip: The Thin Line between Useful and Destructive CommunicationAgile values—such as communication, feedback, and trust—are essential to making teams work. While all communication is equally valued, the line between useful and destructive communication may be fuzzier than you think. |
|
Create a More Productive Work EnvironmentThere is no one ideal set of criteria for a productive work environment, but there are some common themes that team members and managers can keep in mind. On an agile team, the issues of office space, remote working, and multitasking are great topics to discuss at an iteration retrospective. |
|
Finding the Right People to Manage Your ProgrammersManagers are often the ones responsible for removing impediments, but finding people who are good at managing programmers is difficult. Steve Berczuk explores why quality engineering managers are hard to come by. |
|
How Agile Teams Can Deal with Estimation Agile teams often struggle with estimation. As essential as the concepts of measurement and feedback are to agile software development, the concept of "estimation" seems to stir memories of non-agile projects, and it provokes fears of excessive process. |
|
Learn to Use Your Creativity for Problem SolvingCreativity, the ability to make new things or think of new ideas, is something we value. Steve Berczuk writes that established best practices, such as patterns, can help us solve many problems efficiently, but breakthroughs arise from creative solutions. |
|
The Power of IgnoranceIt’s a challenge to keep up with the software industry given all the available channels of information. Yet, we try hard to be confident and appear knowledgeable. Steve Berczuk writes why this isn’t a good thing and how there is power in being ignorant. |
|
How Work Gets to Be FunSteve Berczuk writes that the idea of having fun at work is a frequently discussed—and important—topic. But happiness at work is not as simple a concept as it may first seem. How work gets to be fun matters. |
|
Good Books for Software Developers to ReadAs a software developer, there is always much to learn, and reading is one good way to learn new things. Here, Steve Berczuk shares some of his favorite books that can benefit your software teams and your career. |
|
Why Being a Good Problem Solver Means You Really Know Your Problem Many people on agile teams are good problem solvers. However, we often attempt to solve problems before we are ready. We forget to take a step back to make sure we fully understand the problem, and doing so can lead to less than optimal solutions. |
|
When to Use Rituals and Regular Routines in Your TeamRituals and routines can help us be more effective and concentrate our effort on the things that matter, but applying rituals without thought can constrain us. Rituals are most useful when they help a team do the right things for the right reasons. |
|
How Office Space Affects Team Member CollaborationSteve Berczuk discusses how the physical structure of an organization can contribute to the way team members interact with each other. Physical office space plays an important organizational role, with much being written about the merits of open-space versus closed-space offices. |
|
Why It's Difficult for Agile Teams to Let Go of Waterfall PracticesFor many projects that have rapidly changing requirements, agile often seems to be the right approach. But teams have a hard time adopting agile practices. It’s far from rare to hear of teams trying to fit practices from their former waterfall method into their new agile process. |
|
Adopting Agile Means Accepting Change: What to Do?Adopting agile means change. And change is hard. But if your current process isn't working as well as you would like, you may need to change. The challenge is to explain the value of agile in a way that helps people open up to new ideas. |
|
Creating an Environment that Supports Self-Organizing TeamsSelf-organizing agile teams leverage some basic qualities about what motivates people to help teams deliver. Since these qualities often run counter to traditional management structures, it takes effort to create an environment that supports these kinds of teams. |
|
Remember: Your Goal Is to Solve Your Customers' ProblemsSteve Berczuk reminds us that while estimation, process, and technical skill are essential to delivering value to a customer in a cost-effective way, they are just means to your primary goal of solving problems. |
|
Why Accepting Failure Is NecessaryThe phrase “failure is not an option” is a common cliche often used to motivate people to succeed. But forbidding failure does not prevent it. A mindset that denies failure might actually detract from long-term success. |
|
What to Do When Your Team Isn't Meeting ExpectationsSteve Berczuk writes that it’s worth thinking about what your assumptions are when you feel like a person or a team isn’t meeting expectations. With the right context, you can focus on solving problems. Without it, the best you can do is try to establish blame. |
|
Do Agile Teams Really Need Managers? Steve Berczuk explores whether or not we really need managers in an agile team. Managers perform a variety of functions that are useful for self-organizing teams. The challenge is how to perform those functions effectively while keeping with the spirit of self-organization. |
|
Why You Need to Take Technical Debt into AccountTechnical debt is a metaphor for the result of skipping design or the implementation steps in order to achieve a short-term goal. The next time you work with code, remember that changes may be more costly to make because of your prior decisions. You achieved something, but you incurred debt. |
|
Book Review: The Art of PossibilitySteve Berczuk reviews The Art of Possibility by Rosamund Stone Zander and Benjamin Zander. The book will help you learn how to focus on what’s possible given a difficult situation, rather than just concentrating on the current problem. |
|
Book Review: To Sell Is HumanSteve Berczuk reviews Daniel Pink’s recent book To Sell Is Human and explains how it's a resource that can benefit agile practitioners. The main message in the book is how everyone, not just those engaged in commerce, are selling all the time. |
|
The Importance of Balance in Your Agile ValuesSteve Berczuk explores the importance of balance and the relationship between agile values and top performing teams. The connection between agile values and balancing the various aspects of our lives should not be too surprising, but balancing all aspects of agile principles is difficult. |
|
The Benefits and Challenges of Agile Development RitualsAgile practices come with rituals and habits that facilitate collaboration and free the team to focus on creative work. However, it can be hard for an agile team to keep up with the rituals. Steve Berczuk writes on the benefits and challenges of following rituals. |
|
What Makes for a Healthy Software Team?Steve Berczuk explains that there is more to maintaining the health of a software team than providing the right technologies and processes. You need to attend to the factors that can transform a group of people into a real team. |
|
Book Review: Lean UX—Lean Principles to Improve User ExperienceSteve Berczuk reviews Lean UX: Applying Lean Principles to Improve User Experience by Jeff Gothelf and Josh Seiden. Through its stories, templates, and guidelines on agile user-experience design, this book will help your team do a better job of building in the best user experience possible. |
|
Teamwork and Creativity: Making Them Work TogetherTo work effectively to meet commitments in a self-organizing, cross-functional team, you need to be creative. The relationship between teamwork and creativity is complicated, and by understanding it you can be more effective as a team. |
|
Acknowledging Work Effort Can Increase Productivity and MotivationSteve Berczuk writes on the importance of acknowledgement in making people feel good about work. Simply acknowledging someone’s effort can lead to increased engagement and motivation—and result in more productivity. |
|
How Agile Teams Use DevOps for DeploymentAgile practices add value by helping teams detect problems early and avoid repeating them; these practices also help teams get feedback early and often. To extend the feedback loop into deployment, teams are taking a DevOps approach by including the needs of operations teams into the process early. |
|
Should Agile Teams Minimize Branching?Steve Berczuk explains that developers are most interested in whether or not an SCM tool is capable of branching, thus allowing more than one related stream of code to evolve in parallel. However, minimizing branching may be the best approach for agile teams. |
|
The Value of Developer Testing in SoftwareDeveloper testing is a great way to improve the quality of your code and deliver more reliably. However, our intuitions about the relative value of testing are often wrong. Only by gaining experience writing tests will you be able to learn which tests really add value. |
|
Why People on Agile Teams Need FeedbackAgile teams work by continually improving, and feedback is essential for agile methods to work well. Giving feedback to your team members and peers is hard, and receiving it is sometimes harder, especially when it’s not delivered with the right amount of thought. |
|
The Value of UncertaintySteve Berczuk writes that while it can be difficult to express uncertainty, especially in an area where we consider ourselves expert, the teams we work with can benefit when we do. A bit of uncertainty can help you identify whether your solution is the best one. |
|
How to Choose the Right Communication Tool for an Agile TeamSteve Berczuk explains how email and other tools of communication can have both advantages and limitations for an agile team. When making an absolute decision on whether to use a tool to collaborate, take time to observe and appreciate what works best for you and the people around you. |
|
Beauty, Art, and SoftwareThinking about connections between beauty, art, literature, and software may not seem as immediately useful as learning a new language or methodology, but doing so can help you be a better developer and designer by exposing you to different ways of thinking—or even improving how you think. |
|
Measuring Development Time: Not the Best Way to Spend Your TimeManagers and project managers are often obsessed with measuring the time it takes to do a task. Time is useful to consider, but measuring time doesn’t always give us the information we really want or need. It's true that work takes time, but it's more valuable to measure results and value delivered. |
|
How to Say "No" When Asked for HelpCollaboration among team members is what makes agile software development both effective and fun. Being part of a team means not only helping others so that the team makes progress but also asking for help when you need it so that you don’t block the team for too long. |
|
Book Review: The Human Side of AgileBeing agile is difficult. Not only are there technical and organizational challenges, but the very nature of the way agile methods work brings the assumptions, context, and fears of team members to the foreground. These people issues are explored in Gil Broza’s book, The Human Side of Agile. |
|
Is Your Job “Work” or Is It "Fun?"The announcement by Yahoo to end working from home has started a conversation about productivity and the work-life balance. There are many issues about time management and productivity that come to mind, but another interesting question related to where we work is whether work is “work” or "fun." |
|
Why Retrospectives Are Important in Agile Software Development Periodically reviewing how things went—and looking for ways to improve—is an essential part of agile software development. Retrospectives are one way to do this, but it’s important to understand that there is a difference between a structured retrospective and “just talking about what happened.” |
|
Why Rituals Are Important for Agile TeamsA ritual—something that is part of all cultures—can foster community in a team and reduce the time and energy we spend making decisions on how we work. The challenge is to keep the rituals that are still useful, not fall into habit, and balance the value of rituals with agile values. |
|
Hiring Agile Developers: Three Often-Neglected Skills They NeedWe are all aware that there is a great demand for agile developers. So, when you are hiring for your agile team, what qualities do you look for in a candidate? Steve Berczuk explains the often-neglected skills that can help one be an effective agile software developer. |
|
Estimation on an Agile Software ProjectEstimation is hard work, and people aren’t naturally good at estimation. But without an estimate, it’s hard to know how far off you’re likely to be. Estimates in the context of an agile project can help you better set expectations and improve stakeholder’s confidence in when you can deliver. |
|
Why Managers Can Be Valuable to Self-Organizing Agile TeamsAs challenging as it is to find a good manager, having one on your team can be valuable, especially in the context of an already effective team. So rather than assuming that self-organizing agile teams don’t need managers, consider the value a good manager can add. |
|
What Is the Role of Management in Agile?Agile methods rarely describe roles that match those of a traditional manager. While some organizations consider managers to be “overhead,” others argue that their supervisors have value and help make people work more effectively. Steve Berczuk takes a look at the role of a manager in agile. |
|
How Being Active at Work Leads to Better CollaborationSteve Berczuk shares his insight on how novel approaches to being active at work can lead to better collaboration. If being active can improve collaboration, why not be active? After all, studies have shown that a healthy team is a productive one. |
|
Why Software Development Doesn't Need to Be PerfectIt’s a cliché that the perfect is the enemy of good. It’s also a driving principle of agile software development. Delivering software, or even ideas, that are good enough to work with but not “perfect” can encourage collaboration and creativity—and lead to a better solution. |
|
Developing Self-Organizing Agile TeamsAgile teams are supposed to be self-organizing, but self-organization may not happen on its own. It runs counter to the ways in which people usually work. Steve Berczuk examines the benefits and challenges of self-organizing teams—and some tips on making them work. |
|
Why You Should Acknowledge UncertaintySoftware developers spend much of their time solving problems, which seems contrary to some common workspace habits. While they can’t always know everything, they are often uncomfortable acknowledging uncertainty. This isn’t necessarily the best thing to do—for your customer or yourself. |
|
The Growth of Agile in GovernmentSteve Berczuk analyzes a US Government Accountability Office (GAO) report, released in July 2012, on agile software development in government projects, and finds that the report's recommendations could apply equally well to a small technology company adopting agile. |
|
Improving Your Measurements to Influence BehaviorMeasuring things is easy, but measuring the right things and acting appropriately based on what you have measured is hard. What you do with measurements can influence behavior, so it’s worth putting some thought into what you measure. |
|
How Software Leans toward Agility and ExperimentationAgility depends on learning and experimentation. You make decisions, execute, and then re-evaluate. Steve Berczuk explores why software development is a natural medium for experimentation and agility, because, in a physical sense, software is relatively easy to manipulate. |
|
How to Solve a Problem That's Not Well DefinedWhen presented with a problem, professionals are often tempted to propose solutions without validating the problem statement. This can be the right thing to do when the problem is well defined. Unfortunately, outside of academic exercises, such well-defined problems are rare. |
|
The Importance of People in Agile Software Development When software professionals talk about agile methods, they often overlook the most important topic—the role of people in agile software development. If you ignore team dynamics, you risk hindering your team's effectiveness. |
|
Using Agile to Avoid Excessive MultitaskingBy keeping priorities clear and avoiding excessive multitasking, you can provide teams the space to work with attention to quality and adaptability. Agile processes give teams more control over their time, and this control can lead to the teams' being happier and more productive. |
|
Counterintuitive Tips for Agile Collaboration While true for all teams, agile software development is especially reliant on teams and collaboration. What makes a team function well can be counterintuitive. |
|
How Automation Benefits Agile Technical PracticesAutomation is an important aspect of agile technical practices. Automated builds, testing, and deployment enable developers to implement features and refactor to improve code quality with confidence. So, is there any reason to be skeptical about the benefits of automation? |
|
Solutions to Old and Bad SoftwareA recent article in the Atlantic describes the software behind many systems we rely on, and not all of the software is as robust and well written as we might hope. While agile values and techniques may not be the whole solution, they can help you improve the quality of your software. |
|
Agile Codelines and Shared Traffic SpaceHow an agile team works with their codeline is analogous to a shared space traffic model, in which most traffic signals and markings are removed; drivers, cyclists, and pedestrians are guided by a small set of rules. |