David Scott Bernstein's Blog

Many teams seem to set lofty goals for improvement only to fall short of achieving them. The problem is often not with the goals but the lack of measurement and accountability. Without a way to measure progress, goals remain just an idea in the conceptual realm, and teams are less likely to strive for them.

Measuring progress is crucial for any successful project, whether developing software, improving a process, or achieving a personal goal. It gives people a tangible way to see how far they’ve come and how much they still have to achieve. Here are some tips for measuring progress in Agile Software Development:

The first step in measuring progress is to set measurable goals. Make sure your goals are specific, achievable, and measurable. Use metrics that matter to your team, such as cycle time, defect rate, or customer satisfaction. This will help you track progress and adjust your approach as needed.

Once you have your goals, define the metrics to measure progress. These metrics should be easily measurable and should provide insight into how well you’re doing. Use tools like dashboards or burndown charts to track progress and make it visible to the team. But don’t overdo it. The biggest cause of failing to measure progress, in my experience, is trying to measure too many things. Pick just two or three key metrics to measure and consistently measure them. For a list of metrics I suggest you measure, see my blog post, Seven Strategies for Measuring Value in Software.

Make your metrics visible to the team so everyone knows how they progress. Display metrics on a dashboard or wallboard so everyone can see how the team is doing at a glance. This will encourage accountability and motivate team members to work together toward a common goal.

Regularly review progress against your goals and metrics. Schedule regular checkpoints to review progress, celebrate successes, and identify areas for improvement. Use these reviews to adjust your approach and identify opportunities for further improvement.

Use feedback to improve your progress measurement approach. Ask team members for feedback on how well the metrics work, and make changes as needed. Solicit feedback from customers or stakeholders to ensure that your metrics align with their needs.

Measuring progress is critical for achieving goals in Agile Software Development. It gives people a tangible way to see how far they’ve come and how much they still have to achieve. It creates a sense of accountability and motivates team members to work together towards a common goal. And it provides the information needed to adjust your approach and make improvements.

In summary, set measurable goals, define metrics, make them visible, regularly review progress, and use feedback to improve. We can turn our goals into reality and achieve success by measuring our progress.

This concludes my post series Seven Strategies for Effective Retrospectives, an expansion on the section of the same name from my book Beyond Legacy Code (https://BeyondLegacyCode.com).

The post Measure Progress appeared first on To Be Agile.

I’ve seen my fair share of successes and failures in Agile implementations. From my experience, the most common reason for failure is the lack of empowerment for people. Many organizations implement Agile without truly empowering their people, leading to a culture of fear, resistance, and lack of ownership.

Empowerment is not just a buzzword. It’s a mindset that drives change, fosters creativity, and encourages continuous improvement. It’s about giving people the tools, resources, and support they need to make informed decisions and drive positive change.

So, how can we empower people in Agile Software Development? Here are some tips that I’ve found to be helpful:
First, create a safe space for people to work. Fear is the enemy of empowerment. To empower people, you must create a safe space where they feel comfortable taking risks, sharing their ideas, and making mistakes. Encourage open communication, active listening, and respect for diversity.

Empowerment requires resources, whether it’s time, money, or training. Ensure your team has access to the resources they need to succeed. Just saying “self-organize” is often not enough to make teams efficient. Invest in training and development, provide the necessary tools and technologies, and give team members the autonomy to use those resources.

Ownership is a crucial driver of empowerment. Encourage your team to take ownership of their work, goals, and achievements. Ensure they understand the big picture and the impact of their work on the organization’s success. Celebrate their successes, and help them learn from their failures.

Empowerment requires change, and change can be scary. Support your team in making changes, whether it’s a new process, tool, or approach. Be open to feedback and encourage experimentation and continuous improvement.

Lead by example. Empowerment starts at the top. As a leader, you can lead by example. Demonstrate a growth mindset, take ownership of your mistakes, and support your team’s initiatives. Be transparent, communicate openly, and show that you value feedback.

Empowering people is not easy but essential for Agile Software Development success. It requires a shift in mindset, a commitment to change, and a willingness to support your team. But the benefits are worth it. Empowered teams are more engaged, productive, and innovative. They take ownership of their work, embrace change, and drive continuous improvement.

So, let’s empower the people we work with. Let’s give them the tools, resources, and support they need to be successful. This will help create a culture of empowerment that drives positive change and fosters innovation. And let’s have fun while we’re at it! After all, empowerment with a side of humor is one of the secret ingredients to successful software development.

The post Empower People appeared first on To Be Agile.

Retrospectives are an essential part of Agile Software Development. They allow teams to reflect on their performance, identify areas for improvement, and make changes that will help them work better together. However, a retrospective is only as good as the input it receives. Listening to everyone on the team, not just the most vocal members, is essential.

As an Agile Software Development Coach, I’ve seen many retrospectives where only a few team members dominate the conversation, and the rest of the team stays quiet. This can be a problem because the team may miss valuable insights that could help them improve. To avoid this, here are some tips for listening to everyone during a retrospective:

Start by setting the stage for the retrospective. Explain why it’s important to hear from everyone on the team and encourage everyone to participate. Remind the team that the retrospective is a safe space where they can share their thoughts and ideas without fear of judgment.

Use facilitation techniques to encourage participation from everyone on the team. For example, use round-robin brainstorming to ensure that everyone has a chance to speak. Use sticky notes to capture everyone’s ideas so they don’t get lost in the conversation.

Be inclusive of everyone’s opinions, even if you disagree with them. Ask clarifying questions to understand their perspective better. Use active listening techniques to demonstrate that you value their input.

Take actionable objectives from the retrospective. Ensure that everyone on the team has a role in making small improvements to help the team work better together. Ensure these objectives are achievable and everyone understands what they must do to make them happen.

Follow up on the actionable objectives after the retrospective. Schedule regular checkpoints to review progress, celebrate successes, and identify areas for improvement. Use these checkpoints to adjust your approach and identify opportunities for further improvement.

Listening to everyone during a retrospective is critical for success in Agile Software Development. It ensures that the team captures valuable insights, identifies areas for improvement, and makes changes that will help them work better together. It also demonstrates that constant improvement is everyone’s responsibility, and everyone has a role in making small improvements.

So, set the stage, use facilitation techniques, be inclusive, take actionable objectives, and follow up. Listening to everyone can make your retrospectives more successful and help your teams achieve their goals.

The post Listen to Everyone appeared first on To Be Agile.

When problems arise in agile software development, getting to the root cause is essential. Once the real issue is understood, it’s important to address it directly. Addressing the root cause is often easier than addressing the symptoms and can prevent the problem from reappearing in a different form.

To address the root cause of a problem, it’s essential to understand the contributing factors. This may involve digging deeper into the issue using techniques like the five whys, where we ask why five times to uncover hidden causes of a problem. Once the root cause has been identified, the team can work together to find a solution to prevent the issue from recurring.

For example, let’s say that the root cause of a problem is that the team lacks the necessary skills to complete a project on time. In this case, the team could look at ways to improve their skills through training or mentoring. By addressing the root cause, the team can prevent similar issues.

It’s important to note that addressing the root cause may not always be easy. It may require significant changes to the team’s processes or way of working. But by addressing the root cause directly, the team can make more lasting improvements and prevent similar issues from recurring.

To address root causes effectively, it’s crucial to have a culture of continuous improvement. This means encouraging team members to share their thoughts and ideas and being open to making changes to improve the team’s processes. By working together to address root causes, the team can become more effective and efficient.

In summary, addressing root causes is key to having effective retrospectives in agile software development. By understanding the contributing factors and working together to find a solution, the team can prevent similar issues from recurring. This requires a culture of continuous improvement, where team members feel comfortable sharing their thoughts and ideas and making changes to improve processes over time. And over time, these improvements pay off.

The post Address Root Causes appeared first on To Be Agile.

When something goes wrong in agile software development, getting to the root of the problem is essential. But the presenting problem is often just a symptom of a deeper issue. One technique to uncover the actual cause is to practice the “five whys.”

The five whys technique is simple but effective. When faced with a problem, ask why it happened or what caused it. Then, with that answer, ask why again, and so on, until you’ve asked “why” at least five times. By the fourth or fifth “why,” you’ll often discover some interesting problems you may not have been aware of.

For example, let’s say that the presenting problem is that the team missed a deadline for a project. The first “why” might be that they underestimated the work involved. The second “why” might be that they didn’t properly scope the project. The third “why” might be that they didn’t communicate effectively with stakeholders. And so on.

By digging deeper into the problem, the team can identify the root cause and make changes to prevent similar issues in the future. The five whys technique can also identify areas for improvement that may not be immediately obvious.
When I practice the “five whys,” I often discover the underlying issues that allowed the problem to exist in the first place. Knowing this solves the problem at hand but also addresses a whole class of problems I can eliminate in the future.

Creating a safe and open environment where team members feel comfortable sharing their thoughts and ideas is essential to make the most of this technique. Encourage everyone to ask “why” and share their perspectives. By working together to get to the root of the problem, the team can make more informed decisions and improve their processes over time.

In summary, the “five whys” technique is a simple but effective way to get to the root of a problem in agile software development. By asking “why” multiple times, the team can uncover more profound issues that may be contributing to the problem. Creating a safe and open environment where team members feel comfortable sharing their thoughts and ideas is crucial to make the most of this technique. With practice, the team can learn to use the five whys to improve their processes and work better.

The post Practice the Five Whys first appeared on To Be Agile.

The post Practice the Five Whys appeared first on To Be Agile.

When things go wrong, it’s natural to want to assign blame. But in agile software development, assigning blame doesn’t get us very far. And it can often make things worse. That’s why adopting a different mindset during retrospectives is crucial — one that focuses on the process, not the people.

Let’s face it – it’s usually not intentional when communication breaks down. People don’t set out to create problems or make mistakes. Instead, issues typically arise as a result of flaws in the process. By blaming individuals, we’re missing the root cause of the problem and making it more difficult to find a solution.

Instead of focusing on who made a mistake, we want to focus on what went wrong in the process that allowed the error to happen in the first place. This shift in perspective can significantly affect how we approach problem-solving.

When we focus on the process, we take the pressure off people. The team can focus on finding ways to prevent similar issues from happening again. By examining the process, we can identify the flaws that contributed to the problem and work together to improve it. This helps us avoid future problems and creates a more positive and collaborative environment.

To adopt this mindset, creating a safe and open environment where team members feel comfortable sharing their thoughts and ideas is crucial. This means avoiding blame and instead focusing on solutions. It also means encouraging everyone to share their perspectives and work together to find the best solutions.

Psychological safety is one of the essential factors in high-performing teams. Psychological safety doesn’t just mean that people feel safe sharing their ideas. It also means that the team is aligned with shared goals and practices. It means everyone on the team has a voice and feels heard, so they are encouraged to contribute.

We can create a more effective retrospective process by shifting our focus from blame to process. We can learn from our mistakes and make improvements that help us work better as a team. So, the next time something goes wrong, resist the urge to blame – instead, focus on the process and work together to find a better way forward.

The post Blame Process, not People appeared first on To Be Agile.

Seven Strategies for Effective Retrospectives
It’s important to reflect with the team and gain insights on what can be improved. Regular retrospectives are an excellent way to get the team in the habit of looking at what they did and how they can improve. The following seven blog posts contain seven strategies for effective retrospectives. Enjoy!

Look for Small Improvements
As a coach in agile software development, I’ve noticed that organizations can sometimes struggle with change. It’s common for them to either resist change altogether or try to implement too many changes at once. However, I’ve found that making minor improvements is the best way to achieve organizational change.

You might be wondering why minor improvements are so practical. The answer is that it’s all about taking baby steps. Making small changes can make it easier for everyone to adopt them, and they can add up over time to create a significant impact. Imagine if you aimed for just a 2% improvement every few weeks – by the end of the year, you’d have a whopping 50% improvement! That’s pretty impressive.

One of the great things about minor improvements is that they’re often less risky than major changes. When you make a huge change, there’s a lot at stake. But when you focus on minor improvements, you can test them and see how they work before making further changes. Plus, small changes are usually more manageable and easier to implement, which makes them more likely to stick.

So, how do you make small improvements? First, you’ll need to identify the areas where your team could use help. This might include improving communication, reducing waste, or streamlining processes. Once you know what needs improving, you can start brainstorming small changes that could be made to address those issues.

It’s essential to involve your team in making minor improvements. When everyone is involved, they’ll be more invested in the changes being made and more likely to adopt them. So, encourage your team to share their ideas for minor improvements and listen to their feedback. By doing this, you can ensure that everyone is on board with the changes and increase the chances of success.

Overall, minor improvements are a powerful tool for achieving organizational change. Taking a measured and incremental approach can make significant progress over time. So, start by identifying the areas that need improvement, involve your team, and aim for those 2% improvements – your team will thank you!

The post Look for Small Improvements appeared first on To Be Agile.

Wrapping up this series of seven blog posts on burning down risk, I want to talk about validation.

Validating our ideas, assumptions, and features is critical to tell us if we are on track. We want to get software in the hands of our users as quickly as possible so that they can tell us what works for them and what doesn’t. If a picture is worth a thousand words, then even a mockup of the feature is worth a million words.

When we put our minds to use a feature, we can get a good sense of how to design it well, and that’s our goal. It’s often a refinement process we don’t get right the first time. It’s through the interaction with our users that they discover and we discover the best ways to use the software.

I call this using development as a discovery process, and it’s where the actual value of software development comes in. It’s not the code but rather our understanding that we gain on how to do things better that is the real value developers provide. The code embodies that understanding so that others can benefit from it. The understanding is the real value to me of developing software. Software embodies our understanding.

In Agile and Scrum, we talk a lot about validation and feedback. We get feedback on many levels. We get feedback from our users, who tell us what they want and verify that our build addresses their needs. We get process feedback that tells us how to improve our process. This includes retrospectives and feedback from the team.

There’s also the feedback that we get from our build and our tests that tell us if we are introducing defects into the system so that we can recover quickly. For developers, feedback from the build server running continuous integration is one of the most valuable forms of feedback. When I am writing code, I run my build frequently. Whenever I have a bit of functionality, I check it in and get feedback from my build to validate it, and the rest of my system runs as expected.

Agile is all about feedback, and software development efficiency has a lot to do with the length of our feedback loops. We want to get feedback as soon as possible, and that means building the smallest piece that shows value.

The post Validate Often appeared first on To Be Agile.

This is going to be a short post.

In agile software development, small is a big thing! When we talk about small in agile, we are talking about really small. The smaller, the better. When we break down big tasks into small ones, much of the difficulty around implementing them goes away. Small tasks give us more opportunities for feedback and to check in when we solve smaller problems and generally are more straightforward to work with.

Generally, we think about a feature in terms of the story. A story contains who it’s for, what they want, and why they want it. A story is a placeholder for a feature. Features may be too large to work on within one iteration or sprint, so we break features into tasks.

The syntax for describing stories is “As a , I want to , so that ,” and the typical way of describing a task, which is a component of a story, is using the “Given, When, Then” syntax. This says that given a set of preconditions, when a trigger occurs, then some post conditions will occur, which we can validate.

I like this syntax for tasks because it maps very nicely into a unit test. Unit tests have a setup corresponding to the preconditions and assertion, which typically invokes the trigger and verifies the post conditions.

I like to build the smallest product increment that still adds value to a user. Only about 20% of a feature can be valuable, and the rest may be of much lesser value, so I like to build that 20% first. My customers often don’t even want the other 80% and are willing to move on to the next feature.

How small should we build? Build the smallest thing that still provides some value. Make that value your acceptance criteria and write your test around that. That’s my best advice.

The post Build the Smallest Piece that Shows Value appeared first on To Be Agile.

Of course, it always turns out that the biggest risks are the ones we are unaware of. “What you don’t know can’t hurt you” is a myth. It’s the things that we don’t know about that can hurt us the worst. This is why we strive to reduce unknowns and dependencies. There are typically a lot of unknowns on a software project, and we have to get comfortable with uncertainty.

I have developed some techniques for managing risks. First of all, I like to make things visible. I list my dependencies and the major things that could go wrong to keep an eye on them throughout the project and ensure I stay on track. I look for ways of encapsulating issues in code so I can defer on them and deal with them later without paying a huge price. If I can hide a service behind a well-defined interface, I don’t have to implement that service immediately. It’s taken me a lifetime to figure out the important things to keep track of on software projects.

One thing I’ve learned from my experience is that it’s easier to figure out a problem when I’m in the midst of it rather than trying to figure it out from afar. What I mean by ‘from afar’ is when we are planning or thinking about doing some work rather than when we are doing the work. I find that while I’m coding, I can do my best designs. I think that doing an upfront design is fallacious most of the time. It’s more difficult and less accurate to imagine doing the work than doing it.

Because of this, I find it’s more effective to figure many things out as I go, which means I go into iteration with unknowns. Many times these unknowns work themselves out, so they don’t ever become issues, but there are times when they don’t, and I’m forced to deal with them. Perhaps there is a service that I need, but I’m not sure if there is a framework that will do it for me, or perhaps I have an unknown implementation detail that I have to work out.

I take all that into iteration with me, and when I bump up against those unknowns and can’t go any further, I create a little mini time-box. I say that for the next hour or day or whatever, I will research the following things, and at the end of the time box, I see how I did. I asked myself if I had resolved my issues and answered my questions. Do I have new questions? Can I move forward, or do I have to create another mini time-box to answer new questions?

I find that it is more efficient to take these issues into iteration with me than to figure them out upfront because I don’t know which issues are important and which are unimportant. So I end up with a longer list of issues I must resolve.

Often, the issues that I have are a result of missing information. Either I don’t understand how a feature is supposed to work, or I have unresolved implementation issues that must be dealt with. When I first identify what I need to know, I can clearly define a strategy for finding it out. From there, I iterate.

Emergent design is about letting a design emerge by paying attention to what tests need from code and what code needs from tests. It’s an advanced technique, but it can be magic when it works well. When doing emergent design, we start simple and iteratively build features. The end result for me is often much better than what I had imagined, so it is my preferred way of building software.

The post Work Through Unknowns appeared first on To Be Agile.