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:
- Develop trusting relationships with the people on the project team, and in their function.
- Provide coaching and mentoring opportunities for people.
- Provide communities of practice for the people.
- Remove obstacles for the people and team.
- Start and nurture the hiring effort whenever you need to hire new people.
- Help people with career development.
- Provide feedback to people, and help people learn how to provide feedback (meta-feedback).
- Provide coaching and meta-coaching when people want it.
- Help the organization understand its capacity and make decisions about the project portfolio.
- Help influence the rest of the organization with the agile culture.
Functional managers are champions for the team, and shepherds for the process. They are servant leaders.
Here’s what functional managers do not do:
- Have status conversations. If the team is agile, the team understands its status. If you need help seeing their board, that’s a problem the team needs to solve. If they need help seeing their status, they need to change their board or their process for updating each other.
- Move people on or off teams, once you or the team establishes itself.
- Ask people to do something the team has not committed to, or that the product owner has not added to the kanban board. That’s right. “Your” team doesn’t work for you; the team works for the product owner.
- Micromanage any part of the project work. Or, manage any part of the project work.
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.
January 29, 2015 01:28 PM
As I write the program management book, I am struck by how difficult it is to estimate large chunks of work.
In Essays on Estimation and Manage It!, I recommend several approaches to estimation, each of which include showing that there is no one absolute date for a project or a program.
What can you do? Here are some options:
- Plan to replan. Decide how much to invest in the project or program for now. See (as in demo) the project/program progress. Decide how much longer you want to invest in the project or program.
- Work to a target date. A target date works best if you work iteratively and incrementally. If you have internal releases often, you can see project/program progress and replan. (If you use a waterfall approach, you are not likely to meet the target with all the features you want and defects you don’t want. If you work iteratively and incrementally, you refine the plan as you approach the target. Notice I said refine the plan, not the estimate.
- Provide a 3-point estimate: possible, likely, and worst case. This is PERT estimation.
- Provide a percentage confidence with your estimate. You think you can release near a certain date. What is your percentage confidence in that date? This works best with replanning, so you can update your percentage confidence.
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.
When you see this roadmap, you can see how we have planned for an internal release each month.
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.
In the one-quarter view, you can see the Minimum Viable Products.
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:
- Are these stories too big to count? If so, any estimate you create will be wrong.
- Are we delivering useful work? If so, the organization will continue to invest.
- Are we working on the most valuable work, right now? What is valuable will change during the project/program. Sometimes, you realize this feature (set) is less useful than another. Sometimes you realize you’re done.
- Are we ready to stop? If we met the release criteria early, that’s great. If we are not ready to release, what more do we have to do?
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:
- How much would you like to invest in this project/program before we stop?
- How valuable is this project/program to you?
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.
January 21, 2015 01:37 PM
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.
January 19, 2015 06:01 PM