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!
My column is up on projectmanagement.com. It’s called Is Agile Working for Your Project?
I hope you enjoy it.
I have a new article up on agileconnection.com called The Case for #NoEstimates.
The idea is to produce value instead of spending time estimating. We have a vigorous “debate” going on in the comments. I have client work today, so I will be slow to answer comments. I will answer as soon as I have time to compose thoughtful replies!
This column is the follow-on to How Do Your Estimates Provide Value?
If you would like to learn to estimate better or recover from “incorrect” estimates (an oxymoron if I ever heard one), see Predicting the Unpredictable. (All estimates are guesses. If they are ever correct, it’s because we got lucky.)
I have an article up on agileconnection.com. It’s called How Do Your Estimates Provide Value?
I’ve said before thatÂ We Need Planning; Do We Need Estimation?Â Sometimes we need estimates. Sometimes we don’t. That’s why I wrote Predicting the Unpredictable: Pragmatic Approaches for Estimating Cost or Schedule.
I’m not judging your estimates. I want you to consider how you use estimates.
BTW, if you have an article you would like to write for agileconnection.com, email it to me. I would love to provide you a place for your agile writing.
If you are not on my Pragmatic Manager email list, you might not know about these opportunities to explore several topics with me this month:
AnÂ Estimation hangout with Marcus Blankenship this Friday, April 10, 2:30pm EDT. If you have questions, please email me or Marcus. See the Do You Have Questions About Estimation post. Think of this hangout as a clinic, where I can take your questions about estimation and help you address your concerns.
In the Kitchener-Waterloo area April 29&30, I’m doing two workshops that promise to be quite fun as well as educational:
To see the descriptions, see the KWSQA site.
You do not have to be a manager to participate in either of these workshops. You do need to be inquisitive and willing to try new things. I believe there Â is only room for two people for the leadership workshop. I think there is room for five people in the project portfolio workshop. Please do sign up now.
I am doing a google hangout with Marcus Blankenship on April 10. We’ll be talking about estimation and my new book, Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.
The book is about ways you can estimate and explain your estimates to the people who want to know. It also has a number of suggestions for when your estimates are inaccurate. (What a surprise!)
Marcus and I are doing a google hangout, April 10, 2015. There’s only room for 15 people on the hangout live. Â If you want me to answer your question, go ahead and send your question in advance by email. Send your questions to marcus at marcusblankenship dot com. Yes, you can send your questions to me, and I will forward to Marcus.
The details youâ€™ll need to attend:
Youtube live streaming link: http://www.youtube.com/watch?v=82IXhj4oI0U
Time & Date: April 10th, 2015 @ 11:30am Pacific, 2:30 Eastern.
Hope you join us!
Some of my coaching clients have way more to do than they can manage. Some of my project portfolio clients are struggling with how to say no.
In many of my transitioning to agile clients, the managers want to know when the project will be done. Or, they want to know how much the project will cost. (I have a new book about this, Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule.)
Managers ask for estimates because they want to know something about their ability to recognize revenue this year. How many projects can they release? What is the projected effect on revenue; customer acquisition and retention; and on service revenue (training, support, all that kind of service). We pay managers big bucks so they can project out for “a while” and plan for the business.
You need to know this in your life, too. If you are an employee, you know approximately how much money you will make in a year. You might make more if you get a bonus. You might make less if you get laid off. But, you have an idea, which allows you to budget for mortgages, vacations, and kid’s braces.
Remember, in waterfall,Â there was no benefit until the end of the project. You couldn’t realize any benefit from a project until it was complete: not revenue, not capitalization, not any effect on what customers saw. Nothing.
When you use agile, you have options if you can release early.Â Remember the potential for release frequency?
If you are agile, you donâ€™t need to estimate a lot to tell them when they can first receive value from your work. You can capitalize software early. Your customers can see the benefits early. You might be able to acquire more customers early.
Agile changes the benefits equation for projects.
Agile is about the ability to change. We see this at the team level clearly. When the team finishes a feature, the team is ready for the next feature. It doesn’t matter if you work in flow or timeboxes, you can change the features either for the next feature (flow) or at the next timebox. You can change what the team does.
Agile is most successful when teams finish features every day (or more often). The faster you finish a feature, the faster the team gets feedback on the feature. The more flexibility the product owners has to update/change the backlog for the team (either for flow or the next timebox). The teams do have to complete their work on a feature in a reasonable amount of time. If your cycle time gets too high, no one sees the flow of features. If you don’t get to done at the end of the iteration, you don’t get the benefit of agile. Teams need to learn how to get to done quickly on small features, so they can demo and get feedback on their progress.
What does this fast delivery/fast feedback cycle do for senior managers?
It allows senior managers to change their questions. Instead of “When will this be done?” or “How much will it cost?” senior managers can ask, “When will I see the first bit of value? Can we turn that value into revenue? When can we capitalize the work?”
Those questions change the way teams and senior management work together.
When teams do agile/lean, and they have a constant flow of features, managers don’t need “assurances” or “commitments to estimates” from the teams. Instead, the team estimates a much smaller chunk of work–time to first delivery value.
You might not know precisely when you can deliver that first value. But, as soon as the team works togetherÂ if they understand agile/lean, they can create a reasonable estimate. They can update that estimate if necessary.
What else can teams do?
With agile, you don’t have to set the strategy for a year, fund the projects, and expect that the projects will complete within that year. A year is a long time in almost every market. Managers might want the ability to change their strategy, and still get to a first “delivery of value” date.
Our metrics need to change. Cost to release or time to release is inadequate. They are inadequate because we can change the backlog at any time.
Instead, consider these metrics:
I have other measurement suggestions for programs in Organizing An Agile Program, Part 5: Measurements That Might Mean Something to a Program.
It’s not about #noestimates. It’s about which estimates your managers need. Managers have a fiduciary responsibility to the organization. You have the responsibility to release often, at least internally. The more often you release, the fewer time/cost estimates your managers need. The more your managers can take advantage of capitalizing software and what the software can do for the organization and the customers.
Your managers need estimates. And, they need to change the estimates they request. It’s all about your organization’s transition to agile.
Every time I work with a client or teach a workshop, people want more ways to visualize their project portfolios. Here are some ideas:
Here is a kanban view of the project portfolio with a backlog:
And a kanban view of the project portfolio with an “Unstaffed Work” line, so it’s clear:
If you haven’t readÂ Visualizing All the Work in Your Project Portfolio, you should. It has some other options, too.
I have yet more options in Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects.
I’ve been talking with clients recently about their managers’ and HR’s transition to agile. I hear this common question: “How do we manage performance of the people on our agile teams?”
Now, what does this mean for raises?
I like to separate the raise from the feedback. People need feedback all the time, not just once a year. That’s why I like weekly or biweekly one-on-ones. Feedback isn’t just from the manager to the employee; it’s two-way feedback. If people have trouble working in the current environment, the managers might have a better chance to change it than an employee who is not a manager.
What about merit raises? This is tricky. So many managers and HR people continue to think one person is a star. No, on well-functioning agile teams, the team is the star—not individuals. You have options:
Managers have to not get in the way when it comes to “performance management.” The people on the team are adult humans. They somehow muddle through the rest of their lives, successfully providing and receiving feedback. They know the worth of things outside work. It’s just inside work that we keep salary secret.
It might not fit for you to have open-book salaries. On the other hand, how much do your managers and HR do that interferes with a team? You have to be careful about this.
If you reward individuals and ask people to work together as a team, how long do you think they will work together as a team? I don’t know the answer to that question.
Long ago, my managers asked me to be a “team player.” Â One guy got a huge raise—and I didn’t, although I had saved his tush several times—I stopped working as a “team” member. I got my big raise the following year. (Year!) ThisÂ incongruent approach is why people leave organizations—when the stated way “we work here” is not congruent with the stated goals: agile and self-organizing teams.
What do you want? Managers and HR to manage people? Or, to lead people using servant leadership, and let the teams solve their problems and manage their own performance?
If teams don’t know how to improve, that’s one thing. But, I bet your teams do know how to improve. You don’t have to manage their performance. You need to create an environment in which people can do their best work—that’s the manager’s job and the secret to “managing performance.”
If you read least week’s post about agile misconceptions, There is One Right Approach, you will like this one. This week’s article isÂ Agile Misconceptions: Agile is Just a Project Management Framework.
If you would like more common-sense approaches to agile, sign up for the Influential Agile Leader. Weâ€™re leading it in San Francisco and London this year. We offer discounts for multiple people from your organization.Â Sign up now.
I have finished the content for Essays on Estimation. But, I need a new title. The book is more than loosely coupled essays. It reads like a real book, with progression and everything.
I have a number of ideas. They are (in no particular order):
Do you like any of these ideas? Have a better idea? I would like a title that explains what’s in the book.
I numbered these so you could respond easily in the comments with the number, if you like. Or, you can type out the entire title or a new title. I am open to ideas.
Thank you in advance.
I have an article up on agileconnection.com calledÂ Common Misconceptions about Agile: There Is Only One Approach.
If you read my Design Your Agile Project series, you know I am a fan of determining what approach works when for your organization or project.
Please leave comments over there. Thanks!
If you are a leader for your agile efforts in your organization, you need to consider participating in The Influential Agile Leader.Â If you are working on how to transition to agile, how to talk about agile, how to help your peers, managers, or teams, you want to participate.
Gil Broza and I designed it to be experiential and interactive. We’re leading the workshop in San Francisco, Mar 31-Apr 1. We’ll be in London April 14-15.
The early bird pricing ends Feb 20.
People who participate see great results, especially when they bring peers/managers from their organization. Sign up now.
My most recent Pragmatic Manager , Creating an Environment of Leadership is up.
Gil Broza and I are offering the Influential Agile Leader twice this year: once in San Francisco, and once in London. The early bird deadline for registration is Feb 15.
If you are trying to transition to agile and you’re having more challenges than you expected, you owe it to yourself to participate.
If you have questions, contact me. I’m happy to answer them.
Laurent Bossavit, in The Leprechauns of Software Engineering, shows us how that assumption is wrong. (It was an assumption that some people, including me, assumed was real.)
This is a Gaussian (normal) distribution. It’s what we expect. But, it’s almost never right. As Laurent says,
“Many projects stay in 90% done for a long time.”
What curve do our estimates followÂ if they don’t follow a Gaussian distribution?
Troy Magennis, in “The Economic Impact of Software Development Process Choice – Cycle Time Analysis and Monte Carlo Simulation Results,” suggests we should look at the Power-Law (Weibull) distribution.
What this distribution says with respect to estimation is this: We areÂ good at estimating small things. We get much worse with our estimation quickly, and for the long tail Â (larger and larger chunks of work), we are quite bad.
Why? Because creating software is innovation.Â Building software is about learning. We better our learning as we proceed, assuming we finish features.
We rarely, if ever, do the same thing again. We can’t apply precise estimation approaches to something we don’t know.
You should read Troy’s paperÂ because it’s fascinating. It’s well-written, so don’t worry about not being able to understand it. You will understand it. It’s only 10 pages long.
The question is this: What effect does understanding an estimation model have on our estimates?
If we know that the normal distribution is wrong, then we won’t apply it. Right, why would you do something you know to be wrong? You would not estimate large chunks and expect to have a +/- 10% estimate. It doesn’t make sense to do that.
But what can we do? On the printed paper, what the proceedings will show p. 5061, Troy has a table that is telling. In it, he says that if you have large unique work items or you have large WIP, you will have poor predictability. (He has suggestions for what to do forÂ your process.)
My suggestions for your estimation:
What should you do when people ask you for estimates? What kind of requirements do you have? If you have large requirements, follow my advice and use the percentage confidence, as inÂ We Need Planning; Do We Need Estimation?Â Read the estimation series or get Essays on Estimation.
You can predict a little for estimates. You can better your prediction. And, you may have to predict a large effort. In that case, it helps to know what distribution model might reflect your estimate.
Many organizations create teams by their architectural part: front end, back end, middleware. That may have worked back in the waterfall days. It doesn’t work well when you want to implement by feature. (For better images, seeÂ Managing the Stream of Features in an Agile Program.)
Pierce Wetter wrote this great article on LinkedIn, There is no “front end” or “back end.”Â Notice how he says, referring to the yin/yang picture,
Your product isn’t just the white part or the black part above. It’s the whole circle.
That has implications for how you structure your teams.
If you have front end, back end, or middleware teams, you lose the holistic way of looking at features. You can’t produce features—you produce components, parts of features that work across the architecture. Even if everyone does their job perfectly, they still have to knit those pieces together to create features. Too often, the testers find the problems that prevent features.
Instead, you want a product development team, a feature team. That team has someone from the back end, someone from the front end, someone from middleware, and a tester, at minimum. Your team may have more people, but you need those people to be able to create a feature.
You might call these teams product development teams, because they produce product chunks. You can call them feature teams because they can create features.
Whatever you call them, make sure—regardless of your life cycle—that you have feature teams. You can have feature teams in any approach: serial, iterative, incremental, or agile. What differentiates these teams from functional or component teams is that feature teams can produce features.
Features are what you offer to your customers. Doesn’t it make sense that you have teams that create features?