9 Organizational Changes to make when adopting Agile

If you are a traditional (waterfall) organization transitioning to Agile, you’re about to be in for a big shock. To make a successful organizational shift, many changes are needed, including:

Traditional	Agile
Work is directed by manager	Team self-manages
Work is approached on a project basis	Shift in focus to products instead of projects
Work is measured by spend	Success is measured by value delivery
Long feedback loops	Short feedback loops
Heavy, upfront documentation	Lightweight, minimal documentation
Rigid scope with formal change management	Scope is variable and negotiable; not a promise
Estimating is done upfront, when least is known	Items in the product backlog are relatively sized
Individuals are involved in more than one project	Individuals are fully dedicated to a single team

Self-organization/self-managed teams

The need for a traditional “manager” goes away in many regards in Agile. Managers do not assign or track people’s work. Instead, self-managing teams figure out how to deliver the highest-value items as prioritized by the Product Owner.

Rather than having a “manager”, team members should have career coaches – people who help them identify their growth path within their career and organization. No one likes micro-management; having a career coach empowers people to take their growth and development to the next level. What motivates most people is the ability to control their own destiny while enjoying challenging and meaningful work.

Products instead of Projects

The focus of an organization needs to shift from project-based (distinctly defined scope, budget, and specific start/stop dates) to product-based. Unlike projects, products have a full life cycle (vision, inception, growth and maturity, decline, sunset). While a “product” exists, it has a product backlog, and will be developed until the Product Owner determines that enough value has been realized.

Metrics

Measurement of success (or failure) must also change. Many organizations today focus on the wrong metrics, such as:

• How many projects were completed?
• Is the project on budget or over?
• How many projects are in progress?
• Is project delivery on schedule?
• How many changes were approved?

It’s not simply a matter of black-and-white ROI – there are other measurements that are more important. In Agile, some metrics to care about include:

Shortened feedback loops

Gone are the days of “figuring it all out perfectly upfront” and throwing a giant specification document over the wall to developers who won’t even read the spec. Instead, devs will look at the pictures, make assumptions, and code something else. When finally delivered, things will have changed, and the business will need something different.

With shortened feedback loops, this reduces the possibility of spending valuable development time working on something that might never be used. Immediate user feedback ensures that you are delivering exactly what the users want and need, rather than waiting a year or two to find out that it’s not really what they want.

Documentation

The level and type of documentation will also change, depending on the type of industry. Traditional projects require heavy upfront documentation. With agile, you want to document “just enough, and just in time”. By doing this, you again reduce the possibility of spending time on documenting requirements for something that may never make it to the top of the Product Backlog.

In some industries, however, there may still be a need for more robust documentation. If you are in a regulated industry such as health care, finance, or insurance, you may be subject to audits, and need to have a proper paper trail to support your decisions. Even more stringent documentation requirements may exist for medical device companies, where there is no tolerance because the products are literally life-and-death.

If Organizational standards exist, they must also be changed. This would include templates for business requirements documents, change requests, test plans, etc.

Scope Management

In agile, the scope is variable, and the Product Backlog is dynamic and ever-changing. Agile flips the project iron triangle (scope, budget, and time) upside down. With flexible scope, formal change management isn’t needed. Instead of being rigid and resisting change because there’s a large cost associated with changes late in the game, Agile embraces change. Items that aren’t valuable will naturally filter to the bottom and won’t be developed.

Estimating / Sizing

Estimates change in Agile, too. Items in the Product Backlog are sized using relative estimation. Relative estimating is a tool to determine a team’s average velocity in order to predict how much work a Scrum Team can take on in future sprints.

At the task level, time estimates may still be needed. However, they don’t predict how much time something will take. Rather, these numbers track the “burndown” as team works through their tasks in any given sprint. This will show the team how they are tracking towards completing their sprint goal and can help identify if there are any issues that need to be addressed.

Focus

Most organizations have people assigned to multiple projects at the same time. This is inefficient and ineffective. In Agile, team members belong to a single product. A Product Owner directs the priorities enabling the team to focus on the most important things first. This eliminates outside requests, allowing the team to blast through their work much faster.

Final Thoughts

These are just a few of the changes that need to be made at an organizational level when adopting agile. I am sure there are many more. Do you know of any other adjustments needed when making this shift? Let me know!