You decided who your session is for: the people with the problems. You’ve got the outcomes. Now, it’s time to write the abstract. Conference proposals always have a short abstract. Some conferences, such as the Agile 20xx conferences, also have “Information for the Program Team.” You might think of that as the outline or more […]
Now that you’ve framed your proposal, start with what you want people to take away from the talk, the outcomes. Why? Because too many descriptions are a promise for an outcome or what people will learn. If you’re coy about the outcomes, people can’t select themselves in or out for your presentation. Speakers who say,
You want to present a talk, workshop, experience report at a conference. (Or, a lightning talk, Pecha Kucha, or more.) You have something important to share. How can you create a proposal that the program committee will accept? I’m writing this series to explain how to do just that. The series parts are: Understand who
I spoke with an agile coach whose team works in flow, similar to this board. They don’t use iterations—they plan on demand. The column on the left, “Stories to Workshop” is their backlog refinement column. Recently, the team decided they need “minimum” WIP (work in progress) limits. Especially on the Workshop column. Why? Their product
If you are like most people I know, it doesn’t matter what approach you take to your projects—your manager has too much work for you to do. Instead of a potential career-limiting conversation, frame the conversation so you can show your manager you’re considering his or her perspective. Here are some options for how to
You’ve got an impossible project. You have no flexibility. The project is a fixed-price, fixed-scope, fixed-date project. And, you have a specific team to do the work. (There are other impossible projects. Such as when you have a collection of people who multitask among several projects.) Can an agile approach save these projects? No. An agile
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
Do you have trouble fitting “all” of the necessary work into an iteration? Your managers might want to push you to do more. Or, the product owner thinks you can do more. Or, the team wants to do more (see Beating a Team’s Goal.) Agile approaches are not about doing more. Agile approaches encourage us
Shaun’s comment on Measure Cycle Time, Not Velocity suggested a team might be better off measuring both cycle time and velocity. Why? For two reasons: “Beating” the last sprint goal Assisting the PO in a forecast of when things might be done. Let’s examine these ideas. Clarify Story Points Why even bother with story points?
Create Your Agile Culture: Embrace, Not Manage Change Stu, a manager who’d been successful throughout the years by managing risks and managing change was concerned. “I don’t want to move fast and break things,” he said. “I don’t want to move too slowly. I’d like to move fast. But I don’t want to break anything.”