October 21, 2014
By Johanna Rothman
Long ago, I was a project manager and senior engineer for a company undergoing a Change Transformation. You know the kind, where the culture changes, along with the process. The senior managers had bought into the changes. The middle managers were muddling through, implementing the changes as best they could.
Us project managers and the technical staff, we were the ones doing the bulk of the changes. The changes weren’t as significant as an agile transformation, but they were big.
One day, the Big Bosses, the CEO and the VP Engineering spoke at an all-hands meeting. “You are empowered,” they said. No, they didn’t say it as a duet. They each said it separately. They had choreographed speeches, with great slide shows, eight by ten color glossies, and pictures. They had a vision. They just knew what the future would hold.
I managed to keep my big mouth shut.
The company was not doing well. We had too many managers for not enough engineers or contracts. If you could count, you could see that.
I was traveling back and forth to a client in the midwest. At one point, the company owed me four weeks of travel expenses. I quietly explained that no, I was not going to book any more airline travel or hotel nights until I was paid in full for my previous travel.
“I’m empowered. I can refuse to get on a plane.”
That did not go over well with anyone except my boss, who was in hysterics. He thought it was quite funny. My boss agreed I should be reimbursed before I racked up more charges.
Somehow, they did manage to reimburse me. I explained that from now on, I was not going to float the company more than a week’s worth of expenses. If they wanted me to travel, I expected to be reimbursed within a week of travel. I got my expenses in the following Monday. They could reimburse me four days later, on Friday.
“But that’s too fast for us,” explained one of the people in Accounting.
“Then I don’t have to travel every other week,” I explained. “You see, I’m empowered. I’ll travel after I get the money for the previous trip. I won’t make a new reservation until I receive all the money I spent for all my previous trips. It’s fine with me. You’ll just have to decide how important this project is. It’s okay.”
The VP came to me and tried to talk me out of it. I didn’t budge. (Imagine that!) I told him that I didn’t need to float the company money. I was empowered.
“Do you like that word?”
“Sure I do.”
“Do you feel empowered?”
“Not at all. I have no power at all, except over my actions. I have plenty of power over what I choose to do. I am exercising that power. I realized that during your dog and pony show.
“You’re not changing our culture. You’re making it more difficult for me to do my job. That’s fine. I’m explaining how I will work.”
The company didn’t get a contract it had expected. It had a layoff. Guess who got laid off? Yes, I did. It was a good thing. I got a better job for more money. And, I didn’t have to travel every other week.
Change can be great for an organization. But telling people the culture is one thing and then living up to that thing can be difficult. That’s why this month’s management myth is Myth 34: You’re Empowered Because I Say You Are.
I picked on empowerment. I could have chosen “open door.” Or “employees are our greatest asset.” (Just read that sentence. Asset???)
How you talk about culture says a lot about what the culture is. Remember, culture is how you treat people, what you reward, and what is okay to talk about.
Go read Myth 34: You’re Empowered Because I Say You Are.
October 21, 2014 03:14 PM
October 15, 2014
By Johanna Rothman
Cesar Abeid interviewed me, Project Management for You with Johanna Rothman. We talked about my tools for project management, whether you are managing a project for yourself or managing projects for others.
We talked about how to use timeboxes in the large and small, project charters, influence, servant leadership, a whole ton of topics.
I hope you listen. Also, check out Cesar’s kickstarter campaign, Project Management for You.
October 15, 2014 02:42 PM
October 09, 2014
By Johanna Rothman
If you saw Large Program? Release More Often, you might have noted that I said,
You want to release all the time inside your building. You need the feedback, to watch the product grow.
Some of my clients have said, “But my customers don’t want the software that often.” That might be true. You may have product constraints, also. If you are working on a hardware/software product, you can’t integrate the software with the hardware either until the hardware is ready or that often.
I’m not talking about releasing the product to the customers. I’m not talking about integrating the software with the hardware. I’m talking about small, frequent, fully functional releases that help you know that your software is actually done.
You don’t need hardening sprints. Or, if you do, you know it early. You know you have that technical debt now, not later. You can fix things when the problem is small. You see, I don’t believe in hardening sprints.
Hardening sprints mean you are not getting to done on your features. They might be too big. Your developers are not finishing the code, so the testers can’t finish the tests. Your testers might not be automating enough. Let’s not forget architectural debt. It could be any number of things. Hardening sprints are a sign that “the software is not done.” Wouldn’t you like to know that every three or four weeks, not every ten or twelve? You could fix it when the problem is small and easier to fix.
Here’s an example. I have a number of clients who develop software for the education market. One of them said to me, “We can’t release all the time.”
I said, “Sure, you can’t release the grading software in the middle of the semester. You don’t want to upset the teachers. I get that. What about the how-to-buy-books module? Can you update that module?”
“Of course. That’s independent. We’re not sure anyone uses that in the middle of the semester anyway.”
I was pretty sure I knew better. Teachers are always asking students to buy books. Students procrastinate. Why do you think they call it “Student syndrome”? But I decided to keep my mouth shut. Maybe I didn’t know better. The client decided to try just updating the buy-the-book module as they fixed things.
The client cleaned up the UI and fixed irritating defects. They released internally every two weeks for about six weeks. They finally had the courage to release mid-semester. A couple of schools sent emails, asking why they waited so long to install these fixes. “Please fix the rest of these problems, as soon as you can. Please don’t wait.”
The client had never released this often before. It scared them. It didn’t scare their customers. Their customers were quite happy. And, the customers didn’t have all the interim releases; they had the planned mini-releases that the Product Owner planned.
My client still doesn’t release every day. They still have an internal process where they review their fixes for a couple of weeks before the fixes go live. They like that. But, they have a schedule of internal releases that is much shorter than what they used to have. They also release more often to their customers. The customers feel as if they have a “tighter” relationship with my client. Everyone is happier.
My client no longer has big-bang external releases. They have many small internal releases. They have happier customers.
That is what I invite you to consider.
Release externally whenever you want. That is a business decision. Separate that business decision from your ability to release internally all the time.
Consider moving to a continuous delivery model internally, or as close as you can get to continuous delivery internally. Now, you can decide what you release externally. That is a business decision.
What do you need to do to your planning, your stories, your technical practices to do so?
October 09, 2014 01:42 PM
October 08, 2014
By Johanna Rothman
I’m working on the release planning chapter for Agile and Lean Program Management: Collaborating Across the Organization. There are many ways to plan releases. But the key? Release often. How often? I suggest once a month.
Yes, have a real, honest-to-goodness release once a month.
I bet that for some of you, this is counter-intuitive. “We have lots of teams. Lots of people. Our iterations are three weeks long. How can we release once a month?”
Okay, release every three weeks. I’m easy.
Look, the more people and teams on your program, the more feedback you need. The more chances you have for getting stuck, being in the death spiral of slowing inertia. What you want is to gain momentum.
Large programs magnify this problem.
If you want to succeed with a large agile program, you need to see progress, wherever it is. Hopefully, it’s all over the program. But, even if it’s not, you need to see it and get feedback. Waiting for feedback is deadly.
Here’s what you do:
- Shorten all iterations to two weeks or less. You then have a choice to release every two or four weeks.
- If you have three-week iterations, plan to release every three weeks.
- Make all features sufficiently small so that they fit into an iteration. This means you learn how to make your stories very small. Yes, you learn how. You learn what a feature set (also known as a theme) is. You learn to break down epics. You learn how to have multiple teams collaborate on one ranked backlog. Your teams start to swarm on features, so the teams complete one feature in one iteration or in flow.
- The teams integrate all the time. No staged integration.
Remember this picture, the potential for release frequency?
Potential for Release Frequency
That’s the release frequency outside your building.
I’m talking about your internal releasing right now. You want to release all the time inside your building. You need the feedback, to watch the product grow.
In agile, we’re fond of saying, “If it hurts, do it more often.” That might not be so helpful. Here’s a potential translation: “Your stuff is too big. Make it smaller.”
Make your release planning smaller. Make your stories smaller. Integrate smaller chunks at one time. Move one story across the board at one time. Make your batches smaller for everything.
When you make everything smaller (remember Short is Beautiful?), you can go bigger.
October 08, 2014 01:47 PM