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 MoreInvest in Automated Tests
I’ve built my career on writing software to automate other industries. I’ve learned a lot about a range of disciplines and businesses, how they operate, and very often their “secret sauce” can be embodied in the software that they write to run their businesses. I believe that the quality of our build and the quality …
Continue reading “Invest in Automated Tests”
Read MoreAvoid Branching
I’m going to go out on a limb here (pun intended) and say that the purpose and benefit of continuous integration have to do with integrating our code continuously. That makes sense but I see so many teams use their CI systems to isolate their code in branches and prevent the code from being integrated …
Continue reading “Avoid Branching”
Read MoreIntegrate Continuously
This is the first post in a new series of posts called Seven Strategies for Burning Down Risk based on the section with the same name in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. Of all the agile technical practices the first and most important one …
Continue reading “Integrate Continuously”
Read MoreKeep Stories Testable
I want to conclude this collection of seven blog posts on strategies for story splitting with one of the most important aspects that a story should include, which is the ability to be tested. Just like testable code, testable stories are essential. When we make stories testable, we find that many of their other qualities …
Continue reading “Keep Stories Testable”
Read MoreKeep Intentions Singular
Throughout this series of blog posts on story splitting, I’ve stressed the need to make our stories as small as possible. The way to do this is to keep a story focused on a single outcome for a single type of user with a single purpose. Keeping the intentions of a story singular helps us …
Continue reading “Keep Intentions Singular”
Read MoreMinimize Dependencies
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set …
Continue reading “Minimize Dependencies”
Read MoreSplit Stories on Acceptance Criteria
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set …
Continue reading “Split Stories on Acceptance Criteria”
Read MoreIterate on Unknowns Until They are Understood
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set …
Continue reading “Iterate on Unknowns Until They are Understood”
Read MoreBreak Complex Stories Down into Knowns and Unknowns
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set …
Continue reading “Break Complex Stories Down into Knowns and Unknowns”
Read MoreBreak Compound Stories Down into Components
In 2020, I finished a series of 72 blog posts that expanded on the first set of “Seven Strategies…” for each practice in my book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. I included two sets of “Seven Strategies…” in my book and so I am expanding on the second set …
Continue reading “Break Compound Stories Down into Components”
Read MoreUse Acceptance Criteria for Stories
I’m wrapping up this series of blog posts based upon Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, with my last strategy–use acceptance criteria. There are many ways to define or break down and split up user stories. Generally speaking, …
Continue reading “Use Acceptance Criteria for Stories”
Read More