I learned this week that I made the Top Women in Business Blogging list. They tell me my readers nominated me. Dear readers, thank you!
Online MBA Rankings

Tweet This Post

I’ve been working with Rebecca Wirfs-Brock on an agile architecture workshop. I’m working with Rebecca because she has such a depth of experience in architecture, as well as design. She’s working with me because of my project and program management experience. We’re pretty psyched.

We’re working through the issues of large programs and architecture, and, of course, we have encountered the develop by component vs. develop by feature debate. I’m closer to the develop by feature side of the house than Rebecca. She’s a little closer to the develop by component side. We’re not too far apart–we’re not polar–we’re not precisely at the same place. And, we may never be at the same place, because our experiences are different. We each have good reasons.

You get tremendous benefits when you develop by component: high cohesion in the component and low coupling between components. Don’t underestimate the value of these. If you don’t pay attention to cohesion and coupling, eventually you can’t develop anything.

When you develop by feature, you get features. It’s hard to underestimate the value of working product.

But especially in a large system effort, with multiple teams, how do you do this right? Of course, it depends. You might have a combination of teams, in my preference after you have a little experience with some features. Maybe you develop some prototypes. Maybe you do something else.

We’re developing a simulation for the workshop. If you have encountered this problem in your system, please post a comment and let me know if you would like a simulation to explore this. (I am not under the impression this means you would commit to our workshop!) If you’d like to send me private email, that’s great too. We’re trying to develop a simulation that will mimic what happens at work.

Tweet This Post

I’m proud and pleased to be on the list of LiquidPlanner’s Top Project Management Thinkers. I’m thrilled, too!

Tweet This Post

It’s a good thing I said my post about musings was just that–musings! I didn’t bring all of you along. Sorry about that. Let me be more clear.

A program is a collection of projects, where the value is in the overall deliverable. Yes, each project may have a deliverable that’s valuable, but the value to the organization is when all the sub-projects get together and deliver their product. Here’s an example. Think of a cell phone. One sub-project might be the team(s) who create the features that allow the phone to make a call. There may be another sub-project for the features to answer calls. Another sub-project could be the features to manage/interface with voicemail. Another sub-project is the minute counting for administration/billing purposes. The texting features would be another  sub-project.

Each of these sub-projects have teams that are as large as they need to be. So, to answer Veretax and André’s questions: yes, working in smaller teams so each team can be agile does work. Yes, each sub-project works in parallel. The teams for sub-projects work in parallel. When I think of these sub-projects for a program, eacah sub-project has its own rhythm and staff and backlog. That’s why the program needs an overall backlog, because the sub-projects may have interdependencies and may uncover program risks as the program proceeds. In the example of a cell phone, you might not want to start the voicemail until after you know the phone can receive calls. Maybe you can, because maybe there’s a platform that supplies the services your project needs. What happens if you realize you need to change the minute-counting after the call-placing features are done, but before the billing features are complete? You work it out.

But the idea is that you have a program: deliver a cell phone. Each of the sub-projects has its own list of features and each of the sub-projects delivers a valuable result. But, you don’t have a cell phone unless you can make and receive calls and get voice mail. You may need more than that, but you don’t have a product that can succeed in the market without those minimum requirements.

Now, for the why we need program management. I’ve seen (and I bet you have too) programs where the software was all done except for one small piece. Or the software was done but the marketing was not. Or the hardware was done, the marketing was done, and the software was going nowhere. If you have agile approaches to programs, you get to see visible progress (or lack thereof) at the end of each iteration. You don’t have to wait until the predicted or desired end of the program to see the risk.

That’s one of the ways agile reduces technical and schedule risk. The iterations help you get to done across the entire program each iteration and help you see how things fit together. The demo at the end of an iteration shows you where you have technical risk, which reduces schedule risk. In general, incremental approaches reduce schedule risk and iterative approaches reduce technical risk. Because agile combines both, you reduce both kinds of risk. (For more detail on lifecycles, see Manage It!)

Stephan also asked how agile program management differs from “plain” program management. In non-agile program management, managers of sub-projects speak for their functional area, commit people, manage risks, and commit other resources. Notice that there is no program-specific view of the product or transparent coordination across the functional teams. There is not necessarily a ranked product backlog. You could have those things in a “plain” program. I haven’t seen them, but maybe that’s how your program management works.

In agile program management, you have coordination across the cross-functional teams. That’s a huge difference. You don’t have functional managers, you need cross-functional project managers (of some stripe) for each sub-project, and one for the program. Managers don’t commit; teams commit. The program team is all about managing the backlog and risks, the business value of the architecture, and the obstacles for the program.

In case you’re not sure, I’m starting to write the agile program management book, so you nice folks are hearing about this as I try to articulate it. Thank you for your comments.

Tweet This Post

I’ve been working with organizations who want to move their programs to agile. They’ve been successful with small projects. But now, they want to make agile work with large programs, programs that involve hardware or firmware, programs with many pieces of interdependent software features, programs of 50 to 300 (or more!) people.

Now, you might say that we should not even try to do programs of 300 people. That 300 people are too many and it’s too difficult to manage their interactions. And, besides, they can’t know each other. Well, they don’t all work together. And, if you have a large product and you want to finish it in a year or less, you may need that many people. Several of my clients do want to complete large product releases in a short time and use agile, because agile reduces many of the technical and schedule risks. And I want to help them be successful.

Here’s what I know about agile program management:

1. You must pay attention to architecture, not just from the beginning, but all the way through the program.
2. If you try to define the architecture up front, you will be wrong. And, you will discover you are wrong after the predicted middle of the program. If you are really unlucky, you will discover this when things start to break near the end.
3. If you have more than one product backlog, everyone will be confused.
4. If you try to mix up the teams, you can no longer predict any velocity. Remember, velocity is personal to a team. Teams will be consistent in themselves, but once you’ve changed the team, the velocity may well change.

These ideas lead me to say that in programs, you need to address architecture throughout the program, that you need one product backlog for the entire program, and that teams need to be relatively static. None of this is easy. I’ll be sharing the guidelines I develop as I see them.

Tweet This Post

In June, I taught PSL with Esther and Jerry. We had a blast. So did the participants. Part of why PSL is so much fun is that we use simulations.

With a simulation, you create a safe environment in which people can experiment with learning a new skill or seeing how they operate. There are two critical pieces to the simulation:

1. Creating a safe environment in which people can work. No one can learn if they feel unsafe.
2. Debriefing the simulation. If you don’t debrief, you can’t tell what you learned.

There are more pieces, but the setup for safety and the debrief are critical.

What I love about simulation-based training is that people are never wrong. Whatever happens in the simulation reflects their reality. Because people recreate their behaviors in the simulation, they (and the instructor!) get immediate feedback on what happens in their work lives.

If you want to consider experiential learning, that’s what I do at conferences, when I lead tutorials. The AYE conference is all experiential learning. (The current discounted registration of $1500 expires July 1.) My workshops are all experiential learning.

If you are trying to learn something without practicing, stop it. Fire the instructor. Do that kind of work in practice, preferably in a simulation, so you can learn from it.

Tweet This Post

My column at Gantthead, The Agile Project Manager: To Facilitate, Serve and Protect is posted. Enjoy!

Tweet This Post

A twitter follower asked if I could provide a link to a “discussion of tactical vs strategic planning/projects?” Here you go:

Strategic work is a management role. It involves setting the direction for the organization (or group), deciding what to do and what not to do, who to hire and when. If it involves committing the organization to money in some way, that’s strategic work. Here are some examples (not an exhaustive list): managing the project portfolio, deciding on a product line, deciding when to hire which kinds of people, deciding on a software process initiative.

Project management is mostly tactical, the operational approach to the day-to-day decisions. The one exception is at the beginning of the project, when you decide on release criteria and a life cycle. When you decide on release criteria, you have defined the boundaries of this release, a strategic decision. When you decide on a life cycle, that’s a strategic approach to how you use the people. The rest of a project or a program is tactical. Looking for and managing risks? Tactical. Understanding how people are working together–or not? Tactical. Conducting a meeting? Tactical. Problem-solving? In the context of a project, tactical.

There’s also work that requires tactical time, and is strategic management work. For example: one-on-ones, feedback, coaching, career development/discussion, working across the organization to smooth the way for a project, solve other problems, or accomplish something that managers needs to do, such as collaborating on the project portfolio. This is the day-to-day work of a manager, which makes it tactical. It’s strategic in nature, because it builds culture, retains people, builds a trusting relationship with people across the organization, and implements the mission. I can never tell if this is strategic or tactical.

Strategic work is difficult. It requires thought and discussion. Tactical work is difficult in a different way. Tactical work often demands answers quickly. Strategic work, assuming you don’t postpone it and create management debt should take longer because reflection is a good thing for strategic work.

So when I said in Functional Managers Acting as Scrum Masters: Not a Good Idea that Scrum Masters will do the tactical work postpone the strategic work, I meant that the Scrum Master will conduct the stand-ups, will facilitate the demo, review, and retrospective (maybe not personally), and remove obstacles for the team. That mean no one is thinking about or performing the management work, such as managing the project portfolio or conducting one-on-ones, or solving problems in advance of the team, if the Scrum Master is also the manager.

Let me know if this is not helpful.

Tweet This Post

I often meet people who are transitioning to agile, and they decided to pick Scrum, because it’s a helpful project management framework. Ok, that makes sense. But then they decide that they no longer need project managers, and that the development manager can act as the Scrum Master.

The Scrum Master is not a management position. The Scrum Master protects the team’s process and removes the team’s obstacles. For me, the Scrum Master is analogous to the project manager. (I’ve never believed in command-and-control PMs.)

There is still a need for managers, but a little differently.  I don’t see the need for functional managers. The agile team needs a manager who champions that whole team. That means that the champion managers need to understand all the functional parts in the team, so they can help each team member.

But the real issue is that it’s a bad idea to have a manager be a Scrum Master. Here’s why:

1. The Scrum Master is a part of the team, and the manager, because of his/her titular authority can never be a part of the team.
2. People are reluctant to take a risk in front of their managers. (Bob Sutton in Weird Ideas That Work: How to Build a Creative Company cites data about this.)
3. Managers set direction, which is more strategic work. They do this with managing the project portfolio, looking at the makeup of the teams, seeing if they need more people. Scrum Master work is tactical, about the day-to-day work of the project team. If you have to choose between strategic work and tactical work, which one will win? (Tactical, all the time.)

So what does happen to the managers when an organization transitions to agile? They help teams self-organize. They manage the project portfolio. They provide feedback and coaching. They champion the team. They take the lead on hiring.

Managers, do your management job. Project teams, including the Scrum Master, do your project work. The two types of work intersect above the project, not in it.

Tweet This Post

The people who are organizing Your Team Needs Women have a good idea–diversity in teams. I have a problem with how they are doing it.

I have tried to contribute to the agile community, chairing the Agile 2009 conference, speaking at user groups, writing for a number of outlets, working with my clients. I do those things because I love my work. I don’t do them because I’m female. I provide a type of diversity, more because of my age and experience than my gender.

How many people in this field have been developers and testers? That’s a type of diversity I offer. As well as managing projects and programs. I’ve developed hardware/software projects and programs. Too few people have that type of work diversity.

Gender diversity is an obvious diversity. It’s not the most useful diversity. Personality diversity is even more important. (I described why in Hiring the Best…) The nomination even calls it out a little, in the sections about “support, promote and encourage” and empathy.

And, with what I read of the nomination, I am concerned that the nominations are looking for nurturing women. I hope not. I nurture my family, not my colleagues. I’m only my daughters’ mother. I’m not anyone else’s mother.

For me, this would be a fabulous award for *anyone*, not just women. In fact, showcasing men as empathic beings might bring more women into the field, but I doubt it.

The problem is that we need to talk to women when they are teenagers, not when they are in their 20′s, 30′s, 40′s. When we help teenagers think about technology careers, that’s when we can get more women in the field.

Don’t get me wrong. I love recognition of people’s achievements. I was thrilled when Manage It! won a Jolt productivity award, and I still am thrilled. That award was for a book, not a woman-authored book.The playing field was open.

I would love to see this award open to every gender, not just women. When you take most of the constituency out of the equation, the award means less.

Do I think we need more women in software? Yes. Do I think this award will help? No. I’m not offended; I’m disappointed.

If we really want more women in software, some of us women must put on nice clothes and talk to the middle-schoolers, high schoolers, and maybe freshman and sophomores in university. That’s how we influence women to join the field. I volunteer for that.

Don’t just look for women. Don’t award or recognize just women. Look for people with a variety of work experience, life experience, and most importantly, personality diversity. That’s how you get a great agile team.

Tweet This Post

I have a new Stickyminds.com column up: Transitioning to Agile Testing. Enjoy!

Tweet This Post

I’m trying to start a forum on my site. I am stuck and need help. If you know how to set up forums and are available to help me get started, I would like to talk to you. Please email me. Thanks.

Tweet This Post

I wrote an article for Cutter IT Journal, called “Agile Managers: The Essence of Leadership.” Cutter has made the entire issue available for free (registration required). See here.

If you have comments, please leave them here. I will be posting the article at some point, but not too soon.

Tweet This Post

I’ve been working with clients making the transition to Agile. They are accustomed to a product manager “owning” a product, and negotiating for people to work on their product. Of course, that means begging, borrowing, stealing people from other projects and lots of multitasking. It also means that specific people have very specific knowledge of products or pieces of products, and it’s way scary for these product managers to consider allowing other people to work on their products.

These clients have organized their technical folks into teams to work together on projects, one at a time. There’s just one problem. They have more product managers than teams. What do the product managers, who are now product owners, do?

If they ask the teams to work concurrently on two products as if they are two teams, the teams aren’t really one team. If they ask people to slide work into an iteration, the people are multitasking. These folks need the structure of a timebox, which is why they considered and rejected the notion of a kanban board. But, they can rank all the work for an iteration jointly, and then ask the team to work on the stories in rank order.

Notice that they are keeping the idea of work flowing through a team. The two product owners are working together to rank the work for the iteration according to the project portfolio. At least one client is considering shortening their iterations so they can keep the team working on just one product for an iteration. They aren’t there yet.

The product owners are learning how to write smaller stories. The teams are learning how to put more people on a story to finish it faster. The product owners will need to collaborate and the leadership teams will need to keep reevaluating the project portfolio so the product owners can collaborate and provide one ranked backlog for the teams.

Transitioning to agile is difficult. Agile does make the issues transparent. It doesn’t make them easy to solve. At least they can see the problems.

There are plenty of ways for these folks to fail. But they are committed to creating teams who can work together. They are committed to no more multitasking. We’ll see how it goes.

Tweet This Post

Ashley Moran wrote a wonderful review of Manage Your Project Portfolio. I particularly like these quotes:

There’s a wealth of tips for making the whole process effective, with some unexpected ones thrown in. The sections How to Kill a Project and Keep it Dead and Discover Barriers to Collaboration are little gems.

…

It’s also amazing that all this has been fitted into just 170 pages.  You could read it in a day.

Essential reading for software managers, and extremely valuable to anyone in working software who is committed to helping their team deliver customer value while staying sane in the process.

Thanks, Ashley!

Tweet This Post

I’m delighted with the Ann Drinkwater’s review of Manage Your Project Portfolio. Some excerpts:

…

Johanna has translated on paper what sounds good to what really works.

…

The author’s informal and no nonsense approach aided in the delivery of content. I’d recommend this book to everyone, from those just starting out in management trying to make project decisions to those in executive leadership positions. Because the concepts and approaches outlined are common sense and applicable in the real world, I believe Manage Your Project Portfolio will soon become a classic go-to management reading.

Thanks, Ann.

Tweet This Post

It’s been a few difficult weeks. First, I came down with a bad head cold. It’s almost funny, watching a person with vertigo and a head cold try to walk. Unless you are that person ;-) Then Daughter #2 contracted mono. Then the rains came and my office flooded–twice. I’ve spent a bunch of time the last few weeks camped out in the kitchen. Of course, my column deadlines don’t wait, so I managed to write them anyway. I hope you enjoy them.

My Stickyminds.com column, Are You Making Progress or Spinning Your Wheels? received no comments, which surprised me. Maybe because I didn’t know it had published?

My Gantthead.com column is titled, How to Say ‘No’ the Agile Way. (That wasn’t my title when I sent it in. I have to talk to the titlers!)

Tweet This Post