Menu
The software engineering field has changed a lot over the years. There have been many advances in the field in terms of tools used, how teams build and test software, the speed of delivery, etc…
For teams that have not yet become a true agile team (every sprint is developed, tested and production ready), one pattern continues to show itself even though this pattern is a carry over from the days of large waterfall projects.
The pattern being alluded to is the projection and allocation of budget based on the one third rule. In the days of large waterfall projects, organizations made the assumption that a software budget was allocated one third per major category of work: analysis and design, develop, test. Analysis and design includes the architecture work for the project. This was the rule of thumb that was used to generate High Level Estimates (HLE).
This rule of thumb worked well when it was applied evenly to all three categories to generate a HLE. However, once the work actually started, what usually happened was that as the first two categories of work needed more time than estimated, it inevitably came at the expense of testing in an effort to stay on budget.
This pattern has caused grief to many testing teams over the years. For some reason the design and analysis or the developers always got more time when they asked for it. The thinking was that without these 2 first categories doing their work, there would be no product to ship. However, for some reason no matter how many changes occurred in the first 2 categories, the testing was usually squeezed to fit in the original rule of thumb. It didn’t matter how complex the testing was, the team was forced into the 30% budget, which always meant that testing had to be reduced. Reducing testing inevitably lead to that vicious cycle of problems in production, which eventually would come back and cost the organization money by having to allocate more and more of future budgets to re-work and corrections, rather than new features.
Move the clock forward to today and unfortunately for teams that haven’t become true agile teams, the pattern continues. Organizations think they are Agile but for some reason they are still planning releases to production that are only every 3, 6 or 12 months without any regular deliverables to production. Testing is still thought of as a separate entity within the sprint and the team is usually unbalanced on the number of quality resources. You will usually find a “hardening sprint” or “stabilization phase” at the end of the sprints but in most cases the question of not going beyond the 30% of the budget for testing is still very top of mind in these organizations.
If an organization is going to work in this type of environment, then they should be applying the same rules as they used to in the past, an equal amount of time for each major activity: Analysis and Design, Development and Test. However, if an organization wants to remain competitive and be able to release software in a timely fashion, then they need to become a real Agile team that works to build in quality.
When a team moves to using Agile and Lean methods, then this team is focused on delivering value to the organization. When delivering value is top of mind for a team, then the amount of budget per category of work is less relevant. The team is focused on delivering valuable working features every sprint which have been prioritized by the product owner who has already made the business case for the feature.
It no longer matters how much of the budget goes for each category of work, but rather, how many valuable features can the team deliver for the budget allocated.
This also now changes the dynamic of how the teams think of quality. It is no longer just the concern of the testing staff, but rather the team now has ownership of delivering a working feature with high quality. Quality is now everyone’s business, therefore the allocation of a budget by category is no longer really relevant.
This new reality has freed up the team to focus on estimating a feature and the work needed to deliver it. The focus is no longer on how much time it should take each category of work to deliver the feature. Yes the team is estimating hours to deliver when breaking down a story into sub-tasks, but the estimate is now a team effort and no longer a siloed effort in which each silo gets allocated limited budget dollars.
Agile and Lean methods have helped software teams refocus on what is really important, delivering awesome quality software that delivers value to the organization!
If you want to know more about how Agile can help refocus an organization on delivering valuable features and maximizing your budget dollars, please contact Avant for a consultation.