I’ve been coaching several teams with a problem: they like to work in iterations. And, they have milestones that are not on a milestone boundary. What should they do? (I suggested flow and you should have heard their response. Well, maybe not.) Here’s why people want these milestones: The team can’t deliver (for whatever reason) as continuous […]
Note to my dear readers: As I write, I realize this series is growing. Thank you for your understanding in advance. In Defining “Scaling” Agile, Part 4: Sharing Agile Outside of Product Development, I wrote about an independent workgroup with one stream of work. I used Customer Support as an example. Support has one stream:
Here’s where we are so far in this discussion of what it might mean to “scale” agile approaches: Part 1: Creating Cross-Functional Feature Teams (Teams that can produce features on a regular basis) Part 2: Programs of Cross-Functional Feature Teams (Programs (multiple teams working together) that deliver features on a regular basis) Part 3: Agile Product
In the “Scaling” Agile: Part 1, I wrote about cross-functional collaborative teams. The cross-functional collaborative feature team is the basis for “scaling” agile. In “Scaling” Agile, Part 2, I wrote about programs. I realized I need another part before my original part 3 :-). This new part 3 is about creating agile product development capabilities.
I offer three online workshops for your writing and product ownership pleasure. All three are open for registration. Practical Product Owner: Deliver What Your Customers Value and Need Workshop (Q2 session starts May 8, 2017) Writing Non-Fiction Workshop 1: Enhance Your Business and Reputation (The Q2 session starts May 17, 2017) Writing Non-Fiction Workshop 2: Secrets of
A couple of weeks ago, I spoke locally about Manage Your Project Portfolio. Part of the talk is about understanding when you need project portfolio management and flowing work through teams. One of the (very sharp) fellows in the audience asked this question: As you grow, don’t you need component teams? I thought that was
Many agile teams attempt to plan for an entire quarter at a time. Sometimes, that works quite well. You have deliverables, and everyone understands the order in which you need to deliver them. You use agile because you can receive feedback about the work as you proceed. You might make small adjustments, and you manage
Knowledge, Risks, and Guarantees One senior manager in an organization trying to use agile told me about his problems, “We still need to know when the project will be done. We can’t afford the risk of missing the deadline. When we spent all that time on requirements, the team knew what they were doing. We
Agile is iterative and incremental development and frequent delivery with cultural change for transparency. What do the words iterative and incremental mean? Iterative means we take a one-piece-at-a-time for creating an entire feature. Iterative approaches manage the technical risk. We learn about the risk as we iterate through the entire feature set. Incremental means we deliver those
As I’m teaching my Practical Product Owner workshop, some POs are having trouble understanding how big a defect is. Sure, they want to have small(er) stories, but a defect isn’t done until it’s all fixed, and the team has decided if they need automated regression tests added to the smoke tests. So, here are three