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
Feeling Alone on Your Agile Journey? Do you feel as if you are waving the agile flag and no one cares? You know what you, your team, and your management needs to do. No one seems to be able to put your suggestions into practice. Worse, sometimes, it looks as if no one cares, except
I’ve lost count of the number of companies that don’t pay for training—or even provide tuition reimbursement. I also see too many organizations decide whom to hire based on technical skills. They don’t see the irony here. That means you’re responsible for your ongoing career development. And here’s the kicker: The more you learn and
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