Your SlideShare is downloading. ×
Blended Agile
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Blended Agile


Published on

Published in: Technology, Business

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Value-driven: two levels
    values that are explicitly identified in the Manifesto values & principles and those that drive how the team works together
    values of the features for the customer
    Traditional environments frequently (not always)
    discourage people from feeling responsible for anything but their own work/area;
    Inhibit true teamwork and encourage white-knightism
    Leadership in Agile
    More Situational style leadership employed
    PM (if there is one) becomes less a master of tasks; keeps a broader view and manages external communications (very Liberating when you realize it’s not all on your shoulders!!)
    Leadership is shared or rotated among team, giving them a sense of ownership and empowerment, and also teaching them
  • Agile works because by its very nature it addresses the reasons that projects fail, and it focuses on building healthy teams and creating environments which support and sustain them
    That’s the Secret Sauce of Agile!!
    It’s also why you hear proponents say that you have to follow “all” of the practices of a particular agile method….because in that way you will maximize your successes….the more you don’t use, the more impediments will remain hidden and the more risk will remain in the environment.
    Connectivity = how connected people are to their work and to each other; connectivity of a team is highly correlated w/ it’s performance (i.e., high performing teams have high connectivity; Meta Learning Model by Marcial Losada;
    other factors =
    Inquiry/advocacy; how much people ask vs talk
    Positivity / negativity; how much people are positive vs. negative
    other / self; how much people are focused on others vs. themselves
    Why doesn’t Traditional work –
    It can… the right circumstances, with the right leadership
    But generally, the right circumstances don’t exist, and it’s very hard to succeed
    The environment, context, structure, and culture limit options, which limits the ability to respond to changing circumstances (e.g., if you’re doing serial development, it’s hard to switch gears)
    Sometimes Agile DOESN’T Work – Why not? –
    For the same reason Traditional doesn’t – the environment / context is not conducive; but even then, agile isn’t the problem…..but it will highlight the problems more quickly, make them visible sooner
  • It seems like common sense, so why isn’t it easy…..because people are involved….and people aren’t easy
    Roles / Responsibility changes: People often define themselves by their jobs; when they no longer do their job in the same way, they can become lost for awhile until they learn to see that they still have worth and value (e.g., analysis is still valuable even if a particular document is no longer produced)
    Interaction Changes: No more “throwing things over the wall” to the next functional phase; People must take ownership, they can’t hide in obscurity or the mediocrity of the process…and that can be scary for some people
    Processes that may change: Development (pair programming); Testing (moved forward); sign-offs (bye-bye)
    Resistance: people have different tolerance levels for change, but for many people there is some element of fear; that fear is because change always brings destruction along with creation; it destroys part of our old life (one we were comfortable with, even if we weren’t happy with it), and creates something new in its place, something unknown and unfamiliar to us.
    George Bernard Shaw said: “Progress is impossible without Change”…..Terry Neil wrote, “Change is a door that can only be opened from the inside.”
    For true and lasting change, it has to start from within….and that’s why agile isn’t easy.
  • It’s a JOURNEY
    These are not all the possible steps on the journey (e.g., these represent the practices, but not the values)
    Every step you can successfully take and maintain will get you closer to the goal
    Remember to THINK….WHY are you doing it
  • Some believe those who use agile methods do not follow a plan. This is a misunderstanding. Planning is actually a core principle of agile methods [7]; however, agile teams tend to plan in smaller time increments and more frequently than those who use traditional methods. This distinction has been clarified by the characterization of XP as planning driven rather than plan driven [8]. Planning takes place with both methods, but with agile methods the focus is on the act of planning, rather than a document. Using an incremental life-cycle model is critical because many of the conflicts observed are rooted in the all up-front thinking that comes with the single- increment waterfall model. Incremental thinking is fundamental to agile methods and crucial to bridging the two methods.
    The frequent feedback from multiple spirals can help your risk mitigation visibility and ultimately your project's success.
  • One common misperception of agile methods is that the requirements are not controlled since they are allowed to change late in the game. This is a legitimate concern that could also fuel why a prime contractor might want to keep an end-customer away from an agile subcontractor, but it also demonstrates a fundamental misunderstanding of agile methods.
    As Craig Larman explains, "Iterative and agile methods embrace change, but not chaos
    creep, which often fails to get recognized until late in the project's test phase when the customer starts writing new discrepancies because the product does not meet what they now perceive the requirements to mean.
  • This presentation would include key terms, roles, and responsibilities. Terms unique to the agile method such as coach, tracker, and metaphor [7] would be mapped to traditional terms such as project manager and architecture.
    Key to the presentation is a description of how agile method fits within a traditional project management framework
  • Changes in Requirements and TestingAgile methods discourage the traditional detailed requirement documents in favor of higher level descriptions of business flows, called "User Stories" or "Use Cases."[v] The idea of producing less than exacting requirement specifications can be a cultural shock to an organization that has lived by rigorous and detailed requirement documents.  But Agile philosophy states that since requirements can not be fully known up front, teams should spend time instead developing the requirements as part of the iteration process.  Scott Ambler sums up his experience as follows:
    "My use cases need to be just good enough.  Why does this work?  Because in an agile environment you'll that you don't fully understand what is required, you'll work with your stakeholder to do so, and you'll build something that meets their actual needs.  It's software development, not documentation development."
  • NEXT: Backup Slide – Getting ready for Lean-Agile
  • Transcript

    • 1. CC Pace Proprietary Blended Agile July 15, 2009
    • 2. CC Pace Proprietary What is Blended Agile? • Blended Agile is a term we use to describe a combination of agile practices/techniques integrated with more traditional methods.   • This is generally a result of a scenario where an organization can not flip a switch overnight and move to a full set of agile practices.  • The company slowly initiates agile practices, increasing them over time while integrating with traditional practices that still have value to the organization but are not part of, or sometime might even be in conflict with, agile practices.
    • 3. CC Pace Proprietary Blended Agile • Blended Agile will utilize some of the Agile practices along with other practices from methodologies such as spiral, DSDM, etc. • Blended Agile is not Agile in its purest form. Thus you will not obtain all of the benefits of Agile. • Blended Agile will allow your organization to improve its current practices.
    • 4. CC Pace Proprietary Examples of Blended Agile • Iterative cycles with requirements established several iterations before • Mini waterfall iterations • Reduction of team time together – Scheduling of product owners time on specific days – Working together for a short percentage of time during the day , perhaps just for the daily standup and doing work at your desk – Use of IM • Break project into modules – Low criticality is done using agile – Over the course of time higher criticality modules use agile
    • 5. CC Pace Proprietary What we will cover: • High level overview of Agile • Differences and Conflicts between Agile and Traditional Methodologies • The Journey to Agile and why using a Blended Approach can be an Appropriate Approach for you Company • Examples of Blended Agile • Key Points to Take Away
    • 6. CC Pace Proprietary What is Agile? • A conceptual framework for software development that promotes development iterations, open collaboration, and adaptability throughout the life-cycle of the project. • Simply stated, the ability to respond to change.
    • 7. CC Pace Proprietary Agile Principles • Individuals and interactions over processes and tools. • Working software over comprehensive documentation. • Customer collaboration over contract negotiation. • Responding to change over following a plan. Although there is value in the items on the right, we value the items on the left more.
    • 8. CC Pace Proprietary Agile Practices • Breaks projects into ‘functional slices’ for incremental delivery. • Consists of short development cycles. • Supports Empirical methods to monitor progress and allow for rapid change. – Inspect and Adapt mechanisms • Anticipates that baseline requirements will change. – Resulting in a product which more closely meets customers needs • Agile is not without its own structure and control mechanisms.
    • 9. CC Pace Proprietary Agile Process Framework 1-4 weeks 24 hours Product Backlog As prioritized by Product Owner Iteration Backlog Backlog tasks expanded by team Potentially Shippable Product Increment Daily Meeting PRODUCT BACKOG ITERATION BACKLOG BURNDOWN CHART ITERATION DEMO RETROSPECTIVE
    • 10. CC Pace Proprietary Implications of Agile • No traditional phase gates; functions are done in parallel in very small batches. • Not everything will get done; this is good! (45% of it is never used anyway). • The highest priority work will get done and will be done early. • Requirements will not be highly defined in advance. • Requirements will change; this implies that code will change and test plans will change. • There will be much better communication, coordination and alignment.
    • 11. CC Pace Proprietary Agile Myths Agile Is NOT: • A silver bullet solution • New and unproven • A methodology without any planning/documentation/architecture requirements • A license to hack • Undisciplined; it actually has many controls • A methodology that creates quality issues • A final solution to all project resourcing issues
    • 12. CC Pace Proprietary Agile and Traditional Methods Compared
    • 13. CC Pace Proprietary Traditional vs. Agile • Most traditional methodologies consist of several phases to develop/enhance applications.  – i.e. requirements phase, design phase, build phase and implementation phase • Agile development utilizes iterations which combine to equal a release (an individual iteration can also be a release on a very small project). – Iterations consist of all of the above phases, except at times implementation. – Implementation may happen at the release level.
    • 14. CC Pace Proprietary How Is Agile Thinking Different? Topic Traditional Agile Driver Plan-Driven Value-Driven Resources Partial allocation Dedicated Sponsor Involvement Ad Hoc Daily Change Is a risk, minimize it Is a competitive advantage, embrace it Leadership Command and control; Telling, Directive Servant Leadership; Participatory, Facilitative Lifecycle Phased Approach; Serial, Sequential Short Iterative Development cycles, Incremental Delivery
    • 15. CC Pace Proprietary Traditional vs. Agile Traditional Thinking Agile Thinking Gathering all requirements weeks or months before development begins High-level requirements gathered and then supports evolutionary requirements Full up-front design and architecting “Just enough” design and architecting Descriptive approach - plan what you expect to happen Empirical approach – inspect and adapt mechanisms with early and continuous evaluation Uses formal processes to control changes Anticipates change to baseline requirements Command and control leadership style Leadership by influence Heavily matrixed team members Dedicated, self-organizing, cross-functional teams Phased approach Short development cycles delivering continuous functional slices of incremental value Process focused Value delivery focused Heavy documentation requirements Consistent level of lightweight documentation maintained as the project progresses Information disbursed across many individuals with low visibility Highly visible information to business and IT in a collaborative work environment
    • 16. CC Pace Proprietary * Top 3 reasons from CompTIA survey, Mar 2007 ** misc reasons from other sources A Different Approach to the Same Problems Some Reasons Projects Fail Traditional Solutions Agile Solutions Poor Communication * Status Meetings; Communications Plan; Stakeholder Meetings Daily Meetings; Collaboration; In- Room/table dialog; Retrospectives Inadequate Resources * Request and justify additional resources Assign dedicated teams; whatever team is available only commits to work they can do Unrealistic Deadlines * Identify risk; Compute additional resources needed to make the date; request; re-work the schedule/budget Deliver in time-boxes; estimate completion range based on team velocity; negotiate scope Requirements Changes ** Submit Change Requests; re-work schedule Add new stories to Backlog; prioritize; pull into iterations Lack of user involvement ** Request a project sponsor or SME rep Dedicated Product Owner involved with the team on a daily basis People Problems ** PM intervention/Coaching Connectivity; Ownership; Team Norms; Values; Collaboration; Co-location; Retrospectives; Team Self-Policing; Coaching
    • 17. CC Pace Proprietary Waterfall, Spiral, and Agile Development • The waterfall life-cycle model has been closely associated with heavyweight documentation. • The spiral model has been misinterpreted as an incremental waterfall model, rather than as a risk-based model. Spiral also responds to change, thus is adaptable. • Agile focuses on people (individuals, stakeholders), products (working software, key artifacts), and change (responding to change, adaptability). – Notice that common to both the Agile Manifesto and Spiral is adaptability.
    • 18. CC Pace Proprietary Agile and Traditional Methods Conflict
    • 19. CC Pace Proprietary Conflicts Between Methodologies • Working Software vs. Early Design Documentation – The conflict between what is perceived the end-customer wants and what is being asked. • Single vs. Multiple-Increment Life Cycle – Agile teams focus on achieving customer satisfaction through frequent software deliveries based on clear priorities. – Agile teams are also usually small and often do not have adequate resources to work multiple risks in parallel. – The single iteration through the waterfall model with the planned single milestone can be a project management conflict for the agile team.
    • 20. CC Pace Proprietary Conflicts Between Methodologies • On-Site Customer Collaboration – Agile requires the customer to become part of the working team. This role is known as the product owner. • Business members are not use to dedicating time to the development of a project throughout the project’s lifecycle. Previously the business person/product owner provided input at different stages of the project. • Formal Deliverable Documentation Weight – Agile methods tend to promote lightweight documentation. This is because agile values working software more than documentation. In most companies cultures, documents tend to be on the heavyweight side.
    • 21. CC Pace Proprietary The Journey
    • 22. CC Pace Proprietary 1. It requires thinking and acting in new ways 2. Roles/Responsibilities will change 3. Interactions will change 4. Processes will change 5. People resist change There are ‘just’ two problems left to solve in business – People and Change. -- Bob Eichenger, Co-Founder, Lominger International Why Isn’t Moving to Agile Easy?
    • 23. CC Pace Proprietary Un-responsive To Change Responsive To Change Co-located Teams Daily Meetings Regular Reflection, Inspection, & Adaption Adaptive Planning Iterative & Incremental Delivery TDD Automated Testing Continuous Integration Everyone’s journey will be different, because starting points are different, environments are different, and obstacles are different. A Journey
    • 24. CC Pace Proprietary Why even bother Blending? • The success of Agile is clear and gaining some of those benefits through small improvements is worthwhile • Providing Business partners with earlier delivery of results and early access to a working system – Time-to-Value – Time-to-Market • Flexibility to requirements change – Evolutionary Requirements • Improved Business - IT collaboration and trust • Increased Customer Satisfaction • Increased Quality
    • 25. CC Pace Proprietary Why even bother Blending? • It takes time to move to a full Agile capability. • Companies have real obstacles that do not allow them to move as quickly. • Companies must collaborate with internal areas and outside organizations utilizing traditional development processes. • Companies have standing processes that can not be changed with a flip of a switch. • Taking a blended approach reduces the perception of risk. • Taking a blended approach gives the organization time to learn and to adjust which practices are right for their organization.
    • 26. CC Pace Proprietary Key Components for Blending
    • 27. CC Pace Proprietary General Blended Core Commonalities • Plan Collaboratively and Use an Incremental Life Cycle – the initial planning to be done collaboratively between the team and the customer – an incremental life-cycle model employed to align the blended project within the overall project schedule • Use Iterative development and Risk Check points – provide working software early to address high-risk areas – ensure all the risks are being addressed and prioritized
    • 28. CC Pace Proprietary General Blended Core Commonalities • Plan for Multiple Documentation Drops – provide multiple drops of documentation before the delivery date to obtain early feedback – consider use of a team member each iteration to capture documentation • Make Customer Collaboration Work – encourage and support as much customer collaboration as you can between the blended team and the end- customer to help manage your own risk – provide documented list of agreed-to stories to be completed in the upcoming iteration/release – conflicts associated with vague requirements can often be resolved quickly
    • 29. CC Pace Proprietary Potential Consistent blended practices for the Teams Metrics • Hours • Days • Points Planning sessions • Two levels of planning – Allows communication of the objectives to the project team, the executive stakeholders and customers: » release level - preparation for deployment to end users » iteration level - time-boxed increment of new functionality
    • 30. CC Pace Proprietary Potential Consistent blended practices for the Teams • Lessons Learned/Retrospective • Demo • Daily Stand up • Iteration 0 • Kick off • Customer/team collaboration and communication • Use an Incremental Life Cycle (2-4 weeks) • Common vocabulary
    • 31. CC Pace Proprietary Potential Consistent blended practices for the Teams • Test driven design and development • Active Stakeholder/Champion Participation • Core hours • Established Team Norms • Fun budget • On boarding • Establish Roles • Change acceptance
    • 32. CC Pace Proprietary Possible Blended Variables Per Team • Co-location • On boarding process • Toolsets • Time dedicated to the project • Length of iteration • Start of iteration • Order of deliverables at end of iteration • How status is covered in daily stand up • How board is set up (User Story Card) • Configuration of room • Scope changing • Presentation of backlog • Documentation flexibility – Multiple drops of documentation be provided – Depth • Estimation method • Contingency story card • Methods of Education • Methods of Communication
    • 33. CC Pace Proprietary Possible Blended Common Practices Overall Organization Overall • Informal user community • Established success criteria for the teams • Product backlog required • Blended vocabulary • Planning • Environment foundation • Core documentation • Compliance/audit • Budgets • Collaboration • Use of core Agile group • Use metrics • Communication Lines Open • Education • Test driven design and development • Active Stakeholder participation • On boarding • Roles
    • 34. CC Pace Proprietary Suggested How To Steps for General Blending • Know the existing processes – Identify the existing process/ methods being utilized – Analyze what is working well and what can be improved • Gain knowledge of best practices – These are from multiple methodologies – Review best practices and analyze which ones make practical sense to begin with • Obtain management support • Obtain team buy in • Select a pilot project – Begin with just one project
    • 35. CC Pace Proprietary Suggested How To Steps for General Blending • Collaborate with the team – Once the team is selected include the team in planning and making decisions • Advertise/communicate what you will do – Kickoff • Determine the strategy – Organizationally – Departmentally – Team • Constant retrospectives for lessons learned – Employ changes based on lessons learned
    • 36. CC Pace Proprietary Blended at your Organization Document and Communicate Your Blended Process • The PMO group or Core Agile group can become involved at this point. • Assign a team member to frequently document. • Share documentation with other areas within the company. - A shared drive? • Presentations to other areas in the company . • Presentations to management. • Frequent brown bags to share status and knowledge gained. • Production of a checklist and or variance document to help the new Blended Agile PM and Blended Agile Team adjust to differences.
    • 37. CC Pace Proprietary Blended at your Organization • Recognize that blended consists of feasible best practices • Recognize that blended can be different among teams and departments – Different teams may employ different forms of blended while maintaining organizational established core principles
    • 38. CC Pace Proprietary Conflicts in Setting up a Blended Process • Many of the conflicts are rooted in the up-front thinking/planning that comes with the one cycle waterfall model. • Several project management conflicts that companies face: – Full Life Cycle vs. Multiple-Increment Life Cycle – Documentation Weight – Role confusion – Working Software vs. Early Documentation – Customer Collaboration on site – Changes in Requirements and Testing higher level descriptions of business flows, called "User Stories" or "Use Cases” – Testing consistently – Time commitment
    • 39. CC Pace Proprietary Strategies to Avoid Conflicts – Once an iteration is under way, requirements must remain fixed to avoid chaos • Add a contingency story card – Multiple drops of documentation to be provided • Reduces risk, obtains early feedback – Use of core Agile group – Use metrics – Use iterative cycles – Communication Lines Open • Documentation • Presentation • Education • Establish common vocabulary • Project – verbal status – examples of the outcomes – visual boards – virtual boards – retrospectives
    • 40. CC Pace Proprietary Examples of Blended Agile
    • 41. CC Pace Proprietary Real Life Blended Case Background/Problem Description • This Fortune 500 company was looking to become more effective by improving on the integration points of multiple systems and improving the functionality of a trading system. The current process required multiple manual processes which were time consuming. • Time to market was imperative and budget was limited. Since there were so many tentacles and integration points from other departments and third party companies, this project also was restricted by several regulations. Management buy in and support for the project was needed from all of the integration groups. • The company was ingrained with older methods of project management and software development. However, due to the size and complexity of this project, they knew they would need to employ a different methodology to be successful.
    • 42. CC Pace Proprietary Real Life Blended Case Method – The client chose to employ a Blended Agile methodology that would improve delivery time, provide working software that satisfied the need of the customers, and conserve budget dollars. Approach – Held discovery sessions to determine readiness to use a Blended Agile methodology. – Formed a Blended Agile team. – Created the setup/iteration zero for the blended agile team. – Analyzed which agile practices would be feasible to utilize within their blended methodology now and in the future, while continuing to introduce new practices. – Determined which existing processes and best practices to utilize.
    • 43. CC Pace Proprietary Real Life Blended Case • Agile Competency Development - Training – overviews, lunch and learns, team meetings - Agile techniques training – stories, backlog, planning, vision box, etc. - Extensive training/coaching of the slated agile coaches - Mentoring – Coaches, Team, Managers • Program Development - Governance approach • IS Senior Management Updates weekly • IS Steering Committee Update
    • 44. CC Pace Proprietary Real Life Blended Case • Co-location was sporadic and only occurred during the core hours • Resources were part time, not dedicated • Instituted Core Hours - 9 hours a week • Obtained executive buy in and support for the project and a blended agile methodology • Established acceptance criteria for project success • Physical Environment - Room which was shared with other projects • Team - 2 Developers/analysts, 2 extended team developers, 2 Product Owners/QA, Agile Coach apprentice, Agile Coach
    • 45. CC Pace Proprietary Real Life Blended Case Key Results – The organization began to view blended agile as just a different technique for project development – Future team coaches were developed through the process – Teams became true teams and morale increased – Earlier releases into production were enabled giving the customer faster workable software • Although only 9 hours a week, when the first release was implemented the management/team calculated the actual time form start to finish to be about two weeks. – Delivering in two weeks workable software was phenomenal for this company. – Knowledge of Agile and forming blended practices occurred simultaneously – Determining which practices to use occurred simultaneously – Cross functional knowledge was shared and then utilized for future projects – 2 Teams Begun – Slated two more teams
    • 46. CC Pace Proprietary Real Life Blended Case Lessons Learned • Establishing the set up of a blended agile project is crucial to the success of the project; the set up differs per project. • No two blended agile projects are exactly alike from a practice perspective. • Determine up front the right team members. • Establish an on boarding process including team introductions and a project boot camp and implement. • Consider how to use team members time wisely. • Research should be done up front.
    • 47. CC Pace Proprietary General Blended Lessons Learned Lessons Learned • Each organization is different. • Any combination of best practices is good. • Consistently evaluate and adapt. • Learn your existing process first. • The amount of time dedicated is ok. • Co-location is helpful but not necessary. • Communicate the same message. • Make sure all organizational levels are on the same page. • Learn agile principles first, then begin to blend. • Consider academic but be practical.
    • 48. CC Pace Proprietary Key Takeaways
    • 49. CC Pace Proprietary How to Recommendations • Agile Core Group/Agile Steering Committee • Foundation of Knowledge • Develop community • Communication • Collaboration • Obtain coaching or help from a practical experienced person in the beginning • Re-evaluate consistently (inspect and adapt)
    • 50. CC Pace Proprietary Bottom Line • Agile methods bring many benefits. • Plan-driven methods bring benefits as well. • Most companies can not change their processes overnight. • Utilize practical best practices over academic best practices. • Collaboration of the best practices feasible within your company will increase progress.
    • 51. CC Pace Proprietary Core Thoughts to Remember in Blending • Keep it simple • Being Agile is the ability to move quickly and respond to change – This is a core principle in blended as well • Build the internal and external capabilities • Academic vs. Practical – Training is not enough you actually need experienced coaching ongoing journey – Always refer back to the principles for alignment – Employ changes based on lessons learned, inspect and adapt • Collaborate and communicate – Advertise/communicate what you will do – Insure and support core believers
    • 52. CC Pace Proprietary Core Thoughts to Remember in Blending • Adjust the organization’s mindset to be fully committed by all “no longer a pilot” • Will not happen with a flip of a switch • Realize that this is an evolving process
    • 53. CC Pace Proprietary Questions?