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!
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?
Is there room for functional managers, such as development and test managers, in agile organizations? Maybe. It depends on whether they take the role of an agile manager.
If you have organized as a feature teams-based organization, the functional managers (development, test, analysis, whatever) can take these responsibilities:
Functional managers are champions for the team, and shepherds for the process. They are servant leaders.
Here’s what functional managers do not do:
What does this mean? It means that the team members are leaders. Agile pushes responsibility into the teams, and away from traditional management. Agile requires leadership at all levels.
Agile challenges managers to recreate their jobs. An agile transformation requires managers work in an agile way, and work differently than before.
If you want to learn more about the role of leaders and managers in agile, join Gil Broza and me at The Influential Agile Leader, either in San Francisco or London this year. We still have an early bird price until mid-February. Don’t miss this opportunity to help your agile transition and your career.
As I write the program management book, I am struck by how difficult it is to estimate large chunks of work.
What can you do? Here are some options:
Each of these shows your estimation audience you have uncertainty. The larger the project or program, the more you want to show uncertainty.
If you are agile, you may not need to estimate at all. I have managed many projects and programs over the years. No one asked me for a cost or schedule estimate. I received targets. Sometimes, those targets were so optimistic, I had to do a gross estimate to explain why we could not meet that date.
However, I am not convinced anything more than a gross estimate is useful. I am convinced an agile roadmap, building incrementally, seeing progress, and deciding what to do next are good ideas.
With internal releases, everyone can see the project or program progress.
In addition, we have a quarterly external release. Now, your project or program might not be able to release to your customers every quarter. But, that should be a business decision, not a decision you make because you can’t release. If you are not agile, you might not be able to meet a quarterly release. But, I’m assuming you are agile.
You might need to replace MVPs with MIFS,Â Minimum Indispensable Feature Sets, especially at the beginning.
If you always make stories so small that you can count them, instead of estimate them, you will be close. You won’t spend time estimating instead of developing product, especially at the beginning.
You know the least about the risks and gotchas at the beginning of a project or program. You might not even know much about your MIFS or MVPs. However, if you can release something for customer consumption, you can get the feedback you need.
Feedback is what will tell you:
Here’s my experience with estimation. If you provide an estimate, managers won’t believe you. They pressure you to “do more with less,” or some such nonsense. They say things such as, “If we cut out testing, you can go faster, right?” (The answer to that question is, “NO. The less technical debt we have or create, the faster we can go.”)
However, you do need the planning of roadmaps and backlogs. If you don’t have a roadmap that shows people something like what they can expect when, they think you’re faking. You need to replan the roadmap, because what the teams deliver won’t be everything the product owner wanted. That’s okay. Getting feedback about what the teams can do early is great.
There are two questions you want to ask people who ask for estimates:
If you work on the most valuable project/program, why are you estimating it? You need to understand how much the organization wants to invest before you stop. If you’re not working on the most valuable project/program, you still want to know how much the organization wants to invest. Or, you need a target date. With a target date, you can release parts iteratively and incrementally until you meet the target.
This is risk management for estimation and replanning. Yes, I am a fan of #noestimates, because the smaller we make the chunks, the easier it is to see what to plan and replan.
We need planning and replanning. I am not convinced we need detailed estimation if we use iterative and incremental approaches.
I published a new Pragmatic Manager this past weekend. It’s called Discovering Your Leadership.
It has a pointer to the Influential Agile Leader event that Gil Broza and I are leading in San Francisco and then in London. You can still get early bird pricing, until Feb 15. Don’t miss this opportunity—we’re only leading it twice this year.
I have a new column posted at projectmanagement.com. It’s called Does Agile Apply to Your Project? (You might need a free registration.)
the group of people who turn out to be most accurate about predicting how long it will take to complete tasksâ€”and how likely they are to succeedâ€”are the clinically depressed. Optimists underestimate how difficult it will be to succeed. But that self-deception is precisely what makes them willing to take more risks and invest in a better future, while the pessimists slouch toward self-fulfilling failure.Â
Pessimistic people are more accurate with their estimation. Optimists underestimate. Their optimism allows them to take more risks and innovate. Which kind of person are you? (I’m both, in different circumstances.)
That got me thinking about why agile works.
Agile and lean (I’m using agile as shorthand for both) help us make progress in small chunks. That creates hope and optimism in the project team. When the project team demos or releases to other people, they trust the team and a become hopeful and optimistic.
We know from The Progress Principle: Using Small Wins to Ignite Joy, Engagement, and Creativity at Work that the more we make progress with small wins, the better we feel and the more likely we are to make more progress. That leads to hope and optimism.
Is this why agile works? Because we can make progress daily?
It’s not the only reason. We also need feedback. When we provide demos to other people, as often as possible, we build trust. With trust comes the possibility of better connection and feedback.
We get feature-itis because we’re no longer in requirements hell. Other people can see that a project team can deliver. That leads to optimism and hope in the organization. (I’m differentiating the two, because they are different. See my review of Seligman’s book.) With hope, people can rise to many occasions. Without hope? I bet you’ve been there on a project. It isn’t pretty.
Agile is not for everyone. Agile approaches? Yes. Completing small chunks of work and showing it to other people? You can do that with deliverable-based planning, building incrementally, and iterative approaches to replanning. If you want a name for that approach, it’s called staged delivery or design to schedule.
If you’re doing agile well, you’re delivering new small features into the code base every day or every other day. That helps you feel as if you’re making progress. When you feel as if you’re making progress, you can be more optimistic or hopeful. That helps you see new possibilities.
I would rather work in a hopeful way, making progress on a project, than feel as if I’m dragging.Â What about you?
So, agile might increase optimism, which allows us to make more progress and innovate. Agile done well brings joy to our work.
People are always asking my why agile works, or to prove it works. I can’t prove anything.
I have said that in my experience, when people work in an agile way, they are more productive and more effective. NowÂ I wonder if this is because they are optimistic and hopeful about their work.
Years ago,Â I was the expert for twoÂ specific products in a small development organization. When it came time for my manager toÂ divide up the work, I always got those productsÂ to add features to, or maintain. That was fine for a while, until I got bored. I went to my boss with a request for different work.
“Who will do the work if you don’t?” My boss was concerned.
“Steve or Dave will. They’re good. They can take over for me.” I knew my colleagues. They could do the work.
“But, they’ll have to learn what you do.”
“I know. I can take a few days to explain, if you want. I don’t think it will take a few days to explain. They’re smart. I’m still available if they have questions.”
“I don’t know. You’re indispensable where you are.”
I faced my boss and stood up. “No one is indispensable. And, if I am, you should replace me on those systems anyway. What are you going to do if I leave?”
My boss paled, and asked, “Are you planning to leave?”
“I don’t know. I’m bored. I want new work. I told you that. I don’t see why I can’t have new work. You need developers on these projects.” I named three of them. “Why do I have to stay doing work on the old stuff when I want to do new things. I don’t see why I should. Just because I’ve been doing it for a year is no reason to pigeon-hole me. No. I want new work. I’m not indispensable. You can hire someone and I can train that person if you want.”
My boss reluctantly agreed to let me stop working on the old systems and work on the new projects. I was no longer indispensable.
The problem with being an indispensable employee is that your options are limited. Your boss wants you to keep doing the same thing you’ve always done. Maybe you want that, too for now. The problem is that one day, you realize no one needs what you do. You have become such an expert that you are quite dispensable. You have the same year of experience for several years.
Instead of being indispensable, consider how to help other people learn your work. What do you want to learn next? You need to plan your career development.
What do you do if you’re a manager, and you have indispensable employees? “Fire” them.
I’m serious. When you have people who are indispensable, they are experts. They create bottlenecks and a cost of delay. If you need flexibility in your organization, you need people who know more than one area. You need teams who are adaptable and can learn quickly. A narrow expert is not what you need.
When I say “fire” people, I mean don’t let them work on their area of expertise alone. Create a transition plan and help the expert discover new skills.
Why should you do this? Because if not, people and projects across the organization decide they need that person. Sometimes with quite bad results.
This month’s management myth is based on a true story. The organization wanted an expert to change teams and move. All because of his expertise. That’s nuts. Go readÂ Management Myth 36: You Have an Indispensable Employee.
I have posted my most recent Pragmatic Manager newsletter on my site. Read Johanna’s 2014 New Years Tips.
I have a question for you. I send the newsletter to my subscribers the last week of the year. I call them “this-year” tips. Some people ask me if I meanÂ “the next year”. I don’t because it’s this year. Is this confusing? Should I rename my end-of-the-year tips? Thanks for your feedback.
A recent coaching clientÂ was concerned about the progress his team was making—or really, the lack of progress his team was making. We spoke about the obstacles he had noticed.
“The team doesn’t have time to write automated tests. As soon as they finishÂ developing or testing a feature, peopleÂ get yanked to another project.”
“Are people, developers and testers, working together on features?” I wanted to know.
“No, first a developer works on a feature for a few days, then a tester takes it. We don’t have enough testers to pair them with developers. What would a tester do for three or four days, while a developer worked on a story?”
“So, to your managers, it looks as if the testers are hanging around, waiting on developers, right?” I wanted to make sure I understood at least one of his problems.
“Yes, that’s exactly the problem! But the testers aren’t hanging around. They’re still working on test automation for stories we said were done. We have more technical debt than ever.” He actually moaned.
“Would you like some ideas? It sounds as if you are out of ideas here.” I checked with him.
“Yes, I would!” He sounded grateful.
These were the ideas I suggested:
I asked him if he could do these things for the team. He said he was sure he could. I’d been coaching him for a while. He was pretty sure he could coach his team.
Now I asked him the big question. Could he influence the project portfolio work at the level above him? His managers were too involved in who was doing what on the teams, and were not ranking the projects in the project portfolio. He needed to influence the managers to flow work through the team, and not move people like chess pieces. Could he do that?
He and I started to workÂ through how and who he could influence.
Technical leads, first- and middle-managers may find influence more challenging. You have to build rapport and have a relationship before you influence people. Had he done that yet? No, not yet.
You often need to serve your organization at several levels. It doesn’t matter if you are a technical leader, or someone with manager in your title. Rarely can you limit your problem-solving to just your team.
If theseÂ challenges soundÂ like yours, you should consider joining Gil Broza and me in the Influential Agile Leader in either San Francisco or London next year. It’s an experiential event, where you bring your concerns. We teach a little, and then help you with guided practice. It’s a way to build your servant leadership and learn how to coach up, down, and sideways. It’s a way to learn who and how to influence. We have more sessions, so you can bring your issues and address them, with us and the other participants.
Our early bird pricing expires Dec 31, 2014. Please join us atÂ Influential Agile Leader.
Andy Hunt, the Pragmatic Bookshelf publisher, just sent me an email telling me that Manage Your Project Portfolio is featured inÂ La RepĂşblica, Columbia’s “first and most important business newspaper.” That’s because getabstract liked it!Â Â
And, I have to say, I’m still pretty excited.
If your organization can’t decide which projects come first, second, third, whatever, or which features come first, second, third, whatever, you should get Manage Your Project Portfolio.
I once worked in an organization where the senior managers thought they should motivate us, the team members. They decided to have a team competition, complete with prizes.
I was working on a difficult software problem with a colleague on another team. We both needed to jointly design our pieces of the product to make the entire product work.
After management announced the competition, he didn’t want to work with me. Why? There was prize money, worth hundreds of dollars to each person. He had a mortgage and three kids. That money made a big difference to him. I was still single. I would have stuck that money into either my savings or retirement fund, after buying something nice for myself.
Management motivated us, alright. But not to collaborate. They motivated us to stop working together. They motivated us to compete.
Our progress stopped.
My boss wanted to know what happened. I explained. I couldn’t fault my colleague. He wanted the money. It made a big difference for him. I would have appreciated the money, but not nearly as much as he would have. (Later, when I was paying for childcare, I understood how much of a difference that money made.)
I then had this conversation with my boss, ranting and raving the entire time:
“Look, do you want the best product or the best competition?”
“You can’t have both. You can have a great product or you can have a great competition. Choose. Because once you put money on the table, where only one team gets the money, we won’t collaborate anymore.”
My boss got that “aha” look on his face. “Hold that thought,” he said.
The next day, management changed the competition. Now, it was about the teams who worked together to create the best product, not the one team who had the best idea. Still not so good, because all the teams on the program needed to collaborate. But better.
When I had my one-on-one with my boss, I explained that all the teams needed to collaborate. Were they really going to pay everyone a bonus?
My boss paled. They had not thought this through. “I’d better make sure we have the funds, right?”
People don’t work just for money. You need to pay people a reasonable salary. Remember what Dan Pink says in Drive: The Surprising Truth About What Motivates Us. People work for autonomy, mastery, and purpose. If you exchange the social contract of working for autonomy, mastery, and purpose for money, you’d better pay enough money. You also better repeat that money the next time. And, the next time. And, the next time.
That’s the topic of this month’s management myth:Â Management Myth 35: Friendly Competition Is Constructive.
Software product development is a team activity, full of learning. As soon as you make it a competition, you lose on the teamwork. You lose the learning. Nobody wins. There is no such thing as “friendly” competition.
Instead, if you go for collaboration, you can win.
I’m writing part of the program management book, talking about how you need to keep everything small to maintain momentum. Sometimes, to keep your work small, teams move from iterations to flow.
Here are times when you might consider moving from iteration to flow:
This came home to me when I was coaching a program manager working on a geographically distributed program in 2009. One of the feature teams was responsible for the database that “fed” all the other feature teams. They had their own features, but the access and what the database could do was centralized in one database team. That team tried to work in iterations. They had small, one- or two-day stories. They did a great job meeting their iteration commitments. And, they always felt as if they were behind.
Why? Because they had requests backed up. The rank of the requests into that team changed faster than the iteration duration.
When they changed to flow, they were able to respond to requests for the different reports, access, whatever the database needed to do much faster. They were no longer a bottleneck on the program. Of course, they used continuous integration for each feature. Every day, or every other day, they updated the access into the database, or what the database was capable of doing.
The entire program regained momentum.
When you work in flow, you have a board with a fixed set of Ready items (the team’s backlog), and the team always works on the top-ranked item first. Depending on the work in progress limits, the team might take more than one item off the Ready column at a time.
The Product Owner has the capability to change any of the items in the Ready column at any time. If the item is large, the team will spend more time working on that item. It is in the Product Owner’s and the team’s interest to learn how to make small stories. That way, work moves across the board fast.
If you use a board something like this, combined with an agile roadmap, the team still has the big picture of what the product looks like. Many of us like to know what the big picture is. And, we see from the board, what we are working on in the small. However, we don’t need to do iteration planning. We take the next item off the top of the Ready list.
There is no One Right Answer as to whether you should move from iteration to flow. It depends on your circumstances. Your Product Owner needs to write stories that are small enough that the team can complete them and move on to another story. Agile is about the ability to change, right? If the team is stuck on a too-large story, it’s just as bad as being stuck in an iteration, waiting for the iteration to end.
However, if you discover, especially if you are a feature team working in a program, that you need to change what you do, or the order of what you do more often than your iterations allow, consider moving to flow. You may decide that iterations are too confining for what you need.
In self-organizing teams, teams remove their own obstacles. It’s a good idea. It can be difficult in practice.
In Scrum, the Scrum Master is supposed to facilitate removing the team’s obstacles that the team can’t remove. It’s a good idea. It can be difficult in practice.
And, what if you aren’t doing Scrum, or you’re transitioning to agile and you don’t yet have a self-organizing team? Maybe you have an agile project manager. Maybe you have a team facilitator. Not every team needs a titled manager-type, you know. (Even I don’t think that, and I come from project management.)
Maybe the team bumps up against an obstacle they can’t remove, even if they try. Why? Because the obstacles the team can’t remove tend to fall in these categories:
Oh boy. Someone who either used to be technical or used to be a first-line manager is supposed to talk to a VP of Support or Sales or the CIO or the CTO or “the Founder of the Company” and ask for help removing an impediment. Unless the entire organization is already agile, can you see that this is a problem or a potential problem?
Chances are good that during an organization’s transition to agile, the team’s facilitator (regardless of the title) will need help from a more senior manager to remove obstacles. Not for the team. For the rest of the organization.
Now, I would love it if the person who is supposed to remove obstacles was that designated facilitator (Scrum Master, agile project manager, whomever). And, that designated facilitator had the personal power to do it all by him or herself. But, I’m a realist. In my clients, that doesn’t happen without management support.
Is it a problem if a manager removes obstacles?
I don’t think so, as long as the manager supports the team, and doesn’t prevent the team from solving its own problems.
Here are examples I would expect the team to solve on its own:
Here are obstacles mid-level managers or more senior managers might help with:
This is a form of management as servant leadership, where the manager serves the team.
Do you see how certain problems are inside-the-team problems and the team can solve them? Other problems are not inside-the-team problems, and are part of the organization’s system. The organization needs to decide, “How committed to agile are we?” and address these issues.
We talk a lot in agile about generalizing specialists. Scott Ambler has a terrific essay on what a generalizing specialist is:
(From Scott Ambler’s essay, http://www.agilemodeling.com/essays/generalizingSpecialists.htm)
How do you hire one of these mythical people?
First, they are not mythical. They are real. Second, you do a job analysis, just as you would for any job. Third, you would look at how they have acquired skills throughout their careers.
What does this mean for the hiring manager and/or recruiter?
Remember, you want generalizing specialists. True specialists introduce a cost of delay into your projects. They end up with a queue of work and they introduce a delay, or they multitask.