Agile for Enterprise Projects August 28, 2012

1. Agile for Enterprise ProjectsAugust 28, 2012 John E. Parker President and CEO Enfocus Solutions Inc. www.EnfocusSolutions.com

2. Webinar Agenda • Agile Adoption and Pain Points • Agile Trends • Implementing Agile for the Enterprise

3. Agile Adoption and Pain Points

4. IT Project Success

5. Waterfall vs. Agile Projects Success rates for waterfall projects are lower than in original 1994 study. This is despitethe big focus on improved project management practices over the last 20 years. Source: Standish Group Chaos Report 2011

6. Major Reasons for Failure of Agile Projects Source: SwissQ Agile Trends and Benchmarks, 2012

7. Agile Pain Points • Capturing requirements • Lack of in-house experience • Lack of automated tests • People spread across projects • Support of agile with a distributed team Source: Accurev Agile Survey

8. Agile Trends

9. Agile Goes Mainstream • According to Forrester Research, Agile development is now mainstream. • Agile is adapting to the workplace. Perhaps the clearest sign of the Agile mainstreaming is the abandonment of traditional SDLC methodologies. • Many organizations are blending Agile and non-Agile techniques and practices to create a hybrid methodology that better fits their needs. • Other changes, such as new team dynamics and the redefinition of roles (such as the business analyst), show the genuine force behind Agile adoption. • It's time for software development professionals to stop sitting on the fence where Agile is concerned. According to those who have successfully adopted Agile, the benefits are well worth the effort. Source: Forrester Research, Agile Development: Mainstream Adoption has Changed Agility, January 2010

10. Agile, Composite, and Cloud • Three delivery trends are changing the way enterprise IT leaders bring applications to market: • Cloud Computing • Agile Development • Composite Applications • These initiatives share three common objectives: cost reduction, higher quality, and faster outcomes. • All three seek to strip the latencies from traditional delivery and provide results that are more aligned with, and more responsive to, the business.

11. Agile Virtual Teams • Choosing to create a team that is not co-located will challenge the team’s ability to follow agile values and principles. • Travel costs, team size, and relocation down-time are three barriers to co-location. • Decreased time-to-market (TTM) and development schedules are two drivers for co-location. • Many parts of the organization have been using virtual teams for some time (sales, supply chain). • Enterprise IT has been working with these business units to make this happen. • Audio/Video Chat, if used properly, can help virtual teams simulate face-to-face communications. Expect to see more virtual teams as more enterprises adopt agile.

12. User Experience (UX) and Agile • Two of the most profound trends driving software innovation over the past 10 years are Agile software development and human centered design (often known as UX in software circles), yet these trends have often moved independently of one another, or worse, been at odds.  • UX (and the broader Human Centered Design movement) is an approach to understanding how people experience and draw value from the interactions they have with computer applications, consumer products, and web and mobile devices.  • The more advanced disciplines of UX help us better understand how to design software in such a way to achieve an extraordinary user experience. This trend has been at the heart of Apple’s amazing run and helped it become the most valuable company in the world. • Agile and UX will grow in dominance, and thus it will be increasingly imperative for companies to do both: implement agile software development processes, while also ensuring that the user experience is tightly integrated and prioritized.

13. Packaged Software (COTS) Delivery and Agile According to Gartner Group, we are starting to see enterprise agile used with package and COTS deployment. • Increased use of agile practices is generating interest in their applicability for package implementation (ERP, CRM, SCM). • The majority of current package implementation methods are sequential in nature, leading to waterfall delivery model. • Package vendors are starting to leverage agile practices, but most of the current agile package projects are client initiatives.

14. Implementing Agile in the Enterprise

15. Agile Development Agile principles were great, and they found a lot of success using these principles and approaches. So, people said, "Hey, let's apply it in our enterprise; it makes sense in smaller companies, so let's use it in bigger companies." Agile was created by software developers for running software product development in small software companies.

16. Don’t Naively Think You Can “Purchase” Agile Adopting Agile requires much more than hiring an Agile coach and purchasing Agile tools. Successful Agile adoption requires: • A culture and mindset shift, the abandonment of orthodoxy • Changes in roles and responsibilities • Changes in governance • Significant changes in development practices (e.g., TDD, Continuous Integration)

17. Complexities of Applying Agile to Enterprise Projects • Corporate Culture. (Agile teams often have difficulty operating in risk adverse and controlling environments) • Size and Complexity of Projects. (agile scalability, domain complexity) • Inability to Build Collocated Cross-Functional Teams.(DBA, middleware, QA, etc.) • Offshore and Outsourced Resources. • Inherited Technical Debt.(It’s easy to apply Agile if you’re building a new system from scratch, but not so easy if you’re working with existing legacy systems and legacy data sources) • Compliance Requirements. (What if regulatory issues–such as Sarbanes Oxley, ISO 9000, or FDA CFR 21–are applicable?) • Numerous Distributed Stakeholders. (Can a single product owner speak for all stakeholders?) • Complex Governance. (PMO, Finance) • Enterprise Discipline.Most organizations want to leverage common infrastructure platforms to lower cost, reduce time to market, and to improve consistency.  To accomplish this, they need effective enterprise architecture, enterprise business modeling, strategic reuse, and portfolio management disciplines. • System Interfaces. (e.g., ERP,CRM) • Coordinating with Non-Agile Teams. (DBAs, Security, Disaster Recovery)

18. The People Aspect of Agile Two of the four manifesto items and five of the 12 principles are people-oriented as demonstrated in the table on the right. People and communications are essential for Agile to succeed.

19. Common People Issues for Agile in Enterprises • The number and location of stakeholders • Creating cross-functional teams with the right skills and domain knowledge • Ability of a single product owner to speak for all stakeholders • Collocation of team and product owner • Use offshore and outsourced resources • Integration with non-agile teams • Domain expertise availability

20. Implementing Agile in the Enterprise • Agile requires a cultural and mindset shift • The mythical Enterprise Product Owner • Mange the Agile portfolio • Implementing Agile in a Waterfall organization is difficult • Since when did developers and business people learn to communicate? • Don’t believe the hype—Enterprise Agile requires documentation • Just-in-time requirements • Sprint Zerois a must for Enterprise projects • User stories are more than a wish-list • Consider nonfunctional requirements from the start • It is important to manage and pay off technical debt • It is essential to know when you are done

21. Agile Requires a Cultural Shift 1. • Key Issues for Most Enterprises Adopting Agile • Self organizing teams • Scrum masters remove impediments and do not manage the team • Upfront documentation required for finance • Sustainable pace • Small batches of work in time-boxed iterations • Close collaboration • Refactoring • Potentially shippable product increments • Defining technically done • Single work queue • Changing roles and responsibilities • Moving Forward • Identify an agile coach • Start with a pilot • Develop a plan for migration • Provide continuous agile coaching and mentoring • Provide periodic Agile assessments to gauge adoption level.

22. Role of the Product Owner The Mythical Product Owner 2. • Defines the project vision • Determines product features • Decides on release dates and release content • Is responsible achieving business objectives (ROI) • Works with team and other stakeholders to gather user stories • Defines acceptance criteria for user stories • Prioritizes the backlog according to business value • Adjust features and priorities at every iteration, as needed  • Accepts or rejects work results • Answers functional questionsfor team

23. The Mythical Product Owner 2. • XP assumes a full-time collocated customer (product owner) that is fully empowered to make all design decisions and has complete domain knowledge for every aspect for the project. • For enterprise projects, this is naive and irresponsible. • Lack of direct user input is the number one cause for project failures. • It is difficult for a product owner to represent all stakeholders on an enterprise project. • Having a product owner serve as a proxy for all other stakeholders is an organizational change nightmare. • It is impossible for a single product owner to have all of the domain expertise to support an enterprise project. • Many product owners are assigned part time and do not devote full time to product owner role. An absentee product owner significantly increases the risk of a failed project. • Without a full-time Product Owner, the Team is often left to second-guess the requirements and the scope of these requirements. It is forced to pick up items from the Product Backlog it feels are more relevant and valuable. The team often makes incorrect assumptions concerning the requirements and delivers the wrong functionality.

24. Manage the Agile Portfolio 3. • Identify and prioritize agile candidates • Assess team skills and capabilities • Assess willingness and mindset of team • Assess product ownership skills • Assess technical debt • Assess external dependencies • Agile may be applied to a number of area but may be difficult • Purchased software (ERP, CRM) • Product Management • Software development • Business intelligence • Realize that some products/services are better managed in other ways

25. Implementing Agile in a Waterfall Organization is Difficult 4. • Although Agile development practices can improve the speed and quality of code, it does not automatically translate to faster delivery of the developed solution or time to market. Getting to market quicker requires agility throughout the delivery process. • This means extending Agile practices beyond the software development process to include and address all interacting and dependent processes, such as operations, legal, support, manufacturing, and business analysis where appropriate. Every step in the lifecycle process can be a bottleneck. • Unless Agile practices are introduced from end-to-end, Agile will just shift the bottleneck to another point in the lifecycle. Sprint 4 Test &Refine Sprint 5 Deployment Sprint 1 Initial Functionality Sprint 3 Additional Functionality Sprint Design& Backlog Load Waterfall project plan renamed to Agile

26. Implementing Agile in a Waterfall Organization is Difficult 4. • Many organizations consider Agile as a solution to their project development problems. They are struggling with long delivery cycles, low quality, and higher costs. Their competition is responding faster to customer needs and changing market dynamics and is releasing new features frequently. They start to adopt Agile in their delivery organization without changing any other part of the project lifecycle. • For example, Finance may require detailed upfront information about the scope, schedule, delivery, and resourcing plan before releasing funds or allocating resources to the project. Often, this even requires a high level design and requirements. • Organizations need to look at their processes end to end and adopt Agile across the organization instead of just during project development.

27. Split Maintenance and Development Lifecycle Implementing Agile in a Waterfall Organization is Difficult 4. • More than 50% of IT budgets go to maintenance—53% to be precise, according to Forrester’s 2011 IT Budget Planning Guide for CIOs. On average, only 29% of the IT budgets are invested in building new products and services.  • One of the main reasons of such high-maintenance cost is the bifurcation that exists in the organizations. This bifurcation leads to suboptimal ways that these organizations plan, run, and maintain their projects. They split project initialization, development, and maintenance budgets. It leads to poor decision making at the project level, which ultimately means higher product lifecycle costs. • This split responsibility across product lifecycle results in: • Low product quality • Higher maintenance costs • Longer release cycles • The product owner should own the product across the whole lifecycle. It is dangerous to split the ownership of the product in to development and maintenance phases (or in several other phases).

28. Theory of Constraints Implementing Agile in a Waterfall Organization is Difficult 4. • Goldratt developed an approach for continuous improvement called Theory of Constraints (TOC), introduced in the book “The Goal.” • Theory of constraints was originally applied to manufacturing but has now been applied to many areas including software development. Agile is loosely based on the Theory of Constraints. • According to Goldratt, the core constraint of virtually every organization is that organizations are structured, measured, and managed in parts, rather than as a whole. This certainly applies to agile development in the enterprise. • The results of this are lower than expected overall performance results, difficulties securing or maintaining a strategic advantage in the marketplace, financial hardships, seemingly constant fire-fighting, customer service expectations being rarely met, the constraint constantly shifting from one place to another, and chronic conflicts between people representing different parts of the organization, to name a few. • Agile considers the team as the constraint for enterprise projects. The constraint is often something other than the team, such as domain availability, QA, finance, or operations.

29. Since When did Developers and Business People Learn to Communicate? 5. • Agile methodologies (XP) require team members to be highly skilled and disciplined. • XP requires an onsite customer or customer team. (This is impractical for most enterprises.) • Communication between business users and software developers is one of the key tenets of Agile, agreed Steve Hardin, ITBE's VP of software development, when I spoke to him Friday. This is why Agile tends to work better for smaller companies with collaborative cultures than it does for big companies with more management layers, he told me. • Development teams are often younger and more energetic in smaller companies. If they have a question, they'll just go ask. In a company where the management structure has more layers, it is a lot more difficult to get feedback from the VP of marketingor the CFO. • Enterprise applications generally involve many types of users with different needs. • Scope creep, mentioned by some of the Slashdot commenters, is perhaps somewhat more commonplace in Agile than in waterfall projects. According to Steve Hardin, more frequent feedback sessions afford more flexibility in adding new features, which can sometimes be a bad thing.

30. Since When did Developers and Business People Learn to Communicate? 5. • Agile does not solve the ongoing problem that users do not know what they really want. Most users have trouble envisioning the business processes needed to attain the desired end state, which makes it hard for them to communicate what they want to developers in a way developers understand. • Not to put the blame entirely on users, many developers think they know more about business processes than they actually do and as a result make many incorrect assumptions. • Larger companies may employ business analyststo serve as a liaison between business users and developers during development projects. Forty-one percent of BAs interviewed by Forrester Research for a 2009 study said they use Agile techniques. Forrester said BAs increasingly will be expected to understand the principles of Agile development. • Communication gaps can also make it more difficult, though not impossible, to use agile with offshore development teams.

31. Don’t Believe the Hype—Agile Requires Documentation 6. • Enterprises do not operate like a small software companies. They have significantly more complexity, such as: • Multiple teams • Globally distributed customers • Offshore development resources • Complex compliance issues • It is sometimes impractical to assemble teams with all the skills needed to complete an enterprise Agile project. • Enterprise projects often involve much more than just software. For example, business process improvement is a part of many enterprise projects • Because of this complexity, more documentation is needed for Agile than for a simple software project with a collocated customer and cross-functional team.

32. Don’t Believe the Hype—Agile Requires Documentation 6. • The subject of deliverables for Agile projects is controversial. Many believe that the source code and system builds are the only things that really matter. Everything else is a work product, that is, something that can be discarded at the end of the project. • For a small Agile project in a small company, focus should be on the source code. Get the system built and move on. • For a large Agile project expected to have a long lifespan in a major enterprise, a few more deliverables will be needed. The list on the next slide provides food for thought.

33. Don’t Believe the Hype—Agile Requires Documentation 6. Final Deliverables • Build Instructions • Change Control (post-production) • Completed System • Operations Guide (Backups, etc.) • Release Notes • Final Source Code • Support (Help Desk) Guide • User Documentation • Database or File System Deliverables • Data Flow Diagram • Data Model Testing Deliverables • Defect Reports • Regression Test Suite • User Acceptance Test Plan Modeling Deliverables • Activity Diagram • Class Diagram • Class Responsibility Collaborator Model • Collaboration Diagram • Deployment Diagram • External Interface Specifications • Flow Charts • Network Diagram • Package Diagram • Sequence Diagram • Use Case Diagram Requirements Modeling Deliverables • Business Rule Definitions • Constraint Definitions • Epics • Stories • Use Cases • Use Case Scenarios • Vision Statement • Workflow Diagrams User Experience Deliverables • User Interface Flow Diagram • User Interface Prototypes Iteration Deliverables • Installation Scripts • Interim System Builds • Source Code Updates • System Architecture Document Source: BrainsLink

34. Just-in-Time Requirements 7. • Just-in-time (JIT) requirements gathering is the process of focusing on defining requirements for the current sprint backlog and developing acceptance criteria for those items. • JIT requirements involve developing only what is required for the current sprint and is done to the level of detail required to enable the team to build the product and acceptance criteria. • JIT requirements are achieved by assigning a business analyst to the team or through requirement sprints if numerous stakeholders are involved.

35. Just-in-Time Requirements 7. Req Sprint 2 Req Sprint 4 Req Sprint 1 Req Sprint 3 Requirement Sprints Dev Sprint 2 Dev Sprint 4 Dev Sprint 1 Dev Sprint 3 Development Sprints • Many organizations are starting to use requirements sprints to get requirements ready for development • Requirements sprints are used to: • Prioritize and groom the product backlog • Develop acceptance/test criteria • Create user centered design artifacts (e.g., wireframes) • Document related business rules • Requirement sprints work similar to development sprints • Daily standup meetings • Requirements review • Retrospectives • Using requirement sprints reduces rework, increases developer productivity, and delivers functionality with higher user satisfaction

36. Sprint Zero is a Must for Enterprise Projects 8. • Many organizations have adopted the practice of using Sprint Zero for project initiation activities. • Many Agilists will tell you that the practice of using Sprint Zero is not agile and should not be done. Ignore this advice—Sprint Zeros are essential for using agile in the enterprise. Not starting with Sprint Zero will create so many impediments that a whole team of scrum masters will be needed to remove them causing such deep frustration that the project will probably be cancelled. • The practice of performing detailed requirements gathering, upfront architecture and design work, and creation of project plans, including resourcing and scheduling in Sprint Zero, is not Agile and should be avoided.

37. A Sprint Zero is a Must for Enterprise Projects 8. If you can’t state the problem, how can you define the solution? • Start with defining the problem • Next, define the Concept • Prepare the business case • Identify and document project constraints • Conduct user research to identify the users and stakeholders • Create personas for each user class • Identify user needs and goals by modeling user needs • Define high level features to address the user needs

38. Sprint Zero is a Must for Enterprise Projects 8. Personas

39. Product Vision and Roadmap A Sprint Zero is a Must for Enterprise Projects 8. StakeholderPersona StakeholderPersona Problem Statement Solution Vision StakeholderPersona StakeholderPersona Objectives StakeholderPersona StakeholderPersona Constraints Release 1- Fall 2012 Release 2- Spring 2013 Release 3- Fall 2013 Feature Feature Feature Feature Feature Feature Feature

40. User Stories are More than a Wish List 9. • User stories, as opposed to requirements (which by common definition represent something the system must do to fulfill a business need or contractual obligation)are brief statements of intent that describe something the system needs to do for some user. User stories are negotiable • User stories are not functional specifications and are not use cases. • As commonly taught, the user story often takes a standard user-voice form of the following: As a <user role>, I can <activity> so that <business value>. • User stories consist of the following three elements: • Card • Conversations • Confirmation (or Criteria) Source: Leffingwell, Dean (2010-12-27). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise

41. User Stories are More than a Wish List 9. A user story is written in the form of: As a <<User Persona>> I want to <<perform this task>> so that I can <<Achieve this business benefit. StakeholderPersona Fe a t u r e Conversations (Threads and Comments) Acceptance Criteria User Story Attachments (Wireframes, models, etc.) Action Items

42. User Stories are More than a Wish List Wireframes and Prototyping 10. • The real strength of the wireframe lies in their ability: • to be a communication tool, used during a workshop to facilitate discussion with developers, testers and business actors (Product Owner). • to be created collaboratively, in order to enable everyone on a team to have a shared picture • Wireframes help generate feedback to see potential problems with an interface and to clarify conditions of satisfaction. • Rapid and valuable prototyping in order to foster collaboration and elicit rapid feedback is a must for Agile projects. • So, wireframes help to generate feedback, to see potential problems with an interface, and to clarify conditions of satisfaction. The most effective methods for wireframes are: • Paper prototyping done collaboratively • Quick collaborative wireframes on the whiteboard • Rapid sketching activities using tools such as BALSAMIQ

43. INVEST User Stories are More than a Wish List 10. • Independent—User Stories should be as independent as possible and minimize dependency on other user stories to deliver full value. • Negotiable—User Stories are not detailed specifications. They are high level descriptions of features for the team to discuss with the story owner and collaborate to clarify the details near the time of development. • Valuable—User Stories should be valuable to the user (or owner) of the solution. They should be written in user language, not technical jargon. They should be at the feature level of description, not the task level. • Estimable—User Stories need to provide enough information to estimate level of effort, without being too detailed. • Small—User Stories should be small and succinct. • Testable—User Stories should be worded in a way that provides for a testable result, i.e., not subjective, clearly defined, and stating true or false outcomes.

44. Enfocus Requirement Suite™ Agile Model Solution Scope Product Backlog Sprint Bundle User Story User Story User Story User Story Problem Statement User Story User Story User Story User Story Solution Vision User Story User Story User Story User Story Persona Persona Nonfunctional Req. Nonfunctional Req. Persona Persona Nonfunctional Req. Nonfunctional Req. Feature Feature Release Bundle Feature Transition Req. Transition Req. Feature Transition Req. Transition Req.

45. User Stories do not Work Well for Functional Requirements 10. • User stories do not work well for nonfunctional requirements. Employing user stories is like forcing a square peg in a round pole. • Non-functional requirements relate to qualities of the system that cut across user facing features, such as security, reliability, and performance. • The difference from functional requirements is that these qualities must be present throughout the system rather than delivered in one-shot like a user facing feature. • NFR can be grouped into: • Execution qualities, such as security and usability, which are observable at run time. • Evolution qualities, such as testability, maintainability, extensibility, and scalability, which are embodied in the static structure of the software system. • Make sure that you engage with technical stakeholders in your organization, such as architects, user experience designers, and operations teams. These people can help an agile team spot NFR that are not captured in your user stories. Consider nonfunctional requirements from the start!

46. It is Essential to Know When You are Done 11. • Agile projects have ceremonies (sprint planning, release planning, sprint retrospective, etc.) and metrics (sprint and release burndown charts) designed to ensure that the project is in a healthy state. • Unfortunately, many Agile projects fail even after following all the ceremonies religiously. Why? One of the primary reasons is that they are not able to deliver value to the customer at the end of each sprint. • They deliver a product at the end of each sprint, but not a product that is potentially shippable. Here lies the root cause of failure. The software these projects deliver at the end of each sprint is half tested, half documented, half refactored, and only half ready for release. • An explicit and concrete definition of done may seem small, but it can be the most critical checkpoint of an agile project. Without a consistent meaning of done, velocity cannot be estimated.

47. It is Essential to Know When You are Done 11. User Story • Unit tests written and executed • Code is reviewed • Functional tests passed • Acceptance tests passed • Code meets standards • Code comments updated • Published to Dev Server Sprint • Demo conducted • Acceptance tests passed • Accepted by product owner • No compile warnings in code • Bugs committed in sprint resolved • Deployment docs updated • Release notes updated • Code repository is tagged • Code is reviewed Release • Released to staging server • Deployment tests passed • Deployment documentation delivered • Integrated performance test passed • Build requirements met

48. Manage and Payoff Technical Debt 12. How Technical Debt Occurs • Sacrifice ofgoodsoftwaredevelopmentpractices—“We don’t have time to refactor now. We will deal with this later.” • Domain knowledge—“Now thatweknowmoreaboutthisproduct, weshoulddosomethingaboutthatcodeweshipped” (Sprint 3 or 4). • Prudent design decisions—(First Sprint) “Let’s use this framework now and adapt to a better framework sometime in the future.” Impact of Technical Debt

49. Manage and Payoff Technical Debt 12. • Legacy systems usually have a significant amount of technical debt. • Before migrating to Agile, technical debt should be assessed through some application rationalization process. • In many situations, it is wise to pay down technical debt before delivering new functionality. • Technical debt should be carefully managed going forward.

50. Request a Demo or Free Trial www.EnfocusSolutions.com • Visit our Web Site • Request a demo • Get a Free Trial • Ask for a PDF of this deck