Your bio establishes your expertise, authority, and credibility in your field. If your conference proposal has a speaking experience field, use that field to explain your expertise, authority, and credibility. I like to think of the bio and speaking experience fields as ways to connect with and invite the right people to your session: These […]
You know who your audience is because you framed the proposal. You started with outcomes, and you refined those outcomes when you wrote the abstract. Now it’s time to complete the rest of the proposal, excluding your bio and the title. Bios and titles are different from the rest of the proposal. (Those will be
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 keep encountering managers and consultants who want to make work “fun” for people. As a goal, “fun” is a bunch of hooey. Before I was a consultant, I held various Director-level positions at local companies. Each organization had mandatory fun days. In one organization, we played softball. Yes, everyone—especially the managers—had to play softball
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
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
Many of my clients use an iteration-based agile approach. And, they have these problems: They “push” too much into an iteration. They use velocity, not cycle time to estimate. They rarely finish everything before the iteration ends. They have to manage extra work—work they had not estimated—in the form of an emergency or production support.
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