Why Your Boss's Boss Should Also Go Agile

29 October 2010

Incremental software development methodologies can be traced all the way back to the 1950s, but it wasn’t until 2001 that “The Agile Manifesto” created a comprehensive and landmark account of agile development and why it’s a better, lighter approach to creating software faster.

Ever since then, developers have been using agile methodologies to improve the speed and flexibility of software development through operational improvements, but most other groups within the same company have not adopted a similar philosophy.

Conceptually we’ve bottled up agile as being for software developers, as if speed, flexibility, and complexity weren’t also issues held within every other departments of fast-paced software companies. When software developers are using agile methodologies, but nobody else is, developers become like the clique group of school kids who share a foreign language nobody else understands.

This has caused us to limit the potential for agile frameworks, because they're only implemented operationally, but not strategically. It’s like a wooden boat full of rowers. They might have seamless coordination and full visibility into the work of their colleagues, but they can’t see the captain’s orders up on deck.

From a developer’s perspective, this makes the direction given by leadership seem ill-timed, disjointed, and contradictory. Developers may begin to think their VPs and C-level executives are pulling them in too many different directions. In actuality, turbulent seas require constant and sharp adjustments to reach the end of the storm in the right direction and position. This creates rapidly changing orders that reach our boat’s rowers in inconsistent clumps through a series of messengers that often distort the original meaning or delay delivery.

What our boat needs is a glass deck, where the programmers can see directions given by the captain directly and respond in real-time. We need an agile company, not just agile software development; a company with middle-managers instead of middle-men. By eliminating the messenger phenomenon, companies can become faster, leaner and more responsive strategically while gaining more confidence in the company’s leadership and direction.

So how do we get a glass boat? Get your boss (and your boss's boss) on board with agile. Make it a company-wide initiative, instead of a developer one. Once you have people on board, there’s a few key processes you need to implement to align software development with company strategy.

  • Part of the reason management feedback on strategy is so untimely is because developers and managers aren’t working in the same sequence. If management operates in the same sprints the developers do, the team will get strategic input just in time for the next sprint.
  • After each sprint the Product Owner needs to re-adjust the backlog based on strategic priorities. This means each sprint needs to have strategic objectives identified for it ahead of time, so you can quickly identify which backlog items are now the most important as priorities change.
  • Communication from the VP & C-level often come to the development team in slow-moving e-mails or powerpoints, which creates a disconnect between strategy and execution. Providing specific new weightings and new objectives only once-per sprint will give teams more instant and clear direction.
  • Last, but certainly not least, the glass boat is all about instant visibility all the way through the command chain. This means instant and highly automated reporting both for information moving down the chain of command and for information moving up. Just as the top of the company needs their strategies implemented quickly, feedback from the bottom needs to be consolidated and presented to the top so they can make informed decisions.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Martin Proulx, CSM, 11/1/2010 10:29:44 AM
There is growing understanding that transitioning to Scrum is a cultural change, not just a team process change. A culture change requires that "leaders" (wherever they are in the organization - including senior management people) understand the changes, understand what it means for them, and understand the objectives.

As stated in your post, it is critical to have your boss and his boss (and his boss...) support such a transition. What is often missing for people to accept and support such a change is what it actually means for them. I offered suggestions in a recent post: http://analytical-mind.com/2010/08/12/mommy-i-dont-feel-so-good-im-a-people-manager-in-an-agile-organization/

martin
Siegfried Kaltenecker, CSM,CSPO, 12/1/2010 4:19:44 AM
Comment on why your boss…

Hi Christine,

Thank you for your article. I┬┤m with you on:

ΓÇó The observation that agile has been bottled up for developers rather than applied to organizations;
ΓÇó The experience that there often is a kind of clique dynamic, including a narcissistic attitude of ΓÇ£we are the good, if not the better onesΓÇ¥;
ΓÇó The goal of realizing the full potential of agile thinking by expanding it to strategic issues as well;
ΓÇó The concept of supporting ΓÇ£middle-menΓÇ¥ to become middle-managers in order to leverage agile change.

On the other hand, I┬┤m rather sceptical about:

ΓÇó The boat metaphor ΓÇô can one really picture modern organizations as steered by a captain, driven by a bunch of rowers, sitting in line, aligned in their efforts to follow the given instructions?
ΓÇó The hope that there will be an end of the storm ΓÇô are there any significant signs that ΓÇ£the turbulent seasΓÇ¥ are about to calm down?
ΓÇó The idea there is one right direction and strategic position ΓÇô isn┬┤t the ΓÇ£art of strategy developmentΓÇ¥ nowadays rather building on a professionally led, i.e. facilitated trial-and-error approach, enabling various loops of communication and feedback, actively using all the data that the ΓÇ£rowersΓÇ¥ can provide?
ΓÇó The solution of a glass deck, in other words, that it just needs more visibility and better information moving up and down the chain of command - donΓÇÖt we need more opportunities for open, trustful communication, i.e. joint sense-making processes, which are cross-functional, silo bridging and hierarchy-bridging as well?

Looking forward to more and different answers, hopefully also inspired by our still ongoing survey: http://p-a-m.org/2010/11/successful-leadership-in-an-agile-world/
Pat Guariglia, CSM, 12/20/2010 9:59:31 AM
I agree with you 100%. It is important that top management not only "understands" agile, but there is a mechanism in place to actually carry the strategic objectives down to the sprint level. As you mentioned in your third bullet: "ΓÇó After each sprint the Product Owner needs to re-adjust the backlog based on strategic priorities. This means each sprint needs to have strategic objectives identified for it ahead of time, so you can quickly identify which backlog items are now the most important as priorities change." This is an important part. The strategic message must be aligned with the actual work, and it has to be communicated downward quickly and timely enough so it can really affect the sprint and subsequent releases. Like you said, the product owner needs to adopt to the change from the top and reprioritize to align with executive strategy as appropriate.
Brian Dsouza, CSM, 1/19/2011 6:25:36 AM
I agree in spirit 100% but feel that achieving this may be somewhat unrealistic.

I do believe that we 'nerds' hit on something that the management gurus do not want to admit. They found a better way to organize and deliver.

There are intrinsic and extrinsic challenges for upper management in embracing 'visibility' and 'transparency'. How many 'C' level execs would be willing to admit to their organization/team mates that a strategic decision they made cost the organization dearly or just plain failed? Conversely how open would the organization be to seeing their 'leader' fail. For an organization that can embrace this, all power to you.

In the corporate world, everything is packaged and gift-wrapped so that the left hand (read shareholders) really does not know what the right hand (management) is doing. In our instant-gratification-Wall-Street-controlled world, would shareholders be forgiving of a good CEO that makes a mistake while attempting to excel?

In spite of all the strides we have made with using an open transparent approach, even in the software community, it is still very difficult for people to accept failure and continue to trust.

Whereas I believe some forward thinking organizations will achieve this, from a typical 'C' level perspective, 'transparency' is nice for everyone else in the organization to practice.

We need 'Glass Bottom', 'Glass Roof' and and 'Glass Wall' thinking to be preached at Management schools before it can become a reality. Students in school need to see transparency being practiced for them to adopt it as a value. This is a tall order, given the way we function as a society.

Alternatively, a reduced level of transparency may be a necessity at certain levels of an organization.

You must Login or Signup to comment.