Introduction to Planning Poker

Many of the techniques of Agile development combine together to provide more than the sum of their parts. One technique that definitely fits this description is the Planning Poker method for doing estimation. In part 1 of this post, I will quickly describe the mechanics of Planning Poker. I will then go on to describe how user stories, whole teams, story point estimation, and velocity all work to multiply the value of Planning Poker and how Planning Poker also reinforces the use of and value of the other practices. If you are already familiar with Planning Poker, you may want to skip ahead to "The Five Essential Ingredients of Great Agile Estimation".

Planning Poker is an estimation technique first described by James Grenning in 2002 in a paper by the same name [pdf]. When I first heard about Planning Poker, I couldn’t help but chuckle. It seemed a bit silly to mix software development and poker. After reading Mike Cohn’s excellent book “Agile Estimating and Planning” I had a good grasp of the mechanics of Planning Poker, but it felt like just a variant of the Delphi method and thus nothing new.

About a year ago we had Kenny Rubin come in to do some Scrum training for us. That was just the shot in the arm that we needed to supercharge Agile adoption at AccuRev. If you are looking for an Agile trainer, I highly recommend Kenny Rubin. It was based on Kenny’s explanation and recommendation that we decided to try Planning Poker on a real project. The results were terrific and after a single session we were hooked. Planning Poker is now a standard part of our Agile process.

The Basics
In order to play Planning Poker, each participant will need a deck of Planning Poker cards. These are easy to obtain, just Google for “Planning Poker cards” or make your own. You will need the following cards: ½, 1, 2, 3, 5, 8, 13, 20 and a card that indicates “I’ve had enough.” The numbers on the cards represent estimates. You can use story points, ideal days, or some other measure, but in this point I am assuming (and advocating) story points. Typical decks contain cards for much larger numbers than 20, but I think you’ll find that 20 and higher are rarely used once you’ve been using Planning Poker for a year or two.

The whole team gets together for a set amount of time to do story estimation. An hour is usually a good amount of time, but this is completely up to you. When I say “the whole team” I am assuming that you are using small cross-functional teams of 5-9 people (see later parts that discuss the use of whole teams).

Estimation is done on a story-by-story basis in the same order as the backlog, starting with the first story that needs estimating. Somebody reads and describes the story. This is often the product owner, but could be anybody. Some teams do story point estimation without the product owner and just skip stories which they are unable to do without the product owner’s involvement. After the story has been read, participants discuss the story for a bit and then decide on an estimate by picking one of their cards and laying it face down in front of themselves. Once everybody is ready, all of the estimates are shown. If the estimates are all the same, you are done.

Usually, some of the estimates are particularly low or particularly high. A low estimate can indicate that the estimator left something out, or possibly that they know a way to reuse existing work or have some other good information that other folks weren’t aware of. A high estimate may indicate many things, but most commonly it means that the estimator is thinking of something that other folks may not be aware of. For instance, somebody may point out that there is no test framework or tooling for a particular technology and that to adequately test the story the team will need to do a lot of setup work.

In any case, after a round of discussion, everybody chooses a new estimate. This is repeated until the team comes to consensus on the estimate. The estimate is given to the story and then you move on to the next story. You end when you hit the end of the meeting time, you run out of stories to estimate, or somebody plays the “I’ve had enough” card.

The Benefits

One of the biggest benefits of Planning Poker is the sense of team that it creates. The whole team is participating in the estimation. This creates a greater sense of team ownership and team responsibility for each story. Another major benefit of Planning Poker is that you leverage the collective wisdom of the whole team. However, this really only works well when you are using whole teams in the Agile sense of the term.



Next: The Five Essential Ingredients of Great Agile Estimation

One Piece Flow -- Transitioning from Scrum to Kanban Part II

If you have been doing Scrum for a while, and doing it well, it is 99% certain that you are frequently practicing something called “one piece flow”. One piece flow is a concept from Lean and is the key to succeeding with Scrum. Doing it well also happens to be one of the requirements for successfully transitioning from Scrum to Kanban.

There are four main concepts in “one piece flow.” Each story is done as if it was the only thing in the release, each aspect of developing a user story happens in rapid succession, there is as much done in parallel as possible, and each team member focuses on a single user story at a time. The result of one piece flow is that the time between when the team first starts working on a user story and when they can ship it fully developed, tested, and documented is very short. The timeframe is generally on the order of a week at most and usually days.

In one piece flow, when development starts on a story, QA should be creating test cases for that story (story testing) at the same time. When development is done, QA should then automate the test cases and make sure they all pass. At the same time, the user documentation is written. One last step that must be completed prior to considering the story done is that all of the artifacts connected to that story such as source code changes, documentation updates, new test cases, etc must be integrated into the source code mainline as part of continuous integration.

In the following diagram, there are 20 stories done over the course of three iterations. There are three developers on the team and each takes on one story at a time. In the diagram, the whole team is doing one piece flow well and you can see how the specifying (S), designing (D), coding (C), writing of tests (W), integrating (I), and testing (T) is evenly spread out but also clumped into stories.

So, from the perspective of a story, it is started, and completely finished in a short period of time. QA should not be waiting until all stories are done. Conversely, developers should not have lots of stories in progress that all finish together which keeps QA from getting involved.

You will know that you are succeeding at one piece flow when stories are being started and then are completely ready to go on an individual basis within days with all documentation written and all unit and story tests written, automated, and passing.

Once every QA person is actively engaged in a story that is part of an iteration, you are “in the flow.” Everybody is now flowing smoothly from story to story. Unfortunately, Scrum has a bad habit of disrupting one piece flow on a regular basis. As soon as one of the developers finishes their work for the last story assigned to them for the iteration you are no longer “in the flow.”

For more about how Scrum disrupts one piece flow, read about Bumping Into Scrum’s Iteration Boundaries.

Next: Scrum and Kanban -- Like Chocolate and Peanut Butter

Transitioning From Scrum to Kanban, Part 1 of 3

Bumping Into Scrum’s Boundaries
Scrum is the most popular Agile process in use today. But if you have been doing Scrum for a while, you know (or will soon experience) that it has some structural problems. Many of Scrum’s activities are tightly coupled to the cadence of the iterations but have a natural tendency towards their own cadences. In order for a story to be done-done-done, all of the work to make sure that it is done-done-done must be done within the iteration. A prerequisite of doing that work is that the code must be complete. That causes problems.

At the beginning of an iteration, there are no stories for testers to be testing until the developers get the first stories finished. At the end of an iteration, while the story validation work is being done on the last stories, the developers (and some of the testers) have nothing to do. A common response to this is that “there is always something to do.” Obviously there is always something to do, but that’s not the point. A key point of Agile is to focus on the highest value work. By definition, the highest value work is whatever is next in the backlog and not anything else. So, if you are doing something other than work required to move that iteration’s stories from todo to done you are working on the wrong things. One approach is to have the developers start on the next items in the backlog, but now you are moving outside the framework of Scrum.

Another problem is that the last stories rarely all transition neatly to done right at the end of the iteration. You may have some stories in progress at the end of the iteration which were hoped to be finished by the end of the iteration. For these folks, there is pressure to fit the work into the time remaining. Other folks may finish up early and not have any stories left to work on. While it is true that the team should be working and thinking as a team and helping each other out, it isn’t always possible to have two people work on the same story.

Just What the Doctor Ordered
There’s a commonly prescribed remedy for all of this: change the iteration length. Sometimes the recommendation is to make it longer, sometimes the recommendation is to make it shorter. In my experience, neither of these recommendations works very well. The reason is that the size of the stories that you work on tends to vary over time. The smaller, the better of course, but some stories are just naturally larger than others. No matter what you do with the iteration length, all you are really doing is changing the size of the problem, you aren’t really removing it.

The Source of the Friction
There are two simple reasons for this friction. It isn’t any easier to predict the future using Scrum. Software development is a creative endeavor. It is unpredictable. There is no way to get stories to all end smoothly at the end of the iteration, regardless of the iteration length or how often it is varied. The structure of the work itself just makes it worse.

Within each story there are two kinds of work: work that is mostly done during the first half of the story and work that is mostly done at the end of the story. The end work depends on the beginning work. As a result, it is impossible to “get the air out of the pipes.” It will always be there. This is illustrated in the following diagram.


The diagram shows two iterations of work split into three "swim lanes." I've artificially put one developer and one QA person into each swim lane to simplify the explanation. The numbers in each swim lane correspond to individual stories, the green areas represent developers and the yellow areas represent testers. The structure of the work means that there will always be areas that are either empty or filled with “other work.” You may have heard that it is good to have slack time, and I agree. However, I believe it is better for slack time to be under the control of the people in the system, not as the unpredictable result of a side-effect inherent in the process.

Long Live Scrum!
So where am I headed with this? Am I anti-Scrum? Am I about to describe a way to fix these problems with Scrum? Neither. I don’t believe these problems can be solved within Scrum. I do think that Scrum can be improved, see “Applying the Decoupling Principle to Scrum,” but I see the real solution as transitioning to Kanban. However, I also believe that it is better to do Scrum for a year or two first in order to build up the discipline of doing One Piece Flow that is necessary for succeeding with Kanban.

Next: One Piece Flow -- Transitioning from Scrum to Kanban Part II

Poll - Short Iterations, The Benefits

Short iterations are the practice of breaking up a release into 1-4 week development cycles that each produce a shippable increment of work. Some of the benefits of short iterations include working software that you can show to people in order to get their feedback and having nothing in progress at the end of the iteration so you can change your plans to take into account market changes, feedback from customers, or information you discovered while implementing that iteration. Also, all of the tests for the functionality implemented during the iteration have been written and run and you have a well known starting point for the next iteration.

There are some assumptions hiding in this practice. It assumes that you believe that incremental design is possible and that you believe that any refactoring you have to do in subsequent iterations is worth the benefits as described above.

So, if you were starting a company with your own hard-earned cash, would you use short iterations or wouldn't you?



Next: Poll - Whole Teams, The Benefits

Poll - Product Backlog, The Benefits

A product backlog is a list of high-level product requirements (or user stories), prioritized by business value (typically determined by a product manager or product owner). It contains entries for any and all work that is performed, including bug fixes. As new requirements are gathered or submitted, they are inserted into the backlog at the position that best represents their business value with respect to requirements that have already been entered. As requirements are met, they are removed from the product backlog.

A backlog gives a clear context to discussions of priority. Anybody can go and look at the backlog to see the position of something they have a stake in. If it is lower than they think it should be, they can examine the backlog to see what is higher in order to help frame a discussion around either moving it higher or moving other things lower.

So, if you were starting a software company with your own hard-earned cash, would you use a product backlog or wouldn't you?



Next: Poll - Your Preferred Methodology

Poll - User Stories, The Benefits

User stories are a description of what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome.

User stories are different than requirements. When using requirements, it is likely that the developer implementing the requirement will be presented with an implementation task or a design document and be constrained to implementing as specified or as designed. A user story removes invisible constraints by focusing on the outcome desired by the user. The developer doing the work will see the user story, will be able to better understand what the user needs, and will be able to participate in or even own the specification and design of that story. User stories provide engineers more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.

So, if you were starting a software company with your own hard-earned cash, would you use user stories or not?



Next: Poll - Product Backlog, The Benefits

Poll - Collocation, The Benefits

Collocation is simply having everybody on a whole team in close proximity to each other. This compounds the coordination benefit of whole teams. This is not related to using or not using outsourcing. Whether you are outsourcing or not, collocation only refers to whether your whole teams are sitting near each other.

So, if you were starting your own software company with your own hard-earned cash, would you use collocation or wouldn't you?



Next: Poll - User Stories, The Benefits

Poll - Whole Teams, The Benefits

A whole team is a small group of people (no more than 12) that work together towards a common purpose, primarily spend their time as part of the team, and as a team have all of the skills they need in order to be self-sufficient. These skill sets may include server side programmer, web designer, tester, technical writer, project manager, etc. The intended benefit is that you spend less time waiting for other groups and bringing part-time participants up to speed, you lose less time due to communication delays, and individuals spend less time multi-tasking between multiple projects.

So, if you were starting a new software company with your own hard-earned cash, would you use whole teams or wouldn't you?



Next: Poll - Collocation, The Benefits

Poll - Unit Tests, The Benefits

Unit tests are simply tests that exercise small amounts of isolated functionality. That is, if you have a function that adds two numbers, instead of depending on running a user function that eventually calls the function, exercise the function directly. This often requires the use of mock objects that pretend to be things that the function needs in order to test the function in isolation from other functions that it depends on. Unit testing and refactoring are often done hand in hand.

The cost of unit tests is in writing the tests themselves and refactoring code as new functionality is introduced to keep the unit tests testing at the right level. The benefit is that you can easily test changes quickly to find simple problems before doing more thorough and slower testing. It also provides a good safety net for refactoring, gets developers more involved in testing, and usually improves the design of the software.

So, if you were starting a new software company with your own hard-earned cash, would you use unit tests or wouldn't you?



Next: Poll - Stand-up Meetings, The Benefits

Poll - Incremental Design, Possible?

Incremental design is the practice of designing as you implement. You may do some upfront work to sketch out the basic ideas and groundwork, but don't have a fully fleshed out design up front. The basic idea is that you only implement what you absolutely need to satisfy the user-centered work that you have committed to for the current milestone/iteration. That way, you don't spend time designing for work that you never do.

If you aren't doing incremental design, don’t you end up having to make changes to your software during the next release to take into account all of the feedback and requests for new features that you get from customers? Don’t you have to rework the software (including the design) anyway? Aren't you already doing incremental design on a macro scale anyway?

One of the points of incremental design is that design changes are inevitable and that you are better off writing your code in ways that make it more amenable to design changes. For instance, unit tests encourage the creation of mock objects and the use of mock objects encourage the creation of abstraction layers which as we all know are a good thing.

And let’s not forget that dirty little “major overhaul” secret. You show me some software developed without incremental design that hasn’t had a “major overhaul” and I’ll buy you dinner. So, if you agree that you are going to have to make changes to your design anyway, sometimes major changes, why wouldn’t you want to do incremental design?

Next: Poll - Short Iterations, The Benefits

Poll - Retrospectives, The Benefits

A retrospective provides a forum for the team to talk on a regular basis about what worked and what didn’t work as a team, to discuss ideas for improvement and to work out problems. Instead of a manager having to unearth all problems and come up with all solutions, a retrospective accomplishes much of this, providing the manager with more bandwidth to deal with sensitive issues and to focus on people management. Retrospectives are particularly effective when combined with short iterations because problems have less time to fester and there are more opportunities to take corrective action.

So, if you were starting a software company with your own money, would you use retrospectives or wouldn't you?



Next: Poll - Change Reviews, The Benefits

Poll- Milestone/Iteration Reviews, The Benefits

Milestone, or iteration reviews, are done at the end of each milestone or iteration. It is a demonstration to key stakeholders including one or more customers that you have completed the work for that milestone. It is also an opportunity for the stakeholders to provide feedback on the work. Reviews provide a test of the functionality, show progress towards goals, and build confidence in the work. The demonstration is a visible, trustworthy, and confidence building way of showing progress. If you can’t demo the work, how do you know how much real progress you are making?

So, if you were starting a software company with your own money, would you do milestone reviews or wouldn't you?



Next: Poll - Retrospectives, The Benefits

Poll - Change Reviews aka Code Reviews, The Benefits

A change review, aka a code review, is a review of the changes (code or otherwise) that were done in order to fix a bug or produce an enhancement. This can be as simple as having an engineer other than the author review the changes and provide comments to the author to something as sophisticated as using a specific code review methodology and/or a code review tool such as Smart Bear. So, if you were starting a software company with your own money, would you do code reviews or wouldn't you?

Next: Poll - Incremental Design: Possible?

Poll - Stand-up Meetings, The Benefits

A stand-up meeting is a quick daily meeting of the whole team where you answer three questions: what did you do since the last meeting, what will you do until the next meeting, and what impediments do you have. Everybody gets a quick sense of how things are going and who needs help. The benefits are that problems don’t fester for long and it removes the need for most other meetings.

So, if you were starting a new software company with your own hard-earned cash, would you use stand-up meetings or wouldn't you?



Next: Poll - Milestone/Iteration Reviews

Poll: Refactoring, the Benefits

Refactoring is the practice of continuously improving the usability, maintainability, and adaptability of code without changing its behavior. That makes it much easier to add new and unanticipated functionality. Refactoring has the disadvantage that it takes extra effort and requires changing the code. Any change has the potential to reduce the maturity and stability of the product, especially if you don't have adequate testing in place.

If you were starting a software company with your own hard-earned cash, would you use refactoring or wouldn't you?



Next: Poll - Unit Tests, The Benefits

Poll: Continuous Integration Benefits

With Continuous Integration, all work from all teams is integrated into a single codeline as frequently as possible. Every check-in automatically triggers a build and usually a subsequent run of the test suite. This provides instant feedback about problems to all interested parties and helps to keep the code base free of build and test failures. It also reduces the integration headaches just prior to release.

There are two benefits of Continuous Integration. The first is that it forces you to break work down into small, manageable pieces. The second is that it spreads the integration work out over the entire development timeframe instead of just a short period at the end. Thus, you have more time to find and fix issues instead of a compressed high-stress window at the end of the release.

So, if you were starting a software company with your own money, would you use continuous integration or wouldn’t you?



Next: Poll - Refactoring, the Benefits

If You Were Starting a Software Company With Your Own Money, Would You... ?

If you were bootstrapping a software company with your own hard-earned cash, what software development practices do you believe in enough that you would use them right off the bat?

You have to vote to see the results. There is a link below each poll which links to the next. There are 15 in all. The first is on your role, the rest are about which dev practices you value.

[Note to the jaded cynics: the polls really do only collect votes, your privacy is assured]


Next: Poll: Continuous Integration Benefits

What I Believe About Agile

Before I get too far into what I believe about Agile, let me give a little background. In 2005, I was a staunch Waterfallian. Stuff happened (blogged elsewhere) and then I turned into an Agile advocate.

There are two important things that I believe about Agile. First, while I do believe that being Agile is more than just a set of practices, I also believe that there are a set of practices which are so good that for me they define what I currently think of as Agile and believe everybody can do them and would benefit from them.

Here are the practices which currently define “being Agile” for me. These are roughly in order of benefit: short iterations (preferably 1-2 weeks), Kanban (as an alternative to short iterations), backlog, one piece flow, continuous integration, whole teams, collocated whole teams, test first/test early, use of a product owner, incremental design, refactoring, unit tests, multi-stage continuous integration, user stories, sustainable pace, task assignment and estimation by team members, stand-up meetings, burn-down and burn-up charts, iteration review, retrospective, and frequent releases. There are other good practices out there, but these are the ones that I believe will become mainstream.

Second, and most importantly:

I truly believe the benefits of Agile are significant enough to focus your resources to get to the point of saying this sentence.

This is based on the belief that the algorithm of Agile is just plain better than traditional development combined with direct observation of the significant benefits experienced by both external and internal teams.

To put it another way, if you are not yet investing in Agile, I believe it is the #1 investment you can make to increase your productivity, quality, revenues, customer satisfaction, profitability, and employee satisfaction. It is possible to invest in Agile but not get these benefits. If that is happening to you, I urge you to stick to your guns and look for help. Getting to Agile is worth the investment. It is worth redirecting resources, changing priorities, and doing what it takes to get there.

The web book “Zero to Hyper Agile in 90 Days or Less” is a good place to start.

You may also be interested in “The Top Ten Reasons I May be Wrong That Agile is Better” .

Getting Management and Engineers Out of Each Other's Hair

This is the fifth in a series of posts on self-management that began with "The Use of Self-Managing Teams Outside the Context of Software Development."

Short Iterations Increase Management Leverage
One of the hardest jobs of a manager is discovering and resolving problems. If you don’t know about a problem, you can’t resolve it. If you discover a problem late, you can’t do much about the negative effects it has already had. If you don’t get feedback on the results of the actions you take for a long time, it is difficult if not impossible to judge the effectiveness of your actions. Short iterations, the practice of breaking up a release into 1-4 week development cycles that each produce a shippable increment of work, vastly increase the amount of feedback available to management for making good decisions. It also provides more opportunities to make adjustments and judge their effectiveness.

Burndown Charts are a Management Dashboard That Everybody Loves
A burndown chart is a useful tool for measuring the amount of progress, positive or negative, during an iteration which clearly illustrates trends which may indicate problems. It is simply a day-by-day chart of how much effort remains. At the beginning of an iteration, 100% of the work for that iteration remains. At the end of the iteration, there should be 0% remaining.

An important multiplier of the effectiveness of a burndown chart is its visibility. A clearly visible burndown chart makes it obvious to everybody how the project is progressing. Nobody wants to see a burndown chart that isn’t making progress, and nobody wants other people to see lack of progress for a significant period of time. The burndown chart helps to motivate and inspire. If your own work is going well, but the chart isn’t going down in general, you’ll be more engaged in helping to solve problems that the team is having overall. When used effectively, the burndown chart reduces the effort required for a manager to determine that there is a problem and also reduces the need for the manager to cajole the team into taking corrective action.

Retrospectives Emphasize That You Are All In This Together
A retrospective provides a forum for the team to talk on a regular basis about what worked and what didn’t work as a team, to discuss ideas for improvement and to work out problems. Instead of a manager having to unearth all problems and come up with all solutions, a retrospective accomplishes much of this, providing the manager with more bandwidth to deal with sensitive issues and to focus on people management. Retrospectives are particularly effective when combined with short iterations because problems have less time to fester and there are more opportunities to take corrective action.

User Stories Reduce Micro-Management
Agile prefers user stories over requirements. User stories are simply stories that describe what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome. The separation removes the invisible constraints which can appear when the engineer assigned to a task is given a specification which completely constrains the problem such that only one solution is available. By focusing on the outcome desired by the user, the engineer working on the task has more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.

There are two reasons that user stories support self-managing teams. First, they reduce the temptation of technically minded managers from becoming an implementation bottleneck. Second, they encourage team members to innovate and take on more responsibility which increases their self-sufficiency. This is much easier to do within an Agile environment because there are more practices in place such as short iterations, burndown charts, and retrospectives which encourage learning while reducing the risk of making mistakes.

I hope you have enjoyed this series on how Agile practices reduce and redistribute the job of management and thereby increase your capacity for self-management. If you missed the beginning, the first posting is "The Use of Self-Management Outside the Context of Software Development" .

You may also enjoy reading the the online mini-version of the book that I am working on called "Zero to Agile in 90 Days or Less."

Three Cures for the Management Bottleneck

This is the fourth post in a series on self-management that began with "The Use of Self-Managing Teams Outside the Context of Software Development"

Divide and Conquer
One of the ways that Agile, especially when using Scrum, reduces the management bottleneck and enables self-managing teams is by having clearly identified roles and responsibilities. Two very useful roles are those of Scrum Master and Product Owner. The Scrum Master role clearly frames the project management function. The Product Owner role clearly frames business management related to the product that a team produces. Both of these roles clearly delineate an area of responsibility that would normally be done by a traditional manager and makes it possible to delegate those responsibilities.

The Scrum Master
In Scrum, the Scrum Master is the person making sure that the (Scrum) process is working, looking for and removing impediments, and acting as a liaison between management and the team. Regardless of what you call the role of Scrum Master, the role itself does not require you to be doing Scrum.

The Product Owner
The role of Product Owner also comes from Scrum. As with a Scrum Master, the use of Scrum is not required in order to have a Product Owner. However, the effectiveness of the Product Owner is definitely leveraged by Scrum. The Product Owner is the person who is solely responsible for the content of a release. They are responsible for all decisions related to what changes are made to the product, including all defects and enhancements. Of course, the Product Owner is most effective if they gather information from a wide variety of sources and work closely with all stakeholders. A Product Owner that regularly makes decisions without consulting with stakeholders or acts on a whim won’t be a Product Owner for long.

The Product Owner Needs a Product Backlog
The role of Product Owner goes hand in hand with the use of a product backlog. A product backlog is simply a list of high-level product requirements (preferably in the form of user stories), prioritized by business value as determined by the product owner.

A backlog gives a clear context to discussions of priority. Anybody can go and look at the backlog to see the position of something they have a stake in. If it is lower than they think it should be, they can examine the backlog to see what is higher in order to help frame a discussion around either moving it higher or moving other things lower. Thus, many people can be leveraged to collectively groom the backlog. This distributes the work of grooming the backlog and helps to ensure that the team is focused on the highest value to the organization.

Reducing the Management Bottleneck
Even if the roles of manager, Scrum Master, and Product Owner were all handled by a single person, the use of these roles and their artifacts simplifies the job of management while at the same time amplifying its effectiveness. And of course, that makes it even easier to delegate these roles. The more that management is delegated, the less chance that management will become a bottleneck.

Next: Getting Management and Engineers Out of Each Other's Hair