In my most recent writing workshop, one writer, Suzy, had a little trouble staying focused for an entire 15-minute writing session. (For my recommended writing process, see Writing Secret 12: Subheadings Help Guide Readers Through Your Content for how I use 15-minute timeboxes.) Suzy realized she could not always write forward. Sometimes, she had to […]
If you use Scrum or any other iteration-based approach to your work, the team plans in batches for that next iteration. The iteration is a timebox. The batch is the amount of work the team thinks they can do in that timebox. If the batch is sufficiently small and your cycle time is sufficiently short,
Ginny, a project manager, had a frustrating meeting with her boss, Henry, the VP of Engineering. His exact words to her were, “I don’t care how you get it done, but we need all of these two feature sets done. Now!” She explained she needed more teams to finish the work. Otherwise, people would be
A colleague unfamiliar with lifecycles or agility asked, “How can we use sprints in this approach?” and pointed to a phase-gate approach with documentation deliverables after each phase. It looked just like the serial lifecycle in the image on the left. (That’s because a finance person drew the lifecycle.) I said, “You can’t use ‘sprints.’
Recently, several people have congratulated me on my “natural” writing. I thank them and try not to giggle. Why? Because I am not a “natural” writer. I have written and published enough that I found my writer’s voice. Instead of talent, I have persistence. I use that persistence in small, timeboxed chunks. That’s part of the
What risks does your project have? Do you need feedback loops so you can: Cancel the project at any time (to manage schedule and cost risks. Assess technical risks so you can rework the architecture or design to manage feature set risks. Manage what you release to customers so you can manage defect, feature set,
The original signatories of the Manifesto for Agile Software Development wanted to solve these specific problems: How can we: Bring more adaptability to software development? Stop “plan the work and work the plan” thinking? Release something of value earlier? Especially since teams now had these levers, from the iterative and incremental approaches: Prototype something for
I discussed the origins of the agile approaches in Part 5. In this post, I’ll discuss how you can create an agile approach that fits your context. Why should you create your own agile approach? Because your context is unique to you, your team, project, product, and culture. You deserve an agile approach that helps
Which levers does your team need to manage risk in your project? Do you need to cancel the project if you can’t finish a phase? You might not have the time. You might not have the ability to do this project. That’s the point of Serial lifecycles in Part 1. Maybe you need feedback from
So far, we’ve discussed the lever of canceling a project at any time with the serial lifecycles in Part 1. That’s assuming you replan and/or cancel. We added another lever of looking for more feedback with iterating over the requirements in the iterative lifecycles in Part 2. Teams have another lever. They can release increments