Thursday, June 20, 2013

Organizational Adoption of Agile

From Craig Larman - Larman's laws of organizational behaviour:
1.       Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and "specialist" positions & power structures
2.       As a corollary to (1), any change initiative will be reduced to overloading the new terminology to mean basically the same as status quo
3.       As a corollary to (1), any significant change initiative will be derided as "purist" and "needing customization for local concerns" -- which deflects from addressing weaknesses and manager/specialist status quo
4.       Culture follows structure.
i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that's why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. John Seddon also observed this: "Attempting to change an organization's culture is a folly, it always fails. Peoples' behaviour (the culture) is a product of the system; when you change the system peoples' behaviour changes."
I think that those who believe Agile and Scrum are the way forward will be at odds with most businesses that have a deep institutionalized Command & Control structures that rests responsibility, but usually not accountability, within groups/committees while diverting responsibility away from individuals. In Scrum we rest most responsibility on the Product Owner and hold this person accountable for the business value delivered at the end of each and every sprint. It is often this simplicity Scrum provides that is in direct conflict with the ‘status quo’. So how to begin changes to the existing structures?
First and foremost, you must have an Executive Sponsor. Without Executive Sponsorship your attempt to directly adopt Agile will almost certainly fail. This is more than just having managers that agree to allow you to use Agile; this is a person who has the rank and status in the business structure who can influence the often many groups/committees who collectively and traditionally have controlled projects.  Agile is a movement that requires top-down leadership to say ‘this is going to happen, here is why it is good and we should all start rowing in that direction.’ The Executive Sponsor, along with possibly one or more Agile Coach specifically trained and experienced in agile adoption at the executive level, will be handing out the oars.
What if you have no Executive Sponsor or the Executive Sponsor’s influence is severely limited? Under these circumstances, full Agile adoption is very unlikely to happen. However, there is a strategy that could overcome the tremendous obstacles that are in the way but it does depend on you finding some in Mid to Upper level Management more interested in results rather than institutionalized processes. The ultimate result is usually a hybrid adoption of Agile where all or some of the institutional controls remain in place but an Agile sanctuary is carved out with fewer of these institutional controls than a traditional waterfall project. This hybrid Agile project is not truly Agile but neither is it true waterfall. The strategy follows a bottom up Agile Adoption approach that will take time, maybe a lot of time, to slowly chip away at the traditional structure and replace it with an Agile structure and Agile mindset.
The strategy is twofold:
1.       Target getting support from managers in the organization that are more likely to support Agile; and
2.       Target going around the organizational structure of “over seers”
The strategy includes targeting those executives in middle to upper management that are more likely to support an Agile process and have some influence on those in the organization who are stanch supporters of the institutional controls. The idea here is not to change these people completely over to the Agile mindset but rather get these targeted managers enthusiastic enough about Agile so they can see the possibilities and potential of Agile. Targeting managers who don’t have influence over supporters of the processes or targeting managers who are the stanch supporters of the processes is usually a tactical mistake. Targeting a manager who doesn’t directly influence those in control of the processes might be an easy convert but other than a quick burst of satisfaction, the real battles will still lie ahead. The manager who is a supporter of institutionalized processes is very difficult to convert; they probably believe in their familiar processes and controls much like you believe in Scrum, albeit for different reasons. A word of caution, because you’ve gotten some support for your Agile project, you must remember that “success has many fathers, failure is an orphan.” For those in middle to upper management who supported you earlier, to ensure their continued support of Agile and endorse its use, hybrid Agile projects must succeed and succeed “loudly”. If your project fails or succeeds but with only a whimper, some, most, or all middle to upper manages may forget that they ever supported Agile.
The second part of your Agile adoption strategy will be to identify all those organizational groups and individuals who traditionally sign-off on projects and find a way to exempt the Scrum project from these. These groups are those who sit on gate committees, steering committees, technology committees, or any one of a dozen other committees that approve, sign-off or use other mechanisms of “over-seeing” a project. These groups are often a source of power and prestige for its members and are traditionally very difficult, if not impossible, to get around without an appropriately positioned Executive Sponsor. The best way to get around these groups is to make your project a separate business unit that answers to the CEO/board. This follows along how IBM built its PC division in order to get out from under the bureaucratic thumb of IBM’s corporate structure.  Another tactic is to chip away at the required process these groups require projects to follow. This can lead to some relief for the project but will probably not succeed at allowing full Agile adoption for quite some time.
Is doing a Hybrid Agile Scrum adoption good? The short answer is yes. By simply following the activities defined for Scrum, (Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective), Jeff Sutherland has said that this will increase productivity by 20%-30%. However, the greater benefits of Agile are really attained through following of and embracing the deeper meanings of the Agile Manifesto, the Scrum Guide, and Scrum Primer. To become “hyper-product” would require everyone involved in the project (managers and scrum teams) to believe in and live Agile and Scrum. Unless the Mid to Upper level Managers of the business are only interested in results and don’t really care how you achieve them, your best approach to adopting Agile is incrementally, one step at a time.
Craig Larman is co-author of:
  • Practices for Scaling Lean & Agile Development: Large, Multisite & Offshore Product Development with Large-Scale Scrum
  • Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
  • Agile and Iterative Development: A Manager's Guide

Monday, June 3, 2013

Sprint Review Facilitation & Customization

The Scrum Sprint Review is a key Inspect & Adapt meeting where the Scrum Team discusses with Users, Customers, and Business stakeholders what was "Done" in the just completed Sprint. The Sprint Review meeting is short but must cover the agenda items listed below. The attendance by the Scrum Team is required. Attendance by stakeholders is optional but should be strongly encouraged for those key stakeholders most affected by the Sprint results. This article gives some advice on how to conduct the Sprint Review when stakeholders are unable to physically be present.
During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint and the Product Backlog is amended if needed. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done. The Product Owner provides the stakeholders the likely completion date for the release based on the Development Team's velocity and work remaining in the Product Backlog. This is an informal meeting, and the presentation of the Sprint results is intended to elicit feedback and foster collaboration.
One hour Sprint Review Agenda includes the following elements:
  • The Product Owner identifies what has been “Done” and what has not been “Done” (suggest 5 minutes)   
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved  (suggest 10 minutes)
  • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment  (suggest 15 minutes)
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date  (suggest 10 minutes)
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings  (suggest 20 minutes)
The feedback from the stakeholders, directed toward the Product Owner and Scrum team, is the most important thing to get out of the Sprint Review. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Customization for Stakeholders who cannot be physically present at the meeting

A Scrum Team strives to ensure the key stakeholders, as identified by the Product Owner, are in attendance at each Sprint Review. The key stakeholders identified may differ from Sprint to Sprint based upon the work selected in each Sprint, but it is important to the success of the project that those identified feel compelled to attend the Sprint Review when asked. When a stakeholder cannot be physically present at the Sprint Review meeting, the Scrum Team loses out on viewing subtle hints on the reception of their Sprint results and future Sprint plans. Stakeholder body language and tone are indispensable clues to the observant Scrum Team which can be lost when stakeholders are not with the team during the Sprint Review. Unfortunately the realities of the business means that stakeholders are distributed across several locations and cannot always be physically present at the Sprint Review. Below are the options in order of preference.


Telepresence is the preferred method for stakeholder involvement in the Sprint Review when not able to physically attend. Scrum Master would schedule the telepresence rooms locally and at all remote locations if possible. The Sprint Review meeting should be conducted as if all people were in the same room.
      • Stakeholder sees what those present in the meeting room see
      • Stakeholder is not a disembodied voice but a real person
      • Scrum Team and other meeting attendees can see and gage stakeholder's reactions to product demo and artifacts
      • Scrum Team and other meeting attendees can see and gage stakeholder's reaction to comments, statements, and suggestions
      • Facilitator of the Sprint Review can better steer the Sprint Review back to the Sprint Review agenda when necessary
      • Difficult to overhear side conversations from remote stakeholders

Webex / LiveMeeting / Net Meeting / or other online collaboration tool:

Online collaboration tool is the preferred method for stakeholder involvement in the Sprint Review when not able to physically attend and access to a telepresence room isn't available.
Product Owner should specifically ask remote stakeholders for their input on the way forward for improving the product.

      • Stakeholder most often see what those present in the meeting room see
      • Stakeholders can follow and participate in discussions on the just completed work shown in the demonstration

      • All stakeholders will need the same online collaboration tool installed and available
      • Higher likelihood that remote stakeholders will talk over people in the meeting room
      • Higher likelihood that people in the meeting room will talk over the remote stakeholders
      • Easier to mis-read voice inflection and tone without seeing the body language
      • Difficult to overhear side conversations


Using only a speakerphone (no video link or web sharing) is the last option available for stakeholders who don't have access to collaboration tools and no access to telepresence equipment.
To give the stakeholder a voice in the Sprint Review, the Scrum Master or Product Owner, as appropriate, would ask those who are remote to provide their input before the Sprint Review meeting so the Scrum Team and stakeholders at the meeting can review their input together. This way the remote teams know that their input counts and will heard by all people in the room.
Product Owner should specifically ask remote stakeholders for their input on the way forward for improving the product.
      • Remote stakeholders have a proxy voice in the Sprint Review

      • Speakerphone stakeholders will not see what's being presented
      • Speakerphone stakeholders will find it difficult/impossible to follow discussions during the product demo and presentation of any related artifacts
      • Speakerphone stakeholders may find it difficult to collaborate with those in the meeting room without seeing the Sprint results
      • Higher likelihood that remote stakeholders will talk over people in the meeting room
      • Higher likelihood that people in the meeting room will talk over the remote stakeholders
      • Easier to mis-read voice inflection and tone without seeing the body language
      • Difficult to overhear side conversations