Developers’ lives change when you transition to agile. Product owners’ lives change. Managers lives’ change. The organization’s culture changes. And, when a project and an organization transitions to agile, the testers and test managers lives’ change, too.

Through our debriefs, we will address these topics in the workshop:

• Managing legacy test technical debt (what do you do with the tests that are useful but not automated?)
• How do you change your idea of where you fit in the project?
• How do you change others’ idea of where you fit in the project and the organization?
• What does a test manager do?
• How do you know a product is ready for release? Or, when is a project over?
• How do the testers “keep up” with the developers? (It’s easy. You will experience how. Easy, peasy.)

Why is this especially for test-type people and project manager-type people? Not because I don’t like developers; I do! In many ways, the testers, project managers, and business analysts, the “not-developers” from more traditional projects have a very difficult transition. They may never have thought of themselves as product developers before. In agile, we ask them to think of themselves as such. Making the transition, and maintaining the transition can be a challenge. I can help.

Here are some slideshare.net resources you might find useful:

• QA or Test? Does it Matter? You Bet it Does!
• Agile Testers and Test Management
• Overcoming some Pitfalls of Transitioning to Agile

Some articles you might like:

• Transitioning to Agile Testing
• Agile Managers: The Essence of Leadership
• Transitioning to Agile in the Middle of a Project

I have more on my blog in the transition to agile tag.  Please poke around and read more.

I will address your issues in the workshop. But only if you sign up. I would love to see you there. Please do sign up.

On May 30, I will be in Stockholm, offering a special one-day version of the workshop, partnering with Citerus. I will also be speaking in English here.

Here are some resources you might find useful:

• The interview Shane Hastie did with me on InfoQ.
• My Oredev 2011 session about Agile Portfolio Planning
• My original slideshare presentation about the agile project portfolio

Some articles you might like:

• Decisions, Decisions, Decisions
• Selecting a Ranking Method for Your Project Portfolio
• Always Ask the Zeroth Question About Your Projects
• Are You Being Guilted Into Doing More?

There are more articles at my articles page. Please do poke around. I would love to see you at the Brazil workshop if you are in South America, or at the Stockholm workshop if you are in Europe. Please do sign up.

• Start Your Geographically Distributed Projects Right
• Building Trust in Any Team
• Using Checkins to Create Transparency
• Micromanagement is Not Transparency!
• Managing Timezones in Geographically Distributed Agile Teams

My most recent newsletter discussed how you might start Building or Maintaining Agility in Geographically Distributed Teams.

You can hear the webinar to hear how Shane and I teach/work together.

It’s time. Sign up today.

We had a few recording glitches, so if you hear me talking over Shane, oops. To me, it sounded as if he was not talking. There is a time period about 32 minutes into the recording where he did drop off the webinar entirely, and I was trying to not talk over him. Of course, that’s where I stopped talking. Sigh. I just could not win. Please listen anyway and forgive us our technical oopsies.

Today is the last day for early-bird registration for our workshop, Working Effectively In Geographically Distributed Agile Project Teams. If you are arriving from outside the Bay Area, I have a block of rooms reserved at the local Marriott Courtyard. Please do join us.

Shane and I first delivered this workshop last year in Australia, when I was there for Software Education‘s SDC. We had a great time, and so did many of the participants. We have since evolved the workshop, to address the needs of the participants who did not have a great time, and to make sure we covered the topics we need to cover.

This is an experiential workshop. You will learn by doing and debriefing. If you’ve taken my one-day versions over the past year, you’ve had a taste of what we do in the two-day. You will learn even more from both of us. Remember, we developed this as a geographically distributed pair.

One of the benefits of signing up for the workshop is the informal consulting you can obtain, not just from us, but from the other people there. You’ll hear what other people are doing, what’s working and what’s not working. If you want, you can hear from Shane and me about what’s working and not working at our clients as they transition to agile and explore more agile approaches.

Do check out the syllabus. And, if you’re ready to sign up, please register.

• PSL in Albuquerque with Esther and Jerry. We have 7 spots left.
• Agile Program Management in Stockholm
• Working Effectively with Distributed Agile Teams in Sydney

I’ve had some inquiries in Pragmatic Project Management as a public workshop, here in the Boston area. Email me if you’re interested.

These people are convinced they must pay attention to their work issues while they are in the workshop. And, they are the same people who want the “cheat sheet” or the “10-second overview of user stories” (true!). They are the ones who don’t participate in the debriefs for the experiential activities. They are the people who don’t see the value of instructor-facilitated and experiential training.

I’ve started a new introduction to my workshops. I say something like this: “I know that you are an adult. I trust you to make the right decision about your laptop open or closed. I will warn you that it is impossible to fully participate in this workshop with your laptop open.” (I smile as I say this.) “You have the choice to leave your laptop open or participate in the workshop. If you choose to leave your laptop open, please don’t prevent the other people at your table from working through the activities.” I stop then and start with the workshop.

I have mixed results. The people who believe me at the beginning learn a lot in my workshops. The people who realize I was serious later on in the workshop and finally   put away their laptops learn too, and it depends on when they put away their laptops. I can’t tell about the people who don’t put away their laptops. From the way they debrief the workshop, I don’t think they learn much.

I sort-of understand why conference-workshops are like this. Few people expect experiential activities at a conference workshop. (Ha! Gotcha!) Many of them have never encountered interactive and experiential training before. And, too many of them are expected (so they say) to check in at work while they are at the conference.

I don’t understand why a company brings me in and expects their employees to be on their laptops all the time while they are supposed to be at training. People really cannot do two things at once and do each of them well. They can do one thing well and the other not at all. They can do both things poorly. But they can’t learn and work at the same time.

I do ask people in in-house workshops how often they need to check email and check in back with their teams. I try to have enough breaks and a long-enough lunch to take that into account. But it’s quite difficult if the answer is “I have to be on email all the time.” I can’t teach and accommodate that request.

If you are attending a workshop, please participate. If you are working, go ahead! But, please, don’t try to do both at one time. It just doesn’t work.

Remember, the AYE conference is all experiential and interactive sessions. We would love to have you. And, we give you long-enough breaks between sessions so you can email or phone back to work. You’ll learn to work better. Isn’t that the whole point of workshops?

I used a number of simulations to help people see how to estimate, and I noticed a number of interesting effects:

• In the public workshops, people were more willing to experiment and live with a different lifecycle for a simulation (a more concurrent lifecycle, or an iterative or incremental approach)
• In the on-site workshops, the participants recreated their environment, even when they said they wanted to try something new. Goes to show you how difficult it is to change.
• Relative sizing is a great way to account for the difference in capabilities when you don’t have specialists or people with subject matter expertise. (“A 2 for this group is more time than a 2 if we had a so-and-so.”)

I encouraged people to try incremental and agile approaches to their projects in the workshop. The participants agreed that the approaches provided faster results, and still were concerned that they would not be able to implement those approaches at work. Some of the people were so accustomed to not having enough people, that even when I asked, “How many people for how long?” they could only assume they had access to the other one or two people in their small groups, even though we had 20 people in the room.

Yes, we encountered Parkinson’s Law (work expands to fill the time allotted), which is why I timeboxed the estimation time. “But we need more time for estimation!” “Do you get that time from your managers?” “No.” “So, maybe you can try some other approaches to make your estimates better in a shorter period of time?”

We discovered that non-functional requirements are more difficult to estimate than user stories or even use cases. And, it still amazed me that people are given broad brush requirements, and are then supposed to generate an accurate estimate (within 10%) with such little data. Yes, we talked about ways to iterate on your estimate to refine it. Will their managers listen? I don’t know.

We even had an opportunity to test out my claim: Multitasking nullifies all estimates. It never fails, when I teach an on-site workshop, some people think their work is more important than the workshop. Maybe it is. But I do know that when they leave and arrive and leave and arrive, it mimics what they do at work, and slows down their project. Because I break everyone into parallel groups, when they return, they can see the effect of their in-and-out behavior on their project.

When you estimate, make sure you think about how the project is organized, how many people you need when, and what information the requirements provide. Then show a confidence graph or a three-point estimate to explain how the estimate is really a guess, but a good guess, not a swag.

• Understand different lifecycles and when (and how) to use them
• Practice pragmatic approaches to organizing and estimating a project
• Learn a variety of ways to steer a project to success
• Learn how to develop and use release criteria
• Design the data you want to use to measure your project
• and practice, practice, practice this and more

You’ll want to join us. Everyone receives a copy of Manage It! Your Guide to Modern, Pragmatic Project Management. (If you have that one, I’m happy to substitute another of my books.)

The more formal syllabus is here. The registration form is here (note the discount for multiple registrations at the same time). If you have questions, email me. I hope you join us.

Have questions? Email me. Want to register? Here’s the registration form. If you’ve been thinking about bringing project management training into your organization but want to try before you buy, this is an ideal way to try me out.