Measure Progress
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. …
Continue reading “Measure Progress”
Read MoreEmpower People
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 …
Continue reading “Empower People”
Read MoreListen to Everyone
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, …
Continue reading “Listen to Everyone”
Read MoreAddress Root Causes
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 …
Continue reading “Address Root Causes”
Read MorePractice the Five Whys
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 …
Continue reading “Practice the Five Whys”
Read MoreBlame Process, not People
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 …
Continue reading “Blame Process, not People”
Read MoreLook for Small Improvements
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. …
Continue reading “Look for Small Improvements”
Read MoreValidate Often
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 …
Continue reading “Validate Often”
Read MoreBuild the Smallest Piece that Shows Value
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 …
Continue reading “Build the Smallest Piece that Shows Value”
Read MoreWork Through Unknowns
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 …
Continue reading “Work Through Unknowns”
Read MoreIdentify Areas of Risk
A big part of managing a software development project is monitoring and managing the risks involved. Software development is a risky activity. Remember that throughout our tumultuous history in software development, according to the Standish Group, one-third of all software projects get canceled and never see the light of day. This was true in the …
Continue reading “Identify Areas of Risk”
Read More