!"#$%&%'($)*+','#-).

/'0$)1*/+/(#)23456)
7/%&8($)
There are many widely used team-based Agile solutions such as, Scrum, XP and Kanban, but there are few documented solutions at the multi-team Enterprise level. Historically, this has been addressed with a roll-your-own approach, often with the assistance of an Agile Coach. Within the Agile community there are a number of well-known and frequently used practices that help Agile succeed when synchronizing multiple teams and creating an organization that supports Agile. The primary goal of Enterprise Agility is to encapsulate and document these well-known best practices for transforming an Enterprise to Agile as simply as possible, inventing as little new as possible. To that end, the Enterprise Agility model is based on the principles and values of the Agile Manifesto as well as the principle of The Simplest Thing That Could Possibly Work. The Enterprise Agility guide is a living document and your feedback is welcomed and appreciated.

.,8((9%-)
Where there may be some confusion regarding terms, they are explicitly defined here. Minimum Viable Increment (MVI) - the epics and/or user stories associated with developing an increment of working software which has just enough value to be worth the effort of delivering it; no more and no less. While the Lean Startup definition of Minimum Viable is very useful when working in that mode, MVI in this document refers to increments that are of a high technical quality and meet the teams definition of done at the release level. They are used primarily for creating a more Agile-friendly funding and investment vehicle.

7%':9%-)7%'";'&,$()
*0<$%$)#8)#<$)*+',$)=9"'>$(#8) The fundamental underpinning of the Enterprise Agility Model is the Agile Manifesto. In order for a practice to be part of this Model, it must adhere to the values and principles of the Agile Manifesto. ?8)@<$)A':&,$(#)@<'"+)@<9#)B8/,0)78(('C,-)D8%E) The model follows the principle of the simplest thing that could possibly work. To that end, the documentation for the model is intentionally sparse. Application of this principle also means that only the minimum number of practices that are needed at any given time should be applied. F$:8G$)?$&$"0$";'$() Look for ways to create loose coupling rather than tight coupling. Three examples:
!"#$%&'#$"('#)*(+',"-./0+'+&001*(+'#0'*#%&"#*0('2/"((*(+3'104%'"5'16-$'"5'2055*,/%'#0'"'5$0&#' 7%%./)'1%%#*(+'#$"#'*5'*(8%2%(8%(#'09'*#%&"#*0(5:'

Copyright 2012-2013 Eliassen Group, All Rights Reserved

!"#$%&'#$"('80*(+'8%#"*/%8'2/"((*(+'"(8'"("/)5*5'90&'"'7$0/%'&%/%"5%3'90-65'0('#$%'9*&5#';<='90&'"' &%/%"5%3'#$65'104*(+'#0'"'/005%'-062/*(+',%#7%%('"'&%/%"5%'"(8'#$%';<=5'#$"#'1".%'*#'62'>*9' 10&%'#$"('0(%?:' ;".%'%"-$'#%"1'&%520(5*,/%'90&'"5'16-$'09'*#5'07('8%5#*()'"5'2055*,/%'&"#$%&'#$"('8%2%(8'0(' -%(#&"/*@"#*0(:'A0&'*(5#"(-%3'"('BCD'"&-$*#%-#6&%'7$%&%'%"-$'#%"1'-"('&%/%"5%'*(8%2%(8%(#/)'*5' "#'0(%'%(8'09'#$*5'52%-#&61:'

D<9#)'()*+',$H)
There is a very simple answer to this question. Agile is an adjective which describes anything that supports the values and principles of the Agile Manifesto. There is a large and vibrant Agile community which produces ideas, methodologies, tools, techniques, and practices which support those values and principles. Examples include Scrum, Kanban, XP, Continuous Integration, and many more. Unfortunately, it is very difficult to assess the Agility of a person, team, or Enterprise. The Agile Maturity Matrix tool has been developed to help address this problem. It is a set of criteria which help to assess Agility. The more criteria that a team meets, the greater the likelihood that the team is Agile. The fewer criteria that a team meets, the less likely it is that the team is Agile. While meeting or not meeting the criteria is no guarantee either way, it is a good place to start. To date, more than 30 Agile Coaches with experience at more than 100 organizations have contributed to this Agility model and Agile Maturity Matrix.

@<$)!"#$%&%'($)*+','#-)?'9+%9:)
Part of the Enterprise Agility Model is the Enterprise Agility Diagram. This diagram is useful for visually representing the model and for facilitating discussion of the model. There is also an animated version of the diagram that illustrates the continuous flow that is a key part of the model.

*+',$)I9(';()
The Enterprise Agility model includes a few Agile basics that are widely practiced, written about, or part of most Agile training programs. These will be only lightly touched upon, but are mentioned here for completeness. The following are specifically covered here because they referenced in the Enterprise Agility Diagram. However, there are many more in the Agile Maturity Matrix tool. @$9:JK$G$,)*+','#-) It is assumed that the Enterprise is already adept at standing up Agile teams using proven team level Agile practices in keeping with the Agile Manifesto. Examples include Scrum, XP, and Kanban. More specifically, it is assumed that the Enterprise is adept at standing up teams that have mostly 2s on the team section of the Agile Maturity Matrix within two months. If that is not the case, then that should be an immediate area of focus. L($%)A#8%'$() It is assumed that the basic unit of work is the user story and that they will be well written, meet the INVEST criteria, and represent vertical slices of work.

Copyright 2012-2013 Eliassen Group, All Rights Reserved

?$0';9#$0)@$9:() It is assumed that the best teams are co-located, cross-functional, dedicated teams and that your organization is continually striving towards this to the extent that it can. The most important aspect of dedicated teams is that ideally any given individual should be on at most one team and that the team pulls its work from exactly one backlog and that backlog is managed by exactly one product owner. B%8(()M/";#'8"9,)@$9:() The cross functional part of cross functional teams is often fairly weak. In this model of Enterprise Agility, cross functional is defined as everything required to go from business idea to production. While it may not be possible to do this right away, it should always be the goal. It may also seem impossible to achieve this goal because the number of people to do so might currently be much more than 7 +/- 2 . However, cross functional also implies multi-disciplinary people. It doesnt mean that everybody can do anything, but for example, instead of having a release engineer or operations person on every team, you may cross train teams on release engineering and operations principles and practices. That then simplifies the job of the release engineer and operations people and makes it easier to implement DevOps and Continuous Delivery. */#8:9#'8") Whether you are implementing Agile at the team level or across the Enterprise, automation is a key enabler. However, it is a necessity for success at the Enterprise level. *+',$)@88,() It is assumed that your organization has already adopted or is actively pursuing the use of Agileoriented tools in all areas. There are five key Agile enabling tools: unit test frameworks, Agile Software Configuration Management (SCM), Agile Project Management, Continuous Integration, and 1-click Deploy. 7%80/;#)NO"$%() It is assumed that each Agile team will have a product owner associated with it and that the product owner is sufficiently available to the team, empowered to make decisions on behalf of the customers/market and the business, and has sufficient knowledge of the customers/market to make good business decisions.

*%;<'#$;#/%$)
In an Enterprise context, architecture has two competing forces: promoting good architecture and architectural practices as widely as possible, and enabling agility. There are a number of practices and techniques that enable architecture to work well in an Agile environment. These include the following. !:$%+$"#)?$('+")19E9)P";%$:$"#9,)*%;<'#$;#/%$6) Rather than decide the architecture in advance, let it emerge as you implement stories. In order for it to grow in the right direction, combine this with consultative architects. B8"(/,#9#'G$)*%;<'#$;#() In this model of architecture, the architects act in a consultative role. Rather than making all of the decisions, they delegate as much architectural decision making as possible into the teams, Copyright 2012-2013 Eliassen Group, All Rights Reserved

work to make sure that teams get feedback on their decisions, and coordinate the decisions and experiences of multiple teams so that everybody benefits from what is learned regardless of where it is learned. !:C$00$0)*%;<'#$;#() Even better than consultative architects are architect developers that are embedded on teams. This isnt always possible, but is a preferred option to the extent that it is possible. M%$Q/$"#)*%;<'#$;#/%9,)B88%0'"9#'8") Regardless of how you involve architecture in your Enterprise, there should be frequent architectural touch points to insure that everybody is headed in a common architectural direction as and where appropriate.

!"#$%&%'($)*+','#-)9"0)*%;<'#$;#/%9,)!"9C,'"+)7%9;#';$()
N"$)7'$;$)M,8O)9E9)A:9,,)I9#;<)A'R$) One piece flow is a concept from Lean and is a key to succeeding with Agile. One piece flow is exactly what is done when producing a hotfix. The only difference is that one piece flow is an intentional practice rather than something done in reaction to a critical problem. Each story is done as if it was the only thing in the release, each aspect of developing a user story happens in rapid succession, there is as much done in parallel as possible, and each team member focuses on at most one single user story at a time. The result of one piece flow is that the time between when the team first starts working on a user story and when they can ship it fully developed, tested, and documented is very short. The timeframe is generally on the order of a week at most and usually days. It may sound from the name that you can only work on one story at a time when following one piece flow. But really it means that for any story that is being worked on, it is progressing as fast as it possibly can without anybody that is working on it switching between multiple tasks. A good rule of thumb is the number of stories you are working simultaneously should the same as the number of hotfixes you could work on simultaneously without affecting the delivery date of any of those hotfixes. @$(#)?%'G$")?$G$,8&:$"#)1@??6) Test Driven Development supports one piece flow and incremental architecture and reduces the amount of functional, system and integration testing required. Refactoring that is based on the Single Responsibility Principle and testing as soon as possible after coding are both good intermediate steps towards TDD.

K$9")
Lean is a fundamental underpinning of the Enterprise Agility Model. Two of the main components of Lean in the model are Kanban and Cycle Time. S9"C9") In the Enterprise Agility Model, Kanban is implied from initial business idea all the way to production. Work should be smoothly flowing throughout the system.

Copyright 2012-2013 Eliassen Group, All Rights Reserved

!T;$&#'8")I9($0)A-";<%8"'R9#'8") The more that Kanban is practiced from concept to production, the easier it is to keep everything running smoothly. With Kanban, whenever there is a problem anywhere in the organization that prevents the smooth flow from concept to production, corrective action is taken immediately. Rather than focus on regularly scheduled meetings to raise issues, focus on detecting and resolving the root cause of problems as soon as they occur. !"0J#8J!"0)B-;,$)@':$) In this model, Cycle Time refers to the amount of calendar time that it takes for work to move from initial business concept all the way to production. Measuring, visualizing, and broadly distributing this information is a vital component of overall success. If the cycle time is very high, sustainable progress towards Enterprise Agility is unlikely to take hold. Focusing on endto-end cycle time acts as a forcing function, helping the organization set transformation priorities. The priority of transformation activities should be directly proportional to their impact on reducing cycle time. A typical starting point for end-to-end cycle time is generally on the order of a year or more. A good set of progressively aggressive goals is: one year, six months, 3 months. Note that while end-to-end cycle time will likely have an impact on the frequency of delivery, they are not directly related. You may have a 3 month cycle time and daily delivery. ='"':'R'"+)D8%E)'")7%8+%$(() This should be implemented wherever possible, but especially at the team level and also at the funding level. Whatever vehicle your organization uses for funding, whether it is projects or MVIs, you should ideally have only as many in progress as you have teams to fund them. For instance, if you have 4 teams, you should strive to have no more than 4 projects or MVIs in progress at once.

7%80/;#)=9"9+$:$"#)
Product management is the process by which new initiatives are created in order to meet the needs of markets or customers, prioritized, managed, and implemented. In this model of Enterprise Agility, product management involves the following components. K'"$)8>)I/('"$(()1KNI6)K$90$%() This may be one or more business stakeholders and/or a product manager. In any case, the LOB leaders are responsible for setting the priorities and funding levels within their own LOB and working with other LOB leaders and executive management to negotiate priorities and investment levels. KNI)I9;E,8+)9"0)!&';() The main output of the LOB leaders are LOB Epic Backlogs . This is then used to drive the program level. Product owners at the program level in partnership with their LOB leader(s) then work to break down epics into the program level backlog which is comprised of a combination of Epics and User Stories. @$9:)K$G$,)I9;E,8+() The product owner for a given team is responsible for the team backlog. This backlog is created from content take from the program level backlog that is appropriate for their team. The product Copyright 2012-2013 Eliassen Group, All Rights Reserved

owner works in conjunction with other product owners in their program and the LOB leader(s) to make sure that their team backlog is as supportive as possible with the overall LOB goals and the needs of the other teams in their program.

M/"0'"+)9"0)P"G$(#:$"#)
The most significant value that comes from Agile is responding to new information and producing something different from what was originally planned, whether it is changing requirements or lessons learned while attempting to frequently produce working software. Fully supporting Agile requires changing your funding and investment models. The main idea is to have a flexible model. Here is a couple to choose from. B9&9;'#-)I9($0)P"G$(#:$"#) With capacity based investment, funding is managed at the product portfolio / line of business level. The amount of funding determines the number of teams dedicated to a line of business or product. Ideally, funding levels can be changed at any time, but in general review and adjustment is done at least quarterly. While funding determines the amount of effort that can be applied to a program, the actual work that is done is determined by the product management team within that program. ='"':/:)U'9C,$)P";%$:$"#)C9($0)P"G$(#:$"#) On a regular cadence, such as once per iteration or once per quarter, the investment community gets together and prioritizes the next MVIs from each area within their purview against each other. For instance, if within a given funding source there are 5 areas that compete with each other for funding and there are 2 team which service the requests, the next MVI from each of the five areas are ranked against each other and the next MVI for each team is chosen from the MVI backlog as each team finishes their previous MVI.

?$;8/&,$0)*;#'G'#'$()
There are some Agile practices which are widely recognized as beneficial, but are often practiced in a manner that needs to be adjusted for Enterprise Agility. These are: regular planning, retrospectives, and reviews. When practicing Enterprise Agility, these activities need to be done asynchronously. For instance, when practicing Scrum, retrospectives are coupled to the iterations. For Enterprise Agility, retrospectives need to be decoupled from iterations so that they can be scheduled to coordinate with cross-team activities such as cross-team retrospectives. Another activity that Scrum teams naturally decouple from iterations is planning. Many Scrum teams hold weekly backlog grooming sessions which are essentially mini planning meetings.

=/,#'J@$9:)A-";<%8"'R9#'8")
B8:&9#'C,$)P#$%9#'8")K$"+#<() If there is more than one team using iterations, then those teams should each pick an iteration length of 1-4 weeks and make the start and end days the same for all. There are a couple of special cases. The common synchronization period across all teams should be no more than 4 weeks. Therefore, teams should only do 3 week iteration lengths if nobody else is doing 2 or 4 week iteration lengths. Otherwise, the common synchronization period could be 6 or even 12 weeks!

Copyright 2012-2013 Eliassen Group, All Rights Reserved

A#9"0/&)8>)A#9"0/&() For each interdependent team that is working towards a common purpose, after they have their individual stand-up meetings, they then send a representative to a standup of standups which serves the same purpose of the team level standup, but for the larger initiative. M/,,)7%80/;#)F$G'$O) After each team does its individual product review, there is a full product review. This is usually organized by whoever is responsible for the overall program from a product perspective. F$#%8(&$;#'G$)8>)F$#%8(&$;#'G$() For the same reason it is useful to have a team level retrospective, it is good to have a retrospective of retrospectives made up of representatives from the teams that are working towards a shared purpose. The retrospective of retrospectives is held after all of the team level retrospectives have been held. D$$E,-)18%):8%$)>%$Q/$"#6)I9;E,8+).%88:'"+) Regardless of whether a team uses iterations and regardless of iteration length, all teams do backlog grooming at least once per week. Also, backlog grooming replaces iteration planning.

!:C$0)A&$;'9,'R$0)AE',,()?'%$;#,-)P"#8)#<$)@$9:()
Release engineering Operations Software Configuration Management Test automation Infrastructure Production support

Whenever this cannot be done, create Agile teams for the specialized skills teams.

N%+9"'R9#'8"V)=9"9+$:$"#V)9"0)@%9"(>8%:9#'8")
?$,'G$%-)I9($0)=9"9+$:$"#) Management and organizational structures are oriented around delivery rather than function. That is, instead of management that is focused on specific functional areas, management is focused on delivering business value within specific lines of business or products. In this model, function-based mentors are still needed, but the roles of manager and function-based mentor are separated. ?$,'G$%-)I9($0)=$#%';() Delivery based management depends on delivery based metrics. !(;9,9#'8").%9&<) The escalation graph is the logical extension of the idea of a stand-ups and retrospectives from the team level all the way up to the executive level. One of the main purposes of the team level stand-ups and retrospectives is to surface, resolve, or escalate impediments. Individuals surface, resolve or escalate impediments that they run into on their own to the team level. Traditionally, the next step is that any impediments that the team cannot resolve themselves the Scrum Master takes responsibility for. But just because they take it doesnt mean they can do anything about it. Copyright 2012-2013 Eliassen Group, All Rights Reserved

The idea behind the escalation graph is that there should be a well known and well established path to escalate impediments as high as needed in order to resolve the impediment as rapidly as Enterprise Agility requires. A common pattern is to have all of the Scrum Masters in a program meet together in their own stand-up, often called a Scrum of Scrums immediately after all of the stand-up meetings in that program have completed. Regardless of how it is implemented, an escalation graph provides a path for impediments to be raised from the individual level all the way up to the executive level within the same day and to be resolved in a timely manner. There are actually two escalation graphs; one that originates with the daily stand-up and one that originates with team retrospectives. A graph is recommended rather than a tree because sometimes resolving an issue requires an escalation up and then communication back down. The purpose of establishing a graph is to encourage the creation of horizontal communication paths between cooperating teams. In Enterprise Agility, escalation is done by way of representatives. This is often a Scrum Master, but can be any person or group of people designated by the team to represent the needs of the team on a case-by-case basis. .8G$%"9";$V)B8:&,'9";$V)B8"#%8,() Governance, compliance, and controls all basically boil down to a list of controls. To achieve Enterprise Agility, focus on the controls themselves rather than their current implementation. Rather than trying to simplify the current implementation of a control, create a list of controls and then consider from scratch how to implement the control in an Agile context. It is unlikely that you will be able to change to the Agile implementation overnight, but having the list gives you a goal to head towards.

*+',$)@%9"(>8%:9#'8")
*+',$)N>>';$) The Agile Office is the team of people that are primarily responsible for coordinating the Agile Transformation within the organization. The Agile office is itself an Agile team. In addition to the roles listed in the Agile Office Practices section below, there should also be an executive champion, and somebody that is well versed in change management. F$;8::$"0$0)*+',$)N>>';$)7%9;#';$()
E&086-#'07(%&' B-&61';"5#%&FG0"-$' H&"(590&1"#*0(',"-./0+' I5%&'5#0&*%5' !%#&052%-#*4%' J1%&+%(#'8%5*+(' G"&8'7"//'>2$)5*-"/'0&'%/%-#&0(*-?'

N&#'8"9,)*+',$)N>>';$)7%9;#';$()

Copyright 2012-2013 Eliassen Group, All Rights Reserved

K0&.'*('2&0+&%55'/*1*#5' H%"1'(0&15' L%9*(*#*0('09'&%"8)' L%9*(*#*0('09'80(%' B#"(862'1%%#*(+5'

B<9"+$)=9"9+$:$"#) Enterprise Agility wont happen over night. There will be many obstacles and there will be strong resistance to change. In order for the transformation to succeed, you will need to follow good change management practices. The Kotter Change Model is the recommended model. !:$%+$"#)?$('+") Strongly related to good change management is the concept of Emergent Design. Just as with software development itself, an Agile transformation will go better when making incremental changes and discovering the best solutions as you go. Dont plan to implement all of the pieces of the Enterprise Agility Model at once. It is good to have a plan, but treat the transformation the same way that you would any Agile project. Do just enough planning, get started, inspect and adapt. @<$)*+',$)=9#/%'#-)=9#%'T)@88,) It is hard to manage what you cant measure. A common problem in Enterprise Transformations is that "Agile" often means something different to everyone involved. Without a clear understanding of the goal, it is hard to set direction, measure progress, or achieve success. Compounding this problem is the fact that going Agile is typically perceived as something that mostly just effects the Agile team members, not the whole ecosystem including the folks on the business/product management side. The Agile Maturity tool can be used to set transformation goals, monitor progress, and get everybody on the same page regarding Agile including: Agile Coaches, team members, managers, and senior leadership. This tool has also been used in many other creative ways such as to focus retrospectives and to help people at all levels do a self-assessment of their own understanding of Agile so as to encourage self-paced learning and open people up to learning from folks that may have more Agile experience. The tool is a spreadsheet with a section for describing the organization as a whole and a section for describing individual teams. There are Agile indicators for each section and each indicator ranges from a 0 (impeded) to a 4 (ideal). Each cell in the matrix contains a simple English explanation of what it means to be at that level for that indicator. The goal is to get as many indicators to a 2 (sustainable) as possible. This helps the organization understand when they are over the main hump of adoption so that they dont stop investing in the adoption too early. If not enough indicators get to the sustainable level, the organization will likely backslide to its old ways. All of the practices listed in this document are part of the criteria in the Agile Maturity Matrix tool.

Copyright 2012-2013 Eliassen Group, All Rights Reserved