What is Agile

Slide 5 - Miriam-Webster Definition of AgileThe group of developers that coined the term “agile” for their adaptive methodologies did so with thought. Both definitions embody the practices and actions outlined in the methods. “Agile” is intended to describe the actions of the team (definition 1) and the team mentality (definition 2)

Slide 6 – Definition of Agile Software Development[Agile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.

Slide 7 – Agile ValuesIn February of 2001 a group of 17 like minded software engineers gathered to have some fun and talk about a better way to develop software. All of these engineers had published adaptive methods to develop software. The common thread that brought them together was a loathing for documentation driven heavyweight software development processes.

Through these discussions they came up with a mission statement (Manifesto for Agile Software Development) and 12 core principles that were evident in all of their methods. The mission statement was about changing the paradigm of what made software development work.

[We are uncovering better ways of developing software by doing it and helping others do it]. This opening statement says a lot about the core mentality of the group and also tells us why after much resistance the industry is coming to except these practices as “a better way”. They were saying that they are not process people who theorize about method. They are engineers who learn by doing. They learn from their own success and failures. They learn from the success and failures of others. They want to help the industry, and by doing so will become better for it.

At the end of this mission statement to change the paradigm of software development they say “while there is value in the items on the right, we value the items on the left more”. This concession about valuing the items on the right indicates that there is an understanding of the business drivers that brought about the use of document driven heavyweight software development processes. They want to let people know that what they were doing was not wrong; there was simply a better way to do it. Unfortunately they also proclaimed themselves “organizational anarchists” which often lead to this last statement being overlooked.

[Individuals and interactions over process and tools] Software developers are people, not just cogs in a machine. They are creative, more so when they are satisfied by and excited by their work. As people, our communication method of choice is face to face conversation. More is conveyed with less effort. In conversation you usually understand more than the words. You can infer intent and motivation. You can more easily determine sincerity and honesty.

[Working software over comprehensive documentation] In a waterfall project, elaboration and design phases can consume half to two thirds of a project budget. It creates an exhaustive amount of documentation that has no chance of living past the end of the project. This has a significant cost, but no substantive value.

[Customer collaboration over contract negotiation] again the wording was chosen carefully. Collaboration is working together toward a common goal. This is a “Win, Win” scenario. Negotiation has a winner and a loser. When it comes to long term projects, you don’t even get to find out who wins and who loses until the end of the project. Contracts are a necessary part of the business world and will never go away. The intent is that the contract should define the limits of the transaction and that collaboration should define the endeavor itself.

[Responding to change over following a plan] Simply put, developing software and delivering software to a customer is an evolutionary process. If you define everything up front, and then limit yourself to that definition, you will end up with a product that is not as useful as it could be, possibly incomplete, or worst case not even usable. As a side note, this paradigm statement is what turns many experience practitioners away from Agile. To many, the “plan” is the bible to the religion name project. Make no mistake; every agile method has planning mechanism. The mechanism differs from predictive methods (waterfall, prince) in that it actually plans for change.

Slide 8 – Agile Principles[Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.] Collaborate with the customer. Build and show them the resulting product. Get their feedback and continue.

Slide 9 – Agile Principles [Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.] Software development is an evolutionary undertaking. When you give someone a tool, you don’t just satisfy a need, you create a new one. Business is volatile. What is important today may not be important tomorrow and vice versa.

Slide 10 – Agile Principles [Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.] Continued thought process from the first discipline emphasizing short feature delivery cycles. Working software needs to be tangible and usable by the customer.

Slide 11 – Agile Principles [Business people and developers must work together daily throughout the project]. To maximize the value of agile processes, the customer must be part of the project. That is how “collaboration” occurs. It also supports micro iterations during development of a feature to help ensure it meets a specific business need.

Slide 12 – Agile Principles[Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.] This relates to “Individuals and Interactions” in the manifesto and to self-organizing, cross functional teams in the definition of Agile Software Development. This is a key concept in productivity gains. Micro management is a productivity killer. Instead it asks leaders to spend their time and use their clout to clear the path and remove impediments. Word of Caution: It is also self serving and one of the most misquoted principles as it is often used as an excuse to lengthen iterations and reduce inspection.

Slide 13 – Agile Principles[The most efficient and effective method of conveying information to and within a development team is face-to-face conversation]. Again this related to Individuals and Interactions. Refer to slide 7. Many people take this to mean that teams that are not co-located cannot be successful. While it takes more work, and may require a bit more documentation, distributed teams can have similar success with good discipline. In addition, video conferencing is available in many forms with a fairly low price point. It is an acceptable substitute when co-location is not possible.

Slide 14 – Agile Principles[Working software is the primary measure of progress.] See slide 7 “working software over comprehensive documentation”.

Slide 15 – Agile Principles[Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.] Short iterations or cycles maintain a sustainable level of urgency (reduced procrastination) and also work to limit “technical debt” that can build up over the course of a long phase or project.

Slide 16 – Agile Principles[Continuous attention to technical excellence and good design enhances agility.] While not explicitly stated, this is a reference to object-oriented design practices. Designs with loose coupling and high cohesion are easier to refactor and accept changes. Use of patterns makes designs more consistent with better understanding across a team.

Slide 17 – Agile Principles[Simplicity – the art of maximizing the amount of work not done – is essential.] This has a dual meaning. The first is that we shouldn’t be doing peripheral things as part of the software development process that do not have residual value. The second is that we should only be working on the highest priority features instead of on bells and whistles that may never be used. This directly impacts the productivity and value delivery of the team.

Slide 18 – Agile Principles[The best architectures, requirements, and designs emerge from self-organizing teams.] The more people who can help design the system the greater number of good ideas that get incorporated in the design. This is also based on the OOP design practice of using CRC cards. CRC stands for Class, Responsibilities and Collaboration. The idea is that each object or potential object is represented by a card. Through the design discussion the cards are placed on a table to discuss organization and interaction. This is an iterative process to add new features to the current design as the product emerges and evolves. It also helps to identify any refactoring that is needed.

Slide 19 – Agile Practices[At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.] This reflects that adaptive / agile methods are not just about evolving and creating the product, but also about evolving the method or process.

Slide 20 – What Agile is not.Many people turn to Agile to solve all of their issues. While agile is very good at highlighting issues due to its inherent transparency, it does not directly resolve anything. As an example, if there is a lack of trust or political friction between an IT unit and its corresponding business unit or customer, the agile process will actually magnify the issue. Once the issue is recognized for what it is, the practice of adapting the process / relationship through retrospective must be used. This is not easy. These types of issues often block or slow the implementation of agile because many people tend to blame agile for the issue rather than recognize that the process is simply highlighting a systemic issue. The other primary misconception is that agile does not have any rules and is tantamount to a free for all in the IT area. Any implementation of agile without oversight and leadership could turn into a free for all, but that is a symptom of a loose undisciplined implementation. Discipline is a key underpinning to all methods. Turning these disciplines into habits is part of any teams maturation.

Why Agile?To understand why moving to an Agile Development method may be a good idea for your team or organization, you first need understand a bit about engineering methods in general and then understand what brought you to your current state. Once these questions have been answered you can look at your current environment and build a case for making (or not making) a change. This section covers some of the basic reasons method usage has changed over the relatively short lifespan of the IT industry and will highlight the perceived benefits of using agile based on industry norms (which may or may not apply to your team or organization).

Slide 22 – Understanding Engineering MethodsThere are two primary method types that most engineering methods fall into. They are referred to as Predictive Methods and Adaptive (Empirical) Methods. Both methods lead to the creation of a product, but go about it in very different ways.

Predictive methods thrive when the product is a known quantity. Design and build activities are distinctly separate. These are the attributes of a predictive method:

Fully definable and stable requirements / inputs Codified standards or rules Stable interactions Stable toolset Repeatable output Quality of output relates directly to the consistency of the process. Engineering practices that use predictive methods include:

o Mechanicalo Civilo Industrial

A great example for applying a predictive method is building a bridge. We can know with certainly the span the bridge will have to cover. We can know the geological make up of both sides of the span. We can anticipate traffic types, flows and patterns that will use the bridge. We can anticipate any traffic that may need to pass under the bridge. We can anticipate environmental conditions that the bridge will be subjected to. These are all definable and stable requirements or definable stable interactions for the bridge. It’s also good to point out that if any of these things change drastically in the future, the bridge will most likely need to be replaced rather than updated. Engineering standards for bridge building are well established (codified). These standards specify materials and design attributes based on a limited number of requirement variables. Resulting designs are very specific and if built multiple times, the product would turn out exactly the same. If designed multiple times, the products would be very similar in nature (not considering aesthetics).

Adaptive methods thrive when the product is an unknown quantity or is anticipated to continuously evolve. The product definition, the product design and the product itself emerge simultaneously. These are the attributes of an adaptive method:

Emerging Requirements Fluid Standards or Rules Changing Interactions Emerging Toolset Variable Output Quality of output relates to the flexibility of the process Engineering practices that use adaptive methods include:

o Chemicalo Genetico Agile Software Development

Comparing adaptive method attributes to software development results in compelling parallels. In taking on a software development project, we typically have a clear high level vision of the product with a limited view or understanding of the details. Some would argue that if software is being developed to support an entrenched business process that both the vision and details are well known. I submit that any effort to create a supporting piece of software will cause the process to change. In most cases changing / streamlining a current business process is part of the value statement for a software product. Hardware, operating systems, development languages, IDEs, security mechanisms, integration protocols and development practices are rapidly evolving. In most cases by the time we update a toolset the next generation or version of the tool is in development or beyond. The only constant in IT rules, standards and toolsets is change itself. Integration channels, especially integrations to external data or systems, are also constantly changing. These changes are in many cases out of our control. If quality goes beyond “bug free” and extends to usability upon delivery or over time, the quality based on flexibility model fits as well.

Slide 23 – Potential benefits of using an adaptive methodAny method that focuses on reducing unneeded artifacts and working primarily on critical features will reduce cost and time to market. When a method puts focus on flexible design, it extends the lifecycle of the product by allowing the software to evolve with low cost modifications instead of costly large rewrite projects. An adaptive method alone does not build trust with your customer, but all agile methods specify collaboration in determining what is needed with empirical examination of the product as it unfolds. This builds trust and encourages the customer to take ownership in both the project and the product that is delivered.

Slide 24 – Software Engineering Timeline

The 40’s and 50’s brought about the first fully electrically powered computers, the codes used to program them, and finally development languages that paved the way for mainstream computing. During this period, programmers were highly skilled and rare. Most being mathematicians and scientists. These programmers used adaptive scientific method to create and implement their codes and to create the first programming languages that would make programming attainable for a broader skill set.

In the 60’s and 70’s, business use of the computer became main stream for large organizations. At this early stage the perceived uses for computers and programs were narrow and straight forward. Because of this, predictive methods were employed to understand a narrow set of requirements and then implement them. The lifecycle of computer programs was very long in comparison to the lifecycles of today. This led to the specification of the predictive methods (waterfall, prince) which became the universal method to build software for business. Another key to the evolution of software development started in the late 60’s. The concept of Object Oriented programming was being contemplated in programming languages. Many agree that the first fully object oriented language was Smalltalk, released to academia in 1972 and to the general public in 1980.

The 1980’s became the threshold to the current digital age we live in. The adoption of Object Oriented design started to proliferate and evolve. Computers started to get smaller and more powerful. Communication networks started to become faster and more complex. Use of predictive methods continued in the business world with projects becoming larger and larger as additional uses were considered.

The 1990’s brought about what many refer to as the digital revolution. The internet and personal computing became mainstream as the price points for technology started to drop. The potential uses for business and personal computing went through the roof. With more possibilities the life cycle of software started to become shorter. The cost and time to create and deploy software using predictive methods became very large considering the shortening lifecycles of the products. Tighter controls and rigidity were added in an effort to justify the rising costs.

As part of this revolution, the use of Object Oriented Programming (OOP) became main stream. Software engineers using OOP started to develop adaptive methods that would allow for scalable design and shorten the development lifecycle. These adaptive methods were publicized and debated at OOPSLA (Object Oriented Programming, Systems, Languages and Applications) conferences. A group of these engineers who were developing these methodologies got together in 2001, coined the term “Agile Software Development” and wrote the Agile Manifesto.

Entering the 21 st century , the battle between Agile and Waterfall heated up. The waterfall camp had 30 years of success under their belt… and they held tightly to it. The agile camp kept up a steady barrage as case study after case study emerged showing software could be developed and deployed with less cost, over less time, with a product that meets the user’s needs. Today the use of Predictive methods if falling and the use of adaptive Agile method’s is rising. The tide is turning, not because the agile camp won or presented a better reason for it’s use, but because empirical metrics on agile projects make a compelling business case.

Slide 25 – Summing It Up – See slide

How is Agile done?In order to “do” agile, you must leverage one or more of the published Agile methods, or create your own method adhering to most or all of the agile disciplines. In this section we will cover some of the more popular and emerging methods being used today.

Slide 27 – Agile MethodsThis is a sampling of agile methods that have been published and used to develop software. This list is not exhaustive. A good portion of the methods were conceived and/or developed prior to the coining of the term “Agile”. Remember, adaptive methods are not new to software development. To get a feel for what is covered in the methods, we will review 4 in a bit more detail to include Extreme Programming (XP), Scrum, Kanban, and SAFe. Today XP is often implemented in conjunction with other agile methods. Scrum is the most popular (most used by name) method in use. Kanban was derived from Lean processes and has hit the mainstream. SAFe is a relatively new framework that larger organizations are using to scale other agile methods which are often considered “team methods”.

Slide 28 & 29 – Extreme Programming Values and PracticesExtreme Programming is similar to other methods in that it provides a basic outline of an iterative approach that supports empirical inspections. It differs in that it provides additional detailed specification for team member interaction and Object-Oriented design and development practices. The values outlined in XP go a step further than most of the other methods specifically calling out Courage and Respect in fostering intra team communication and collaborative design and development. The Practices, which are also referred to in the XP process flow, are driven by OOP practices, but can be applied to other design and programming practices as well. This method has a high focus on development quality and the practices if followed with discipline will reduce/or eliminate “technical debt”

Slides 30 & 31 – XP Release and Iteration FlowsThe XP Project/Release level workflow is similar to other agile methods in that it specifies an iterative process. Compared to other agile methods it has less detail on the mechanisms used to manage the information and iterations, but more detail on specific supporting activities like architectural spikes and specific placement of testing around and within the iterative process.

Slides 32 & 33 – XP Development and Collective Code Ownership FlowsAt the Development & Collective Code Ownership levels, XP sets itself apart from other agile methods by specifying some lower level practices where the other methods make assumptions. It specifies with some detail the practice of continuous integration, the design practices of using CRC Cards and Refactoring, and the interaction practices of Pair Programming and Team Reorganization to stimulate quality and break through design/development issues.

Slides 34 & 35 – Scrum Values, Roles and PracticesScrum is the most widely used agile method in use today. In contrast to XP, Scrum specifies more detail around the process of iterations with clearly defined roles, specifications on managing the scope, and details the most important aspects of communication in and around its iterative process. Scrum does not specify detail around the development activities within the iterations and leaves this more open for definition by the team itself.

The values of scrum also align with this paradigm. In addition to Collaboration and Simplicity which align with XP, agile focuses on Transparency, Prioritization and Focus. These values and the practices related to these values drive a team to work on the “right things” and ensure that all parties involved agree on what the “right thing” is. This is why so many teams and organization choose a blend of scrum and XP. Scrum’s primary focus in on doing the right things and XP’s primary focus is on doing things right.

The roles of scrum define collaborative interaction. The product owner is the customer decision maker related to identifying product features, inspecting the features as they are completed, and determining the ongoing priority of and change control of features. The scrum master is a facilitator between the team and the product owner. This role ensures process discipline, protects the team from external influence during an iteration, is responsible for removing any blockers the team encounters, coaches the team, and is the window of transparency into what the team is doing. The “Team” role is generic by design. The method recognizes that a team may include members of varying skills, but requires that team members check their title at the door and collaborate around all activities as equals. Accountability from an external perspective is placed on the team as a whole. Internally the team holds each team member accountable for their commitments.

The primary practices of scrum are also indicative of focusing on the right thing. Backlog management is a continuous process of prioritization, release management determines scope and timelines, sprint planning details the activities for each sprint, the daily scrum ensures the team is effectively communicating, and sprint closeout reconciles the progress of the team after each iteration.

Slide 36 – Scrum Process DiagramScrum specifies two primary mechanisms for organizing work. The Product backlog which contains all features requested for a product at a given point in time. The Sprint Backlog represents the detailed work required to complete items in a given iteration or Sprint.

During release planning a portion of the backlog is designated for the release. At the beginning of each sprint the team works with the Product owner to identify the most important things in the backlog and based on their capacity commits those items to the sprint. The team then decomposes the backlog items into tasks which make up the sprint backlog. The team determines the work breakdown, who the work is assigned to, and how the team will interact on tasks. Following planning and for the duration of the sprint the team meets every day for a 15 minute meeting called a scrum. In this meeting each team member answers 3 questions. What was completed yesterday, what will be completed today, and what if anything is blocking progress. This report is by each team member to the team. In addition to answering the 3 question, each team member is required to re-estimate the remaining work on their assigned and active tasks. This

information is compiled in a chart called a burndown chart indicating total remaining hours on a daily basis. This keeps the team informed at all time of what it will take to meet their commitments by the end of the sprint. At the end of the sprint the team demonstrates its completed work to the product owner receiving approval or feedback which goes back in the backlog. Also, at the end of each iteration, the team convenes a retrospective meeting to determine any changes needed to make the process better. Scrum provides a framework for incremental development and continuous improvement.

Slide 37 – Kanban Values and PracticesKanban differs rather significantly in practice from Scrum, but focuses on many of the same values with additional focus on efficiency and improvement. It is based on lean manufacturing practices. Other agile processes and the agile disciplines themselves assume that teams are comprised of motivated and capable individuals that will figure out how to organize themselves and manage their own work. While Kanban also prescribes self organization for the team, it provides additional tools and feedback to assist the team in doing so.

One significant difference is that Kanban does not have calendar based development iterations like the scrum Sprint or XP iteration. Some believe that this means that Kanban is not iterative, but that is not the case. Kanban simply removes one of the formal levels of iteration. Most agile methods have varying levels of iteration to include the release, the development iteration, and the development of each feature. Kanban removes the development iteration while maintaining the release iteration and the iterative development of individual features.

The backlog management aspect of Kanban is almost exactly the same as Scrum although it may occur more frequently. The method is managed almost exclusively on a Kanban board which represents the standard workflow to get a feature from concept to completion. Think of the Kanban board as a visual representation of a software development assembly line. Step limits are put in place in that development assembly line to reduce bottlenecks in the overall process as well as reducing the amount of work that is “in progress” (also referred to as WIP). Another difference is that Kanban allows that there can always be one piece of work that is expedited. In scrum, the concept is that no work can be added during a formal iteration. Any important item would need to wait until the next sprint. While the formal calendar based development iteration does not exist, the method specifies that the team conduct a retrospective over consistent time periods (once every x days).

Slide 38 – The Kanban boardKanban is considered a “pull” method. When looking at the board you follow the demand from the right side back to the left side of the board. At the top of the board you see limits for each station. Only 6 items can be in the pending bucket at any point in time. Only 3 in the analysis station, only 5 in the development station, 3 in the test station, and 5 in the deploy station. Items in the “Done” portion of a station only move to the next station when the number of items in the next station falls below the limit. Bottlenecks are identified when all item in a preceding station are done with no limit space in the following station. When this occurs we know that there is a process issue, or the team knows to redeploy resources to clear the bottleneck and keep things flowing. Often Kanban boards have one additional row on the bottom of the board for expedited items. Others use color coding to identify an expedited item. The idea being that in any

given station, the expedited item receives the priority and can even be put into a station that is at its set limit.

Slide 39 – Scaled Agile Framework (SAFe)The Scaled Agile Framework is a publicly available framework. It is not a method, but fills a big information gap in scaling agile methods for the enterprise. Most agile methods as written apply best to team level efforts. For larger projects, program and enterprises the methods typically need to be scaled. This framework provides detail based on scaled case studies to help organization do this more consistently. Agile methods do not inherently account for organizational (macro) governance or strategy.

Slide 40 – SAFe Big PictureThe SAFe Big Picture is a high level framework diagram specifying agile supporting activities at the Portfolio, Program and Team level. This governance model focuses on prioritization and strategy for the enterprise using both Agile and Lean principles. In depth supporting information is available at scaledagileframework.com and is freely available.

Slide 41 – SAFe ScrumXP PictureSAFe practices promote cross method implementation as indicated in this team level diagram. The Scrum method is used to organize and manage features and iterations while XP practices are applied within the iterations to drive quality. The use of Team and Program PSI (Potentially Shippable Increment) goals provides for organization strategic alignment.

Slide 42 – Tying it all togetherMany method practitioners tend to gravitate to a single method. In reality each method has strengths, which when combined based on an organizations environment and vision can create tailored and very effective solutions.

When should Agile be used and Who should use it?Many practitioners who have sipped on “Agile Kool-Aid” would tell you that everything should be done with Agile. I’ve heard comments like “Waterfall has had its day, and should go hide in a corner and die.” The truth is that every project should be analyzed to determine what method fits best. There are many applications that are extremely important that never see the light of a user interface. These are typically utilities that do heavy processing or calculation. They are often driven by standard algorithms or codified industry standards. In these cases the stability of requirements, inputs and outputs may play to the strengths of waterfall. The reality is that when it comes to IT, there is no such thing as “one size fits all”. The environment that an IT unit works in also needs to be considered. The relationship between customer and IT, internal IT relationships, and geographic limitations between team members all factor into what method will work best.

Slide 44 – Reasons to Consider AgileThe principles and benefits of Agile methods make for some compelling reasons to apply Agile methods. I’d warn against changing methods for any of those reasons alone. To successfully change, we must understand the change drivers and a generic statement like “It will just work better” may not be driver enough. Change in any form is an expensive proposition, and just like we ask our customers to justify the cost of a change, we need to find a solid justification to change a team’s or organization’s methods. These reasons and justifications need to originate from customer drivers or needs. Uncovering and communicating these drivers can provide a “strength of purpose” that compels all parties to collaborate and face the difficulties of change together.

When basing a change on a need to streamline development processes or shorten the development lifecycle we need to find a legitimate customer driver that supports either or both of these IT needs. Is cost an issue? Does the cost of implementing technology with current processes overshadow the true or perceived benefits of the technology? Does shortening the development life cycle provide our customer with a competitive advantage or does it allow for a faster return on investment? If the answers to these questions are yes, then these are the reasons that should underpin the change.

General process improvement is a common reason cited by change advocates. One needs to understand that general process improvement is often achieved by making very subtle changes over time. If we are going to make larger sweeping changes to the way we do things to kick start process improvement, again we need to uncover business drivers that support the IT need. Is quality an issue? Does my organization loose time/money because of software quality? Is there a perception by our customer that its interactions with IT are a waste of time? How will improving IT processes tangibly impact the services we provide the customer?

These questions lead us to Establishing or Re-establishing trust with our customer. This can often be one of the most compelling reasons for change. However, this reason is based on subjective evaluation. When something is evaluated subjectively, we need to make its questions and goal statements are more granular. What are the parts of our relationship or what are the interactions with our customer that need to improve? We can’t fix everything at once, so identifying these things and prioritizing them will provide a solid drivers and a way to clearly demonstrate improvements. Demonstrating actions and results is how we establish or re-establish trust.

Slide 45 – Change Management ConsiderationsMake no mistake about it. Implementing Agile methods is a change management effort. It will initially cause as much or more discomfort as it makes things better.

Developers are by nature introverts. Most would like everyone to think they are performing magic (“don’t pay attention to the geek behind the curtain”). If a developer or team is used to being “behind the curtain”, it can be very uncomfortable to have their work and process exposed to the light of day.

In most semi-healthy environments, positive and negative accountability feedback stops at the same place in the hierarchy. In a heavily “managed” environment this is often somewhere in the middle management ranks. In a leadership driven environment this often flows all the way down to the team and team members. Most agile methods focus on team accountability, with each team member holding their team mates accountable

for their commitments. Accountability often sounds fun, but turns out to be much more stressful than people expect. Teams and team members that are not used to it, can have a very hard time with it.

If a team or organization is looking to reap all of the benefits offered by agile, then the customer must be an active participant in making the change. This often requires more time or effort than they may be prepared to give. Setting expectations and having the customer understand the benefits of their participation goes a long way toward making “collaboration” a reality.

Collaboration does not come without cost to a customer used to working in a waterfall environment. When a customer is not intimately involved in a project, it is very hard to prove them wrong when they say, “That is not what I asked for.” Or “The team misunderstood what I said.” The truth is that it is very easy for a customer to lay blame for any issue on IT in a waterfall process. When a customer is actively engaged in the development and acceptance of features in an emerging system, everyone shares the accountability of results. This can leave customers exposed and if not handled correctly can lead to a failed implementation.

Tolerance of failure is a difficult subject, at least difficult to discuss. When we talk about being tolerant to failure, we need to speak at the micro level. At the macro level, which I define as strategic, there will never be much tolerance for failure. Failing at the strategic level is extremely costly. At the tactical level, there are often failures. Under a predictive method these failures are often hidden, not because of bad intention, but because we don’t look at or report specifically on individual work items. In an agile environment transparency applies to all levels. We individually inspect each feature as it is completed, and we talk about the individual tasks to create those features on a daily basis. Bringing these micro failures into the light of day means that we now have the opportunity to actively address each issue and proactively make improvements to minimize the issue in the future. If all of a sudden we start beating people up when these issues come to light, the improvement effort will turn into a retention problem.

Last but not least, using agile methods will expose bad habits, practices and relationships. I highlight expose because Agile is not causing these problems, it is simply identifying their existence. This identification is the first step to improvement. It is very easy to blame the process responsible for discovering an issue for the issue itself. This will undermine transparency as a whole and has been the cause of more than one failed attempt to implement agile methods.

Slide 46 – Implementation StepsDetermining an Implementation Road Map for Agile can range from weeks to months based on the size and complexity of an organization. Each bullet on this slide could equate to a phase of implementation, some being done in parallel and other in line.

The first step is to create or hire an expert. Each of these choices has pros and cons. When you create an expert, that expert has intimate knowledge of your organization but lacks experience with Agile in practice. A hired expert will most like bring practical agile experience with a limited understanding of your organization. Agile concepts are easy enough to learn. Learning to understand an organization can be a large undertaking. On the discipline side of things, an internal person will tend to be sympathetic to change

management barriers and may allow certain disciplines to slide, while an external person should be more empathetic and be able insist on critical disciplines.

This dove tails into understanding the current state of your organization. You need to gauge the complexities of your organization and do an honest assessment of your shortcomings to help make the decision on where to get your expert. On understanding the current state in general, you must realize that any map you may utilize to get from point A to point B, is only useful if you know where point A is.

Building a business case is probably the most important step in the process. Any change needs a vision. If you have the time to communicate why you are changing and explain the benefits of doing so, you will encounter less resistance along the way. Your business case will also be your primary measuring stick for the implementation itself. It will establish goals for the implementation that will allow for meaningful inspection.

Find a Champion, or better yet, Champions. So; What is a champion? A Champion is someone who’s area of influence encompasses the scope of your change effort. A champion has the authority to clear your path. Because a full agile implementation has equal impact on both IT and the customer, multiple Champions are typically needed to cover the area of influence needed to ensure success.

Define a pilot implementation… is much easier said than done. People tend to run Pilots in optimal situations. A pilot should never be done on a mission critical project, however it must be a project that will allow you uncover your biggest underlying organization issues or objections. The purpose of the pilot is twofold. We want to prove success, and we want to uncover the biggest and most ugly issues and deal with them so everyone else doesn’t have too. On duration, a 4 month period should be a hard rule for a minimum timeframe. This will allow the pilot teams to gain some maturity and learn the biggest and hardest lessons. The 9 month maximum is more of a guideline. Any change management effort needs to maintain momentum. Going passed 9 months on a pilot will challenge the momentum, but could be offset by other benefits.

There are often many questions on training. How much is enough? Who should attend? Is there a benefit to formal training? Key players should receive formal training and I recommend going out to get the training vs. having training brought in. There is a lot to be said about learning with people that have different perspectives. Key players are the scrum master / project manager, the product owner / business area decision maker, and key senior team members. An overview, or internal training will suffice for everyone else. Training sessions can vary from a couple of days to a couple of weeks. Costs vary by location and discipline.

Slide 47 – Can Agile be implemented without business support?The short answer is Yes…, but you will need to understand that benefits and improvements will be limited. There are also some situations where it is advantageous to exclude the business. If the IT and Customer relations are significantly strained, or if the customer does not buy into the process you may need to limit the implementation to IT practices with the goal of proving that there is a better way. Specific XP practices and iterative development with empirical inspection can occur without customer participation. A project may need to start with a waterfall like elaboration, but design, development and testing can flow through iterations. To make this work you must identify a customer / product owner surrogate. This person should have the knowledge and skill to interpret

requirements from elaboration. This will allow you to build a foundation of trust that will open the door to collaboration going forward.

Slide 48 – How does one choose an agile method to implement?Having used some or all of each of the methods discussed I tend to gravitate towards scrum. The concepts are fairly easy to understand and the list of prescriptive rules is short but effective. My opinion is that is a great place to start. As with all adaptive methods it leaves room for and encourages change which can be anything from adding pieces from other methods, to switching methods entirely.

As stated in multiple places in the presentation, talk to and understand the needs of your customer. Each of the methods has a slightly different focus. If you know which focus is most import, it makes it easier to pick one to start with.

The name of the method you choose is least important. Most organizations eventually find themselves using pieces and parts of many methods. Focus on the agile disciplines and if it suits you, create your own method.

Regardless of what method you use, in some way shape or form you will find that at least a few of the disciplines are already ingrained in your current processes. I have found that if you currently implement 8 of the 12 disciplines, you are well on your way to being “Agile”.

Slide 49 – GovernanceIT governance is the practice of ensuring that IT is working on things that align with an organizations strategy. Most organization have some governance structure in place. Unfortunately none of the agile methods formally address this. SAFe is the first consumable practice that does. If governance is not formally addressed as part of the processes then it needs to be included as part of the work (or backlog). See the slide for a short list of governance and control activities that should be addressed.

Slide 50 – Things to look out for:IT people are creatures of habit and we often allow our successes and failures dictate what we do in the future. The list of fences we create and choose sides on is extensive and the choosing of sides can be a detriment. Java Vs. .Net, SQL Server Vs. Oracle, Android Vs. iPhone/Pad, Waterfall vs. Agile, Scrum Vs. Kanban, Agile Vs. Lean, Open Source Vs. Licensed, Republican Vs. Democrat….

For a profession that is based on and deals in logic, we often throw it away and insist we do what we are used to vs. what we should do. Agile methods are no exception. You will find people that believe agile can only be done “one way”. Being agile is about being flexible. If an “agile expert” refuses to be flexible, then they are not the person to guide you in your implementation.

Some people will tell you that working software is the only deliverable of an agile project. If there are any other deliverables, then you didn’t do it right. In truth deliverables should be defined by the situation. One of the challenges we constantly face is ensuring we do value add activities and ignore non-value add activities. These are different for every project and need to be specified based on the environment.

Multi-tasking is a way of life. It is a very busy world and we all do it out of necessity. In software development, and especially in adaptive and iterative development, we need to minimize it as much as possible. One mistake I often see new team make is to create a waterfall cycle within an iteration for all committed items. A team will spend the first week elaborating, the second week designing, the third week coding, and the fourth week testing. On the surface it seems efficient, but it’s really not. We force our customer to contemplate multiple features simultaneously. We aren’t making the most efficient use of varying skill sets on the team. We are distracting ourselves by constantly picking up and putting down features through these faux phases. Worst of all, we create a risk of missing our commitment on all items in the iteration vs. missing our commitment on one. Keeping in mind that working software is the only thing that has value and work in progress is cost liability, which scenario has the best outcome?

10 items, all 90% complete 9 items complete and 1 not started