you have a buildup of user interface requirements or features waiting to be tested by QA. As the rest of the team continues to define, design, and implement new requirements, the amount of "inventory" waiting to get processed by QA will continue to grow because it is the bottleneck. So step 3 of ToC says you should slow down all non-bottleneck steps to operate at the same pace of the bottleneck, meaning your requirements gathering, design, and development should all be restricted to the extent that you are releasing implemented features to QA at a slow enough pace that QA can immediately start testing them. So now, if your team size has not changed, it's entirely likely that your QA team is working at or near its capacity while the rest of the team is working below its capacity; literally they might be sitting around waiting for work to do! So what do you do in this situation if you don't like the notion of paying a bunch of analysts and developers to sit around and do nothing or only work part time? According to ToC, you should either scale back the number of people gathering and implementing requirements (if you don't want them to be idle) or you can increase the capacity of your bottleneck (step 4). In this case you can increase the number of features QA can test at any given time or reduce the cycle time per test (help QA figure out to how test more quickly). Either of these steps will increase the capacity of QA, meaning the other parts of the team can scale up again until another bottleneck is revealed (step 5).
Lean and ToC help identify and target waste to improve to our organization. They do not tell us how to do so although there have been efforts in the field to apply both Lean and ToC to software development (Poppendiecks' two books [7, 8], and Agile Management for Software Engineering  by David J. Anderson come to mind).
Agile development is all about practicing a better form of building software. There are methodologies that address ways to build software with several practices together such as Scrum, XP, Crystal, and others. The practices are useful in and of themselves and can be used as surgical tools as long as we are cognizant of how a development practice affects the software development system.
To adopt the correct agile development practices we must be aware how each practice helps eliminate waste in one or more steps of a development cycle. So, for example, test driven development helps reduce the pile (inventory) of bugs waiting to be fixed. Pair programming reduces "hand-offs"between developers with different expertise to build a cross-functional requirement. Cross-functional teams help eliminate the waste from hand-offs and pending work as it moves from team to team.
Putting It All Together: Targeting with ToC, Eliminating Waste with Lean, and Elevating the Constraint with Agile Practices
Lean and Agile aren't very good about indicating where in our system to start improving, but ToC is. To maximize the business value (to be read "most directly address our organization's goals") we start with step 1 in ToC:
1. Find the bottleneck.
Then, even though inventory is a form of waste, in this case it is"necessary waste" because it keeps the system from getting even slower if something happens to the steps that feed the bottleneck. With that we have done step 2 of ToC:
2. Exploit and protect the bottleneck.
The final step we will use from ToC before switching to Lean is to slow