In Part 1, I discussed the agile project system. In Part 2, I discussed the tester’s job in agile. In Part 3, I discussed expectations about documentation (which is what the original question was on Twitter). In this part, I’ll talk about how you “measure” testers. I see a ton of strange measurement when it […]
In Part 1, I discussed how an agile approach changes testing. In Part 2, I discussed how the testers’ job changes. In this part, I’ll talk about expectations. Since the developers and testers partner in agile, the testers describe their approach to testing as they work with developers on the code. (This is the same
Last week, I attempted to have a Twitter conversation about agile and testing. I became frustrated because I need more than 140 characters to explain. This is my general agile picture. For those of you can’t see what I’m thinking, the idea is that a responsible person (often called a Product Owner) gathers the requirements
In Part 1, I discussed the project system of agile. In this part, I’ll discuss the need for testing documentation. In a waterfall or phase-gate life cycle, we needed documentation because we might have had test developers and test executors. In addition, we might have had a long time separating the planning from the testing.
I spoke with a potential client last week. She said, “I’m waving the agile flag. But no one cares.” I wrote a Pragmatic Manager to sort through what I wanted to say to her. Read it at Feeling Alone on Your Agile Journey. If you feel stuck in the middle, or you’re alone, or you
A number of my clients are attempting to use agile as they transition from a strict waterfall to a more adaptive approach to their projects. One problem the change artists have is this: The managers, product managers, and maybe even the customers want to define all the requirements up front. I have not found the
Here’s something I see in many organizations: Management wants to “control and manage” the projects/efforts/work (whatever they call it) in the same way they did before the organization started agile. They want Gantt charts. They want commitments. They want assurances that the work will proceed in the same way they thought of it before the
In Stuck in the Middle, Part 1, I discussed possible management problems with agile. Those aren’t the only stuck problems I see. Sometimes, I see team problems. What if the teams are “almost agile”—they still have too many experts, their stories are too big, they don’t always deliver value on a regular basis? You know
In part 1, I addressed some management challenges with an agile transition. In part 2, I addressed some team issues. In this part, I’ll discuss why agile is a culture change and ways to consider a system change to agile. Agile looks something like this image. The responsible person (often called a product owner)
I met a team recently who was concerned about their velocity. They were always “too late” according to their manager. I asked them what they measured and how. They measured the burndown for each iteration. They calculated the number of points they could claim for each story. Why? Because they didn’t always finish the stories they