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)
For many people, agile means an end to all project management. I disagree. I find value in servant leadership in project management. I explain how you can think about servant leadership and agile project management in my projectmanagement.com column this month: Servant Leadership: The Agile Way. If you are looking to increase your servant leadership
Over on Techwell, my monthly column is Agile Does Not Equal Scrum: Know the Difference. I wrote the article because I am tired of people saying “Agile/Scrum” as if Scrum was the only way to do agile. I use iterations, kanban, and the XP technical practices when I work with teams. I am not religious about