Many of my clients feel stuck with their component teams. They feel they must implement across the architecture, not through it. That’s because the people are organized in component teams. As the organization grows, so does the number of component teams. The more component teams they have, the more complexity they create in the teams, in
A potential client called me. “What’s a good tool to see the state of my projects? I need a tool.” I asked, “What problems do you see?” “Everything is late. No one’s synchronized. I can’t tell where the projects are.” “How many projects do you have in progress?” “At least 100.” (I was pretty sure
You might wonder why I don’t start writing a proposal with a title. In my experience, a great title is something I need to ponder and experiment with. I do often start with a placeholder title. When I developed this multitasking talk, I used this title: Stop the madness. End the multitasking. That was a
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