DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Balancing Autonomy With Accountability

Balancing Autonomy With Accountability

Both managment yin and yang are needed for a transcendent Agile experience. Namaste.

Edwin Dando user avatar by
Edwin Dando
·
Nov. 21, 18 · Opinion
Like (1)
Save
Tweet
Share
8.07K Views

Join the DZone community and get the full member experience.

Join For Free

Many organizations are embracing Agile ways of working in an attempt to build faster, more customer-focused and resilient organizations. They are redesigning themselves to create a culture where decision making is transitioned away from middle management towards those working with customers on the front lines. Ultimately, they seek engagement in order to create a culture where staff is empowered to truly delight customers. Autonomy is the critical ingredient; however, autonomy is often misunderstood. Many organizations think they just need to increase autonomy, however, they forget to include the counter-balance of accountability, often with disastrous results.

Recently, many senior leaders have shared a concern with Radically. It is happening so much that it is becoming a pattern. They are telling us, often with hushed voices, that they feel they cannot ask important business questions such as, “When do you think this will be done?” or, “How is cost tracking?” or, “Will we hit our launch date?” When they do ask these questions, they get proudly shunned and told that these questions "aren't Agile".

Perplexed, they feel stuck. Do they go back to their old ways and demand answers (which they know will be fabricated anyway)? Do they dare mess with the new Agile culture and risk being seen as "a manager", the evil conspirator who is secretly trying to stop Agile and control everyone? Or do they try to manage the business without the vital information required to make decisions? The end result is managers on tip toes.

The problem is that they have increased autonomy without increasing accountability.

scales

One firm wanted to increase autonomy by empowering their people to put forward initiatives that would be funded based on their ability to help deliver the strategy. The “how” (the execution of initiatives) would be entirely up to the proposer, giving the teams freedom and flexibility to focus on delivering the best outcome as the work progressed.

All sounds awesome, right? Unfortunately, it wasn’t, as year after year they encountered the same problem: 9 months into the year they would run out of money and the entire organization would then go into a capital freeze for the remainder of the financial year, causing significant disruption.

Why?

Firstly, those leading the initiatives were not being held accountable for actually delivering something of value. They were given a chunk of money at the beginning, based on forecast delivery of a business outcome. The intent was to give the teams autonomy, however without the counter-balance of accountability for how the investment was being spent, the teams failed to deliver.

The root cause was that they were still running a traditional governance model that didn’t understand Agile. The teams weren’t being held to account to deliver “done” increments of value every iteration. This resulted in the illusion of progress (“We are doing iterations, therefore, we are doing Agile!”), but nothing could be shipped to the customer. The catch-up stabilization and integration required a lot more budget.

The lesson: they decentralized decision making and control to provide autonomy but failed to establish the corresponding accountability. They went from centralized accountability to no accountability at all.

fail

Another firm wanted to embrace Agile in order to build highly autonomous teams and attract the best talent in the market. They rapidly “delayered,” removing most middle-management positions and set the teams forth on a journey of self-organization. Teams were taught new ways of communicating, sharing and collaborating. Each team had a facilitator – a servant leader who would help the teams as required.

Again – seems awesome doesn’t it? However, when the CEO asked how many more iterations would be required to deliver the release, she was shocked to find the teams had no idea. Nobody knew whether this was on track nor did they know cost to date and forecast completion cost. Again, they went from a small group of managers being accountable, to nobody being accountable in the new approach.

Sadly, we often encounter this and the frustrating thing is that this is not (in our opinion) professional Agile at all. One senior leader we talked to called it “Kindergarten Agile,” another “Cupcake Agile,” and yet another "Jazz-hands Agile." It is often the result of well-meaning people who simply lack the business acumen to understand the implications of changes they are suggesting. They recommend autonomous squads, that team have lots of fun and we will measure success by team happiness.

Agile

Agile is based on transparency. When we have transparency, we can see what is going on change course accordingly. Accountability is very specific – in Scrum the Product Owner is accountable for value, the Team is accountable for delivering done increments and the Scrum Master accountable for the process.

Governance remains vitally important. It doesn’t disappear, it just changes, typically from a classical model where the focus is on schedule, scope, budget, quality, and risk, towards a modern model that focuses on value, risk, learnings, and then the next optimal move.

Management remains important, too. It doesn’t disappear. It just changes from a role that allocates work to people and then manages their progress, to a role that focuses on growing people, providing honest feedback and coaching them.

Business questions such as “When do you think this will be done?” or, “How is cost tracking?” or, “Will we hit our launch date?” are completely fair and valid. The difference is that we are moving from a world where we pretended to be able to know all of this upfront and would lock it down in a plan and then govern to that plan regardless, to one where we accept we don’t know it all up front and instead forecast these factors and continually update the forecast as we progress, enabling regular changes in direction based on the information at hand.

Don’t accept Cupcake Agile. Yes, autonomy plays a critical role in reshaping our workplaces, but don’t forget to balance autonomy with accountability.

scrum agile

Published at DZone with permission of Edwin Dando, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How Agile Architecture Spikes Are Used in Shift-Left BDD
  • Building a REST API With AWS Gateway and Python
  • Best Practices for Writing Clean and Maintainable Code
  • Key Elements of Site Reliability Engineering (SRE)

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: