If you’ve been watching my writing (and speaking), you’ve noticed that I like both agile and lean. I like the cadence of milestones and demos that iteration-based agile provides. I like the limiting of work in progress and seeing the whole that lean provides. For me, both are necessary to deliver value. You might have […]
I was at an experience report at Agile 2016 last week, Scaling Without Frameworks-Ultimate Experience Report. One of the authors, Daniel Vacanti said this: Flow focuses on unblocking work. Iterations (too often) focus on the person doing the work. At the time, I did not know Daniel’s twitter handle. I now do. Sorry for not
Marcus Blankenship and I wrote a follow-up piece to our first article, mentioned in Discovery Projects Work for Agile Contracts. That article was about when your client wants the benefit of agile, but wants you to estimate everything in advance and commit to a fixed price/fixed scope (and possibly fixed date) project. Fixing all of
People often ask me, “When is agile right or not right for a project?” I’ve said before that if the team wants to go agile, that’s great. If the team doesn’t, don’t use agile. That answer is insufficient. In addition to the team, we need management to not create a bad environment for agile. You
Marcus Blankenship and I wrote an article, Stay Agile with Discovery, to discuss how to help your clients see the benefits of working in an agile or more agile way. We have seen too many clients want “agile” and not want all the responsibilities that being a Product Owner or customer involves. If your client asks
In a recent workshop, a participant asked me, “What does agile mean? How do you know if you are agile?” He wants to use kanban to see the flow of work through his group. Someone told him he needed to use iterations to be agile. (I had a little rant about this in What Does Agile Mean
Lisette Sutherland posted a podcast we recorded about geographically distributed agile teams. See Organize Your Distributed Team over on the CollaborationSuperpowers site. We covered how you can think about your geographically distributed agile team: Why you want a distributed agile team (yes, there are some great reasons) How you might organize your team. Here are
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