Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Are you transitioning to agile? Is it going well?
If it your transition is going well, excellent. I’m happy for you. But if you are like many of the leaders across the organization I’ve met, you have plenty of problems. Sometimes you have a problem as this colleague said,
Right now we’re really struggling with Portfolio Management that is relevant to our business.Ā We can’t prioritize because we can’t define projects in a way that resonates with the business.
Resonating with the business is an issue of influence. How influential are you? Would you like to succeed in managing the project portfolio? Or, in getting the testers/QA involved at the beginning in a real cross-functional team? Or, helping people realize that fast failing is good? Are you ready to prepare to become more influential?
Join Gil Broza and me at The Influential Agile Leader in Toronto, April 8-9, 2014. If you’re in Europe, we’ll be in Edinburgh, Scotland, May 22-23, 2014.
We’ll experience and practice authentic approaches to influence and coaching.Ā (Of course this is experiential. What did you expect?) Where is your sphere of influence? How do you expand it? How do you influence within it? You’ll have a chance to practice with yourĀ peers in real situations.
We’ll help you learn how to coach up, sideways, and down. Up is especially critical. For example, you might have to explain options in different ways when you coach up. Again, you’ll practice, using real-life situations.
There’s much more that we can offer. You, the participants select the rest of the program. We will deliver, experientially, what you want at the time. We are prepared. We’ve done our work. You will drive the rest of the event.
All the details are at the Influential Agile Leader.
Please join us. Early bird registration ends Dec 31.
Sign up now. You won’t regret it.
In my first management role, I “managed” one person.Ā My managee didn’t need much management. He guided me into how to manage him more than I managed him. He saved me from making too many mistakes. It was great practice for me.
Later in my management career, I managed a “team” of 15 testers. They were not a team. They were a group. I’m not sure why my management insisted on referring to them as a team, but my managers did. My role was to match-make testers with projects.
I didn’t think of my role as allocating people to projects, because I kept people on projects long-term. I didn’t fall for the management myth that I could move people like they were chess pieces. That’s why I thought of my role as match-making. I managed the project portfolio for the test group, so I could match-make.
What else did I do with this group?
I’m sure there was more, but that’s what I remember now.
I recently met a smart CTO of a company with about 100 engineers. He said he wanted a flat organization. Makes sense to me. Then he said this, “Every engineering manager should be able to manage about 15-20 engineers, and the projects that they work on, too.”
Oh, boy. You will notice that I was not managing projects in my list above. I was hiring like mad, in addition to the above management responsibilities, and I was full. I could not do any more. If you’d asked Mark, I bet he would have said I was past full. I did all my phone screens after dinner. When I needed to, I also wrote reports after dinner. I had no time during the day.
Could I have done any useful project management? No. Could I have managed any more people? No. Certainly not up to 20.Ā Why? Because I needed time to meet with everyone, some people each week.
Why could I manage 14 people? Because I was an experienced manager by this time. I’d been practicing. First with one person. Then with three or four. Then seven, eight. When I had nine people in my group, I realized I had to move to biweekly one-on-ones for some people. I asked the people who were more senior if they minded. No, it was okay. But if they were more junior and needed coaching? It would have been a disaster.
And that is the topic of this month’s management myth: You Can Manage Any Number of People as a Manager. If you don’t care how well you manage, you cannot manage any number of people and do a great job.Ā It’s the same principle as code or projects. If you don’t care how good the code is, you can write as much as you want. If it doesn’t have to work, it doesn’t matter. If you don’t care how good your project management is, you can manage as many as you want.
I’m not talking about micromanagement. I’m talking about providing coaching if the other person wants it, a learning environment for the people, a place for people to learn, a trusting relationship with each person every week. That’s it. I expected the people in my group to spend the rest of their time learning on their own and being responsible.
But because we were hiring, and because I had responsibilities across the organization, we were all busy. If I hadn’t made time for our one-on-ones, I could have gone for weeks, not seeing people. That would have been Wrong.
If you are managing more than nine people as a manager, rethink what you can do. If you are not having one-on-ones every week or every other week, what else are you doing?
Management is not about micromanagement. It’s about creating an environment in which everyone can do their best work. If you are too busy to do that, are you really managing?
The title of this blog is “Managing Product Development.” That means that I manage my own product development, products and projects, as well as provide advice for other people. I have many opportunities to do that. My most recent opportunity arose this past year when I self-published Hiring Geeks That Fit, electronically and in print. Hereās the entire story.
I was having trouble with the publisher of the original hiring book. The print book was not always available on Amazon, never mind other outlets. The electronic book was priced too high and not available on Amazon. And, I needed to update the sourcing information. The world had changed.
I owned the copyright, so that wasnāt the issue. The issue was communication. I was having trouble reaching my publisher. My calls and emails were going into the big bit-bucket in the sky. This Was A Problem.
At the same time, I had proposed the agile program book to the Prags, and they rejected it. I was so disappointed, I cannot tell you. My publisher didnāt love me anymore! No, itās not that they didnāt love me. They didnāt think there would be a large-enough audience for that book. (Itās a good thing they rejected that book then. Iāve since worked with more clients and refined my thinking. I would have published yet another book before itās time.)
I decided to take back my electronic rights to the hiring book and create the second edition. And now, I had another book to write, not in the Prag system. What was I going to do?Writers Need Tools That Work for Writing
When I write, I want tools that help me write. I don’t want to edit as I write. I want to write fast, to get the words out. I edit after I write. I spell check after I write. I look for passive voice, bad writing later. The faster I write, the better I write.
If I write in Word, I edit as I go. Writing in Word—for a book—guarantees me a bad outcome. Thatās why many other authors choose Scrivener. Itās a terrific text editor.
When I wrote my books for the Prags, I had an even better toolset. I used TextMate with several bundles. For me, TextMate is a terrific text editor. But how would I use TextMate to create a book?
I didnāt want the hassle of learning how to use asciidoc, although I did install it on my system. I am an old programmer, but really. I want to streamline my book creation, not make it more difficult. I want to turn the crank and have a book come out.
What do I tell my clients? “If it hurts, do more of it and understand how to make it easier.”
I tried to use Scrivener. But when I did a Hudson Bay Start, and exported to a book? You would have laughed at that book. I almost cried. The book stunk—not the contents, the format. It didnāt look like a book.
When I heard about leanpub, and writing in markdown, I was so excited. This is exactly what I wanted. I knew how to write in this workflow.
Now, all I had to do was export the old hiring book into html, import it into markdown, and go from there.
This one step took me a couple of weeks to get right. Yes, a couple of weeks. But, once I had it right, it only took me a few weeks to fix what I needed to do in the hiring book.Iām almost thereā¦
I found a cover designer and had her make a āsecond editionā cover for the hiring book. I kept calling and emailing my old publisher to explain what I was about to do. The day before I was going to hit āpublish,ā I received an email from my publisher.
“No, you canāt do this. I just sold the rights to that title. You canāt use that title, even with a āsecond edition.ā This other publisher is going to put the old hiring book up in all the ebook formats everywhere with the old title.”
“When is this going to happen?”
“Any day now.”
That was March or April of 2012. It didn’t happen for another year. But, what am I going to do now?
I can make a better book, thatās what I can do. That’s what I did. If you want to know how, read Part 2, coming tomorrow…
Continued from Part 1…I Wrote a Better Book
How do I make a better book? I removed all the passive voice. I updated the book with the new sourcing material about Twitter and LinkedIn—neither of which existed when I first wrote the book. I updated the templates, because Iāve learned over the years.
I updated the book to exploit the issue of cultural fit. Especially with the advent of hiring for agile teams, the issue of cultural fit is huge.
I cut more than 20,000 words. I excised adverbs. I added more interview questions. Even with the additional sections about Twitter and LinkedIn, this book is still 20,000 words smaller than the original hiring book.
I have a new title and a new cover. Yes, I had my cover designer work on a new cover. I found an editor who helped me edit. I read that book so many times I think my eyes bled. (Okay, not really, but it felt that way.)Six Months to Electronic Release
I released that electronic book in six months from the time my original publisher said, “No.”
Iād been releasing on Leanpub all along. But when I published the book on Amazon, I knew Iād done it. I was officially an indie author. I asked the Prags if they would carry the book in their bookstore, and they said, āYes.ā (Thank you, Andy and Dave. I knew you still loved me :-)
Mark and I had wine with dinner that night!
I thought I was done. I had an ebook in all three formats: mobi, epub, pdf. What else did I need to do?When Will You Go to Print?
I announced the book on my email newsletter, and several of my readers asked, “When will this book be available in print?” I thought, “Oh no. What am I going to do now?”
My friend, colleague, and mentor, Jerry Weinberg, keeps saying, “No one reads print books anymore.” But my email data is saying otherwise. If I build the print book, will they come?
I found a print book designer, because this book is too large for me to do myself. I have to do a spine and a back cover. I know there are too many decisions. I donāt know what I donāt know. I know I need a helping hand or two.
I found a delightful book interior designer. I also discovered Dean Wesley Smithās workshops, and took them at the same time, so I knew what to look for. And, maybe Iām ready to do this myself the next time.Everything Takes Longer Than I Expect
The bigger the book, the longer everything takes. Hiring Geeks That Fit has many templates and several images. That makes layout take longer. Heidi, my book designer, starts in earnest in May 2013. We think we are done in late June. Thatās pretty fast. She sends the book to the indexer.
She uploads the book to Createspace in mid-July. Yes, thatās mid-July. I have to wait for the proof to see if I like the book. The book takes about a week to arrive.Iām an Idiot
I find a couple of things in the proof. Thatās why we print a proof. Thatās not a big problem. But there is a big problem.
There is too much space between the lines on each page and too much space between the words. This is leading and kerning.
I did not realize what the book would look like in print. I am an idiot.
Even though I have reviewed the pdfs Heidi sent me, the problem is that the book does not look professional. It looks as if an amateur put it together.
When there is too much white space on the page, a book is more difficult to read. You need enough text on the page to maintain your attention. You need enough density to keep reading. There is a balance between too much and not enough density of words on the page. I did not realize what the pdfs would look like in print. Iām an idiot.
I felt low and wondered, “Am I ever going to get this book to print?”Keep Moving
Luckily, Heidi understands styles in InDesign. They still mystify me. Oh, I understand them in theory. I cannot figure them out in practice. I donāt understand how to apply them when I import text from my books on leanpub. Thatās a problem!
I think it only took Heidi another week to make all the style changes. I had to order another proof and that one was fine. But, this process took us almost a month.
The final print version was actually available for sale back in mid-September. But I had started traveling and wanted to announce it. I also wanted reviews on the book page on Amazon. I had to ask my reviewers, “Please post reviews on Amazon.”Do I Do a Book Launch?
Iād thought of doing a book launch, where I ask people to provide my email subscribers presents, but doesnāt fit the way I currently think about my business.
Question: Would you folks like a book launch with presents? Maybe I should rethink the way I think about book launches. I would like feedback from you, my readers.What I Learned
I have learned a lot about managing my own product development. This is what I learned:
So, Hiring Geeks That Fit is available in print! Itās also available in all electronic outlets: leanpub, the Pragmatic Bookshelf, Kobo, Amazon, Smashwords, Barnes & Noble, which has it in both electronic and print forms.
If you are hiring people, you should buy this book. Now!
If you have read this book, please post a review. Thank you.
My next book is in beta: Manage Your Job Search. Yes, I am using what I learned. No surprise there!
Iāve learned a lot through this process, and expect to learn more as I continue to publish. Thanks for reading.
Glen Alleman seems to have nailed it, with Alert – Was Poor PM the Root Cause of ACA Difficulties? Among the many problems:
Do I believe in program management—one person to coordinate the efforts of everyone—for large programs? You bet. Do I believe in project management? You bet. Am I one of those people who believe in agile project management for geographically distributed teams? Yes, sirree. How about projects and programs where people are clinging to their silos? Absolutely.
Ron Jeffries, on Twitter, the other day said,
None of Agile, Lean, Kanban, or any other method ever recommended not thinking. Those who do them without thinking do…
No one is supposed to turn their brain off when they go to work. Honestly.
That is exactly why I believe in creating a healthy project culture. If that requires someone whose title is “project manager” or “agile project manager” to steer the project or program, that’s fine with me. Not to control. To steer.
In a serial or phase gate project, you do need someone with some kind of a project manager/program manager title. Why? Because the discipline is in the project manager, not in the team. It’s a hierarchical approach to managing and steering projects. You can still create a healthy project culture.
Now, how do you create a healthy project culture? Well, you could read what Glen wrote in his post. Note the emphasis on evaluating where you are and replanning. I have yet to meet a project that does not require replanning. Every project needs built-in feedback, more often, rather than less often. Rolling wave planning helps you build in feedback. It does not create the illusion that you have a path and you will stick to it, come hell or high water. It promotes transparency, because you say, “Here’s where we are. There’s where we want to be. How do we get there from here?” It’s a tool that works.
Here’s what I consider to be elements of a healthy project culture:
On a small project, do you need a servant leader? Maybe not. It depends on the project team. On a large program? Oh yes. It’s risk management.
If I’m the project or program manager and it’s getting to the end of the project, I might not want to hear the risks. But I do want to hear them before we release. Because if I’m trying to meet an “immovable” date, I should have been developing with all of those qualities such as performance, reliability, and security in mind from the beginning.
Did you read “A Lifetime Guarantee” by Forrest Shull in the November/December 2013 IEEE Software? (The article is not online yet.) It’s about a company, AIS, who provides a lifetime guarantee on their software. The team decides on the schedule. The company invests in training the team.
“In return, the team takes ownership of the process and can create a process that actually helps get the work done.”
In a healthy project culture, people work together to accomplish the goal. They know where they want to go. They know what done means. They do some work. They see where they are, they replan, they repeat.
With a healthy project culture, it doesn’t matter what approach the team uses: phase gate, iterative, incremental, agile. It doesn’t matter. Without a healthy project culture, they are doomed.
Are you creating a healthy project culture in your project today?
I have posted several slideshares for your reading pleasure. You won’t get the pleasure of my humor, eye rolling and jokes. Nope, for that you would have had to hear me speak.
In September, I spoke at AgileSoCal, and had an interactive talk, Agile Teams and Collaboration: What’s New About Agile? I have a small piece about project chartering in this talk. I had a terrific time there. Thanks for being such gracious hosts, AgileSoCal.
In October, I was the keynote at the Project Management Exchange conference at Texas A&M. They say, “Howdy!” a lot there—I liked it! I delivered myĀ Say Yes—Or Say No? What to Do When Faced With the Impossible talk. I’m not sure these wonderful folks had seen an experiential or interactive keynote before. We had a great time.
Last week, I spoke at the Project Management/Business Analyst Summit here in Boston. (Yes, sleeping at home! Fist pump!) I delivered my first updated public version of Agile Program Management: Collaborating Across the Organization. I received many great comments on it.
I also took this time to clear out some of the slideshares on my LinkedIn profile. My goodness, some of them were quite old. You can find all my slideshares on http://www.slideshare.net/johannarothman.
I had an idea, prompted by one email request: would you like a series of webinars of my talks, recorded? If I can figure out how to use the camera (with lighting), you would be able to see my eye rolls, and be in on the jokes. It’s still won’t be experiential, but it might give you a flavor of me speaking. Please comment if you think this would be something you’d like.
The larger the effort, the more we need to estimate. And, the more your estimate will be wrong. The more we estimate, the more we have schedule games. The smaller your effort, the easier it is to estimate.
That’s why I suggested you use agile approaches in this estimation series. You can break things down, and iterate. You get more information, and estimate smaller chunks. You are more likely to have accurate estimates.Software is Not Construction; Software is Learning
Here’s one problem I have with estimation. Software is not construction. We can’t build software the same way we construct or manufacture anything. Software is all about learning as a team. We can timebox our learning. We can choose to stop doing something. We can put acceptance or release criteria around it and say, “We have done enough for now.”
But, we cannot say, “We can build this software for $xx per square foot.” We don’t know how to do that. Because we have not built exactly this software before. If we had built software like this before, we can estimate pretty darn close, because we either have historical data with good estimation quality, or we have small chunks of work we know about, or both.
When we estimate, other people think of our estimates the way they think of estimates in other fields, especially construction. Especially if you provide a single-point estimate. Even if you provide assumptions, which no one hears.
We estimate for these reasons:
Remember I said software is about learning? And, remember I said we never (okay, almost never) do the same software project twice?
If you always have deliverable software—this includes all tests, documentation, everything you need—you don’t need to estimate anything. You also gain the benefit of learning, so if someone asks, “How hard is thing to do?” the entire team can huddle together for a few minutes and say, “It’s this story and that story and this story, too.”
They then say, “We know it’s at least these three stories, and that’s off the top of our heads. Are those stories more important the ones at the top of our queue?”What Do You Do? (Or, Prove It, JR!)
I don’t estimate my work. I work in chunks of work that take anywhere from 5 minutes to one hour. I rarely work in one-hour chunks. Most of my work takes less time than that.Ā I doubled my output this year by moving to smaller chunks of work.
I finished one book this year, and have another in beta. I have more books in progress. All while maintaining the same number of speaking and training engagements. I wrote roughly the same number of blog posts. I edited more agileconnection.com articles. Why can I do more?
Because my tasks are small. Because they are small I don’t have to estimate. I don’t have estimation time built into my work. I work in flow. That changes everything. I rank what’s most valuable at any time, and work on that.Why Do You Estimate?
Why do you estimate? If you’ve estimated because you always have, think about it. If you estimate because your money people want to do once-a-year money allocation, well, you know that’s fiction. You can do it without detailed project estimation.
For money allocation, decide how valuable the project is to you. When does the project have to deliver the value? Now, tell the project team when the value has to be delivered. That’s all.
Remember, you hired these people because they were smart, responsible human beings. Stop with the phases and all that nonsense. Tell them what you want. Remember, the phases exist because management wanted to be able to cancel the project before it got too far along. You were supposed to show a deliverable and re-estimate at each phase. If don’t cancel, deliver, and re-estimate at each phase, your phases are not working for you.
Buy them a copy of Manage It! Your Guide to Modern, Pragmatic Project Management, which explains how to manage projects in any lifecycle. Give them a ranked backlog. Let them deliver. If they can’t deliver in the money or date frame, they will tell you. They are responsible humans.
If you need an order-of-magnitude estimation, fine. That doesn’t take days to determine. That takes hours. It will be precise-wrong and order-of-magnitude-right. Timebox it. It’s an order of magnitude. Don’t hold anyone to that estimate. (Quick, what’s the definition of estimate? “Guess.” That’s the definition. I kid you not.)
If you want to know when you’ll be done because you think you’re close to the end of the project, ask yourself this question: Is it worth the time to estimate vs. the time to finish? It might be. But know you are taking time away from finishing.
And, if you want to play the blame game remember that management is the one who needs to shoulder the most blame. Why? Because management set the constraints. Don’t believe me? Read the estimation series now.
I can sympathize with management’s need for estimates. I like order-of-magnitude estimates for many things. I even like specific estimates as we get closer. But creating software is not like driving someplace or like constructing a building. When I drive somewhere, I do want step-by-step instructions. When constructing a building, I do want an estimate. And even then, I am pretty sure the estimate is optimistic.
When creating software, I want to see working software as we create it, because with software, we learn. The learning is what’s most important. Because once we’ve learned enough, we can stop. That’s what’s most valuable. Not the estimate.
Did you see Dwayne Phillips’ post today, Adding People to a Late Project? Dwayne says:
Adding people to a late project only makes it later. We have known this for decades.
Especially in the article he refers to, it seems as if there might be no end to the number of people added.
Did anyone ask the people on the project if they needed more people? Maybe they needed to know which requirement is top on the list. Maybe they needed acceptance criteria for each feature. Maybe they needed each feature to stay put for more than a nanosecond. There is more than enough blame to go around for this particular project. Most of the blame has nothing to do with the developers and testers.
Now, if they had asked me what I would do, here is my plan.
I don’t know the culture of the project. I don’t know how many people are on this team. Is it a program or a project? Did they have silos to start? Did they think they could use waterfall?
I empathize with the technical people on the project. They were and are the victims of poor project management decisions and poor management decisions. On the other hand, they could have coded defensively with many tests. Maybe they did. They could have tested defensively with many automated tests. Maybe they did. In that case, they are ready for this phase, the “other 90% of the project.” Because they are deep into the 90% Schedule Game.
I bet these people are smart enough to work themselves out of this, by using timeboxes. The question is this: Are the managers smart enough to let them?
The nice folks at ScheduleMailer interviewed me about how I accomplish what I do. They consider me a time management expert. That’s what project portfolio management will do for you.
I thought it was funny that one of the questions was about work/life balance. I wanted to say, “Honey, it’s all life.” I managed to refrain. I said instead, “It’s all my life.”
Read the entire interview about time management—really choices about what you do when—here.
I read Sayonara Sony: How Industrial, MBA-Style Leadership Killed a Once Great Company, and was struck by how the company appeared to make decisions—what will make us the most money now?
If you make your project portfolio decisions based on money, estimated cost, you too will have Sony’s problems. This is why cost is the wrong question to ask. You want to ask the value question, “How much value will this project provide?”
This is not a return on investment question. That’s a prediction question. You can’t answer that question either.
When you use cost as the “which project should we fund?” you can guess right. But you guess based on what you think the market will buy, not what you decide is the right strategy for your company. Big difference.
This is why you want a mix of projects in your project portfolio: Projects that keep the lights on; projects that keep cash coming in; and projects that are innovative, that have the power to transform your organization. And the problem is this: in software, you often can’t tell which one is which. This is why agile or lean is so wonderful. You don’t have to be able to tell.
If you use incremental budgeting and an agile approach to your project portfolio, and an agile/lean approach to your projects, you can pivot when you need to.
Now, you might need to do a quick SWAG (Scientific Wild Tush Guess) for an order of magnitude estimate for your project. Is this project bigger than a breadbox? Is it smaller than a space station? That’s not a project estimate. That’s a SWAG, an order of magnitude estimate. You do a SWAG with a few people in under an hour. Two hours max.
For the project portfolio, you make the evaluation decision based on your best guess of the project’s comparative value to the organization. This is why it’s so helpful to be able to deliver something in a short period of time, such as 2-6 weeks, when the project portfolio people will want to reevaluate the portfolio again.
Oh, and those Sony engineers? The ones who were laid off when Sony couldn’t keep their commitment to lifetime employment? Some of them went to LG. You know, the company that you probably bought your flat screen TV from? All I know, is that every hotel I stay in has an LG TV. In our house, we have (smaller) LG TVs.
When you use value to make project portfolio decisions, you decide on the most valuable project. If you change your mind, you don’t can the people. You change what the people do—you flow work through the team. Is this more difficult with hardware? Of course. Is it impossible? No.
People want autonomy, mastery, purpose. (Yes, this is from Dan Pink.) Give it to them. Tell them what is the number one project. The number two project, etc. Tell them what is not funded, and why. They will work for you, to make it happen.
I just read Scott Berkun’s The Year Without Pants: WordPress.com and the Future of Work. For me, it was a mixed read.
Yes, you can make a totally distributed team work. What you need to do:
That was the good stuff.
Now, for the stuff I didn’t see and wanted to see. I’m a WordPress user. I run my site and my three blogs on WordPress. I’m a developer by training. I have worked in small startups and medium size companies. I wanted to see and feel the passion for the work. I wanted to see Scott change over the year and Automattic evolve over the year, to see what they learned. I didn’t.
For the first 15 years of my career, I was a developer or tester, working in small teams such as these. I wasn’t geographically dispersed, like these teams, but I worked in small teams, where we had small deliverables and we delivered. We never got houses together in strange cities, but we had the excitement of getting ready for releases and trade shows, and we made it. I can tell you stories of early breakfasts, lunches together, late dinners, and then the releases. I can tell you stories of conferences, where we did have hotel rooms together. I knew those people—some for just a little while, some for more than 30 years—just as well as I knew my family. I still stay in touch with some of them.
I wanted to read about that passion. About that commitment. About that involvement. In this book,Ā the only time Scott showed passion was when he described their in-person meetups. When the team was together. When they were working, but more when they were drinking and eating together when they weren’t working. Isn’t that interesting? If distributed or dispersed teams are the future of work, why was Scott’s passion so evident only when the team was together?
I wondered why. Maybe because there were no testers? It’s hard to keep testing your own code, day in and day out. But I think it’s more than that.
It’s because it was such a homogenous culture of young single men. Not a single woman was mentioned in this book. Not one. At least, I couldn’t tell that there were any women there.
Women change teams. Would the team still have gone drinking every time they got together until 2am or longer? Maybe. But, I bet they would have thought about their customers differently. Why? Because at least at that time, more women blogged than men.
Way back, when I worked with my small teams, we changed the interfaces for our products. Why? Because my hands were smaller than the men’s hands. We made things I could use. Yes, these were physical products. Our customers were happy. Not all of our customers were big men with large hands. And, I learned about color blindness early, because the men I worked with were color blind, so our system interfaces took what they could and could not discern into account. Some of our customers appreciated our thoughtfulness.
When you have team diversity, you can create much better products.
I didn’t see was any changes or evolution in leadership and management. I expected to see a change in Scott, the team, or the company. I didn’t. I saw no change in how Scott managed, or how he evolved. Did he change as a result of working for Automattic? I can’t tell.
Did his team members change? Well, there were two promotions, but, we as readers can’t tell why.
Automattic, the company, grew to be twice its original size. We are not privy to any of the changes, and I expected to see some changes. Nope, not a one reported.
When you read other books of this ilk, such as Soul of a New Machine, you read about the passion of the people for their work. You read how they changed. Nope, none of that here.
Other reviewers have exclaimed that this is the future of work. I hope not. No women developers? I hope not. Passionless, changeless, a senior manager making all the decisions in an opaque way? I hope not.
Here’s my vision of the future of work:
The future of work is not about young single men working by themselves all over the world, coming together once a quarter to drink and meetup. That’s not the exciting part.
The exciting part is that there are smart people all over the world, men and women. We can use them on our projects, as long as we have the tools to incorporate them well. Those tools need to promote transparency; they don’t have to be high tech. Read Lessons Learned from Leading Workshops about Geographically Distributed Agile Teams to read the lessons that Shane Hastie and I learned.
Work is personal. Work is about connection. The reason Scott became passionate about the meetups is that he, as well as his team members, needed the connection. Sure, you can have distributed and dispersed teams. And, those teams need to connect.
Connected teams, teams who know each other will always deliver more and better than teams who don’t. That’s the future of work. How you make connected teams? That’s up to you.
I was in the midst of an assessment when the CIO came to me, and shut the door.
“I have a serious question for you.”
I nodded for him to continue. I put aside my papers to show him I was providing him my undivided attention.
“I’m thinking of offshoring all the testers. What do you think?”
“You can do that. If you do, you will take longer to get a release out the door. Since you brought me in to see why it’s taking you 18 months to get your 9-month releases out, I’m not sure it’s a wise thing to do. Why are you thinking this?”
“All the other CIOs I know are doing this.”
This was in 2002, just as the offshoring/outsourcing boom was starting. Agile had not yet become an accepted way of working. I had recommended working in feature teams and working in timeboxes, with small(monthly) deliverables, with people working on just one project at a time. Yes, you can see my current thinking in that report.
That CIO was not alone. His management and his board was exerting tremendous financial pressure on him to reduce the cost of his projects. At the same time, they were exerting the same pressure to release faster. He was stuck between a rock and hard place.
In another assessment, just a few years ago, I encountered the same situation, where senior management had made the decision to hire developers in New York City and testers in Singapore, a 13 hours time difference.
I’ve met people in my teaching who have developers all over the US and testers in the Far East. Every single time I hear the same story: the delays in the project are overwhelming. Read Lessons Learned from Leading Workshops about Geographically Distributed Agile Teams for more information.
Why does senior management do this? Because they do not realize that software is about design and learning. Design and learning are collaboration efforts. When senior managers think software is like manufacturing, they miss the essence of software: collaboration.
What are the successes? When you hire feature teams in one location. What? You think you can only hire testers in India? Ha! They have developers there, too. Or China. Or Vietnam. There are developers all over the world. Do you need to teach them English, or French, or German, or whatever your project language is? Yes.
That is the subject of this month’s management myth: Management Myth 21: Itās Always Cheaper to Hire People Where the Wages Are Less Expensive.
Wage cost is not project cost. You need to assess the cost of delay in your project. You need to ask yourself what is driving your project (cost, schedule, features, people, something else?).
What if everyone is distributed? You can do that, too. You need a lot less management. You need to be very clear on what a team is going to do, first, second, and third. If you yank a team around and change their goals all the time, you will get nothing out of that team.
Decide on how much management you want. If you are a larger organization and want/need some hierarchy and you want people to come into work every day, go for feature teams in one location or another. If you are smaller and can manage with less management/hierarchy, go for distributed or dispersed teams, where people work anywhere, but are more or less in the same time zone.
But, the more time zones apart people are, the more difficult it is for people to collaborate. That is why geographically distributed teams are so difficult to make work, for agile or any other team.
Can you hire people anywhere in the world and make it work? Of course you can. As I have said before here, you are smart people. You can make anything work. At what human cost?
If you read my most recent post, Comparing Teams Is Not Useful: Exposing Another Management Myth and the comments, you will see that I rant about the business of normalizing story points for predicting cost or schedule for a program. That led to several comments re SAFe for programs or other frameworks or lifecycles for programs.Everything Starts With Trust
Does your management trust you? When your management asks you for an estimate that is more than an order of magnitude estimate, it’s because they don’t trust you. That’s because you haven’t been delivering often enough for them.
Now, you can be upset about this, you can leave this alone, or you can fix this. I like fixing. The way you fix this is to work on smaller features (not infrastructure), demo more frequently, and release more often, assuming you have the kind of product that allows you to do so. I didn’t say this was easy to execute.
You build trust by delivering. Period.
Do you trust your management? Trust goes both ways.
Your management has to create an organization in which there is a product owner for each feature team. Each feature team works on one project at a time. No person is yanked off a project onto another project—work flows through the teams.
If you have or are willing to create these conditions, you can make any number of forms of agile work for you.
If you don’t have this level of trust at the project level, why would you try to attempt an agile program? (Go read Agile is Not For Everyone.)
I know, you feel the pressure. Or, someone says, “You must go agile.” Have you read What Lifecycle? Selecting the Right Model for Your Project? You have choices, other than waterfall or agile, especially for programs.If You Want to Use Agile for Managing Programs…
If you want to use agile for program management, you need several conditions in the organization:
Why? This is the basis of trust. This allows what we have from the agile manifesto:
Individual and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Why is this so important? Change happens in a program. It occurs even more in a program than it does in a project. If you can’t trust the people working on a program to make decisions, who can you trust?
If you read my series on small world networks, you know that I am a fan of autonomy, collaboration, and exploration for and among the teams. I am also a fan of measurement to see the risks as they occur.
But management wants to know, “How much will this project cost? When will this project be done?” I understand that they want to know. (BTW, this smacks of contract negotiation to me.)
Remember, the definition of estimate is guess.Estimation is Insufficient as a Basis for the Project Portfolio Evaluation
Leffingwell is correct when he says that many management teams want an estimate for large programs. I wrote a series last year about estimation.
If you fall for estimation as your way of valuing projects in the portfolio, you are doomed to fail. Why? Because you are trying to predict the cost or the date when you know the least about the project. I guarantee you do not have a full backlog. I guarantee you do not know everything about the product. I bet you don’t have everyone on the program. You could spend umpty-ump Iteration Zeros and not get to an accurate estimate. It doesn’t matter.
You have to use value as the basis for ranking the projects in the project portfolio.
You don’t have to go into the project portfolio ranking blind, especially if you use agile approaches. You can say, “Do an iteration (or two or three) and create a walking skeleton. What does that tell us?”
This works if your iterations are short, as in one or two weeks. If your iterations are longer than two weeks, this doesn’t work. Sorry, you are now in contract negotiation.
Now, based on the teams’ knowledge (or some small number of the teams’ knowledge), do a SWAG estimate of how big this program is. I timebox this step. “Is this program worth doing?” is a valid question. This is different than an ROI (return on investment) analysis. This is asking, “If we spend time on this program, will we get something valuable that is releaseable to customers before we’ve spent all our money?”
The “is this program worth doing” is a different question than either “can we release every iteration” or “what is the ROI for this program”. The “worth doing” question is a question of magnitude. The “can we release every iteration” is a question in the small. The ROI question attempts to estimate every item in the backlog, the backlog that in my experience is bound to change, which makes estimation moot. (I have seen teams waste team-years in estimation. Yes, I have.)
If you use estimation as the basis for evaluating projects in your portfolio, you will miss potentially transforming projects. You will miss the projects/programs that have the capacity to push you light-years ahead of your competition. Why? Because you can’t estimate them. Why? Because you haven’t done them before! You have no freaking clue how long they take. You can lie and SWAG them. Or, you can provide a walking skeleton and keep re-estimating them.
Or, you can do what we’ve done since time immemorial: provide interim deliverables at frequent milestones and show your progress. Agile allows us to do this very well. So does staged delivery, because it’s an incremental (not iterative) lifecycle, which is why I like it. You build the product and show your progress. If you are from the Engineering side of the house, this is concurrent engineering.
When you do show progress, you build trust. You can collaborate.Change is Good, Especially in a Program
Remember, in agile, we welcome change. We want the backlogs to change. Remember in Organizing an Agile Program, Part 4: Start From the Teams and Work Up, I discussed how teams could work across the program on other backlogs? You want that on an agile program. Roadmaps are not set in stone. Program roadmaps are meant to change.
The teams need to be able to release every (short) iteration. That’s what makes the program effective. That allows the program to change. That allows the company to release a valuable product faster.
Remember that feature teams releasing is not the same as releasing a product. Product release is a business decision. Feature team release is an issue of integration.Varying the Backlog Creates a More Valuable Program
When you vary the backlog, especially in a program, you create more value. This is why estimating, in advance, limits your options in the project portfolio. You might need to know if this project is bigger than a breadbox. But this is why I use cards and stickies with my clients when evaluating the project portfolio. People handle the cards and they create a shared sense of what the project is.
Once they discuss the card, now they understand the magnitude of the project. They say, “Okay, we’ll let this project run until this milestone or until we see this, and then we’ll reevaluate.” That’s great. That’s exactly the discussion you want at the project portfolio level. Maybe the milestone is how much money you’ve spent. But it’s more likely a feature set achieved. Or a feature set achieved in a certain window of time.
This is the strategy of your organization. The sponsors need to discuss it. They need to fight about what is valuable to the organization. As long as the product development organization is delivering, chunk by chunk, they can continue to discuss.
If the sponsors really want you to stop delivering to start estimating, okay. You can do that. As long as they realize the % confidence you attach to your estimate is less than 100% until the end of the project, that’s okay. Because the backlog is going to change, right? So, you can never have 100% confidence in your estimate.
Oh, and if you think you can state a single-point date with assumptions? Hah! No one ever hears your assumptions. No one.What Management Wants
Management wants comfort. Management wants a crystal ball. Management wants the illusion that it had with Gantt charts. I understand that.
And, if you have a not-quite-steady transition to agile, you can’t release every iteration. Or, your iterations aren’t short, as in two weeks. Which means, you can’t change frequently enough, which means you need to do prediction.
I understand management wants something comforting. But I don’t believe in lying to management. I don’t believe in placating management. I believe in asking management some difficult questions and then telling them the truth. These people get paid big bucks. They can handle the truth.
The questions I ask:
When you are transitioning to agile, you have some choices:
Oh, the option I didn’t mention: Determine what is wrong with your agile transition and fix it. Why can you not release product every two weeks? What is your “overhead?” Or “impediment?” Why can’t you release every week?
If you can’t release as a single team every two weeks, your not-releasing is not going to get better as a program. It can only get worse as you have more teams. Agile will make this transparent. Any program will make this transparent. Agile will make your problems transparent faster.What Agile Approach Should You Choose?
I write and consult to help you be more effective in a pragmatic way. That’s why I don’t follow a school of anything. I’m not religious about any agile way. I often mix and meld the agile approaches for my clients. They have found tremendous value in that.
If you are starting a transition to agile, first, ask yourselves, “Why do we want to transition to agile?” Agile is about the ability to respond to change. You get this ability by technical and management discipline. It requires both.
You don’t get it from just the technical teams delivering features. If management doesn’t do their part by creating product ownership, creating a reasonable work environment, and managing the project portfolio, the technical teams can’t deliver.
Practice with one small agile project first, before you move to a program. Become accustomed to delivering features every week. Become accustomed to evaluating the project portfolio based on value. Become accustomed to having a single product owner develop a roadmap for a product and a product backlog for that product. That’s difficult enough.
Once you understand what your organization’s issues are, and you can resolve them, now, you can move to a program. You will have more and different issues and risks. But, at least you won’t be starting your agile transition.Agile is About Feedback and the Ability to Change
If you transition to agile in some way, but you only get feedback from a product owner once a quarter, is that agile? I don’t see how it is. Maybe that’s not the intent of SAFe. But that’s how I’ve heard of some implementations of it. That’s how I read it. Maybe I just don’t understand it. It’s possible.
When I work with teams, I tell them, “We will start with two-week iterations.” They all groan and tell me the iteration is too short. And then we start to slice and dice their stories. I used to ask How Little Can You Do of the project managers about the requirements for the project. Now I ask it of the product owners and the technical team, “What are the acceptance criteria for this story? What does done mean? How little can we do and still add value?”
You are smart people. You can make anything work. I know that. But, at what human cost?
To me, SAFe looks like Theory X management. I’m a Theory Y person.Earn Trust and Extend Trust
Whether you are part of a feature team or management, you have to earn and extend trust if you are on your agile journey. On a feature team, your job is to deliver finished features. Period. If you are part of management, your job is to create an environment that allows the feature teams to flourish.
If you trust each other, management can ask for order-of-magnitude estimates, if necessary, and make project portfolio decisions based on value. More often, if the project portfolio team is doing their job, and the team is delivering, they don’t need the estimates. The management team learns to cancel/kill a project before they get emotionally hooked by sunk cost.Learn to Be Effective
Both the technical teams and the management teams need to learn new behaviors when transitioning to agile. From my reading, SAFe reinforces old behaviors. It postpones feedback and doesn’t help management learn to look for value instead of estimates. As I said, it looks to me as if it’s Theory X management.
Agile is Theory Y management. Tell people what you want. Provide them the resources to do it. Get out of their way. See what they’ve done. See if there is more value in the backlog, a short time later. If so, continue to fund the project/program.
If you want more details on project management and lifecycles and ways to think about projects and programs, see Manage It! Your Guide to Modern, Pragmatic Project Management.
I’m still working on getting the first release of Agile and Lean Program Management: Collaborating Across the Organization ready. “Fall” is my best estimate. Not early fall :-)
For an agile and lean approach project portfolio management see Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects.
Every so often, managers want to compare teams. You’ve heard this in several ways:
Comparing teams is not useful. There is no reason to do so. Each team is unique, composed of wonderfully unique individuals. What does matter is that the team is working well together, delivering product. That is the only thing that matters.
If the team delivers, without working well, the team is not sustainable over time. If the team does not deliver, even if they are harmonious, that is not sustainable over time. You need both. And, you cannot get both if teams are in competition with each other.
I was working as a manager in an organization several years ago, when one of my managers wanted to have a “friendly” competition, to see which team was “better” than another team.
“What outcome do you want from this competition?” I asked my boss.
“I want to know what team is better,” he said.
“Do you also want any shippable product?” I asked.
“Well, of course!” He looked at me as if I had three heads. “That’s the whole point of this exercise. I want shippable product and friendly competition.”
“But these people have to work together. And you are asking them to compete with each other instead of collaborating with each other. I am the program manager. How the heck is this supposed to work?” By this time, I’m standing up, leaning over his desk, in his face.
I’m angry. I’m not happy about this situation. I’ve just helped the teams understand how to do deliverable-based planning so that we have sync’d their deliverables. (This is before agile.) Now, my boss is about to undo everything I have done. Argh. (Read Manage It! Your Guide to Modern, Pragmatic Project Management to learn more about deliverable based planning.)
I sat down. I calmed down. I explained that I needed collaboration, not competition.
I still have all my hair.
This is why I wrote Management Myth 20: I Can Compare Teams (and Itās Valuable to Do So). Managers have good intentions. And, they don’t always realize the consequences ofĀ their intentions.