I have never found Gantt charts to be useful. When I say that to my clients, some of them tell me they do find use in Gantt charts. Specifically, the people who like Gantt charts say they can predict where the project is headed. In addition, they can see the various interdependencies across the work. […]
Make Better Decisions When You Have Too Much Ambiguity As a leader in the organization, you have a Big Decision to make. You need more data. However, getting the data is impossible in the timeframe you need to decide. The data you want might not even exist. What do you do? You could pray. I’m
What Happened to the Beautiful Plans? (They Became Experiments) Tim, a senior manager, loved seeing plans for work and roadmaps. Then, the organization decided to Embrace, Not Manage Change. Tim wasn’t sure how to track the work. This image helps me frame the need for an agile approach. (See the blog series: Where I Think “Agile” is
It seems as if the larger the agile program, the bigger the planning. Many organizations try to plan for an entire quarter at a time. They bring everyone on the program together in a large room (often a hotel ballroom) and attempt to plan the next quarter’s work. That kind of planning works for some
I don’t know if you retrospect on a regular basis. I do. (I know, you are so surprised!) Andy Kaufman asked me to share my biggest learning for his podcast. Take a listen to The Most Important Lesson You Learned Last Year. I’m pleased and proud to be in such good company. Thanks, Andy!
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.
If you’ve read Reasons for Continuous Planning, you might be wondering, “How can we do this?” Here are some ideas. You have a couple of preconditions: The teams get to done on features often. I like small stories that the team can finish in a day or so. The teams continuously integrate their features. Frequent features