What are we afraid of?


Published on

Large, regulated industries (like aerospace and telecom, for example) have unique challenges for scaling Agile for distributed, global teams of 500+ people, and associated code bases of several million lines of code. This package focuses on the unique challenges for this type of business environment. Given the premise of a few pilot teams up and running with success, living, loving the Agile Manifesto and associated principles, how do we expand local Agile team success in this environment?

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

What are we afraid of?

  1. 1. Don’t bother with this package if this doesn’t look like your business: 1 Friday, May 21, 2010
  2. 2. Don’t bother with this package if this doesn’t look like your business: You have a couple of very successful Agile teams who are living the Agile Manifesto and associated Principles And now you wonder.. How do I expand this in my global, regulated large company (500+)? ...and (for a variety of business reasons) saying “Scaling Agile is hard, so we won’t do it” is not an option for you. 1 Friday, May 21, 2010
  3. 3. Scaling Agile 2 Friday, May 21, 2010
  4. 4. Is Scary! 3 Friday, May 21, 2010
  5. 5. What are we afraid of? 4 Friday, May 21, 2010
  6. 6. For large, global, diverse companies, ‘going Agile’ means you must Create/support local optimization Empower at the team level Continue to meet Enterprise goals 5 Friday, May 21, 2010
  7. 7. The solution? Automate your SDLC. 6 Friday, May 21, 2010
  8. 8. Think of this as an opportunity to increase profit 7 Friday, May 21, 2010
  9. 9. and have fun! 8 Friday, May 21, 2010
  10. 10. What should our automated SDLC do for our teams and our business? URL for our processes Hi Auditor, here’s how we think we develop products! URL for compliance to processes Hi Auditor, here’s what we did! What we need to do, should do, can/cannot do is all documented in our regulated environment, with Virtual Big Visible Charts and supporting tools so that we can be geographically distributed supporting a global economy. 9 Friday, May 21, 2010
  11. 11. What else could our automated SDLC offer? Be a value added tool for our global (distributed) teams to support knowledge creation and knowledge sharing. Support formality in the situation where it is needed, to offer tailoring when it is not. Organically capture decisions and store artifacts. Support code quality! Support our Agile Adoption! Support Issue Management! Provide intelligence which can be actioned when necessary. Share the corporate vision so teams are not making decisions in vacuums 10 Friday, May 21, 2010
  12. 12. What would a simple SDLC look like? Your SDLC could be as simple as Wiki pages taking you from Business Case through to Release. Example Business Case wiki template: This could be as simple as “What I am delivering, Why I am delivering it, how much is it going to cost us”, with tracking tool approvals (example, Jira) built-in. Simple example of Wiki Process Compliance: For any specific team anyone can see where they are within the SDLC. When the buttons ‘fade out’ team is in compliance with the process. 11 Friday, May 21, 2010
  13. 13. Lets talk further about this regulatory compliance We’re regulated as a public company Or as a data provider Or perhaps safety, security regulations (FAA) SOX, FFEIC, FAA, ..we are an auditable entity This means we are expected to have auditable processes, from product development through to operations. This does not mean we can’t Be Agile! 12 Friday, May 21, 2010
  14. 14. Think of this as an OPPORTUNITY! Move away from heavy-weight processes to processes where process validation is built-in. Capture decision-making processes organically, not through reams of papers - make it natural! For example, move to a model where a tracking tool (Jira, for example) tracks approvals so that the living process becomes an auditable artifact. Heavy-weigh processes are EXPENSIVE! When trust is low, extra cost of V&V skyrockets and slows down delivery You will need to train your auditors however, who will be expecting the paper trail! 13 Friday, May 21, 2010
  15. 15. Knowledge creation and sharing when the information is an emergency: What are your challenges as a geographical distributed organization? 14 Friday, May 21, 2010
  16. 16. Where’s the knowledge today? “On some shared network drive” “In some word doc somewhere” “Sharepoint, sccs, ecm..” ...the act of finding the information itself is time consuming and too hard! “He knows” (The single person that possesses the knowledge that the others want, so much so that he is CONSTANTLY interrupted.) 15 Friday, May 21, 2010
  17. 17. What are our Knowledge Creation and Knowledge Sharing Goals? Provide the teams with the ability to build knowledge, share knowledge, and take action. Provide the narrative on the business expectations and expected results. Build formality in where you need it and provide the ability to tailor when you do not. Example: Formal detailed design document can be tailored out if team is co-located all speaking the same language, however cannot be tailored out if team is distributed across continents (and languages.) 16 Friday, May 21, 2010
  18. 18. Look! Another Opportunity! Build a Knowledge Oasis Portal! Capture all of the “He Knows” information. Redirect all of the peer-to-peer information Redirect “one owner of the document” information Make the information linkable and searchable! Create a master index of tacit knowledge. ALL questions are possible: but document the answer building the Wiki “as needed.” Twiki, Wikis, (example Confluence) are your friends... PEOPLE are the secret sauce to Agility: yet tools that can share knowledge support the effort! 17 Friday, May 21, 2010
  19. 19. Knowledge Oasis Portal Benefits: Your Key contributors to this Portal are not going to be who’d expect them to be: Your Knowledge Oasis Wiki Portal will give a voice to everyone in the organization who may not share their knowledge today! Hosting “Fun, Contribute-to-the-Wiki” competitions will accelerate this knowledge sharing, making a huge difference! 18 Friday, May 21, 2010
  20. 20. Issue Management 19 Friday, May 21, 2010
  21. 21. Is this your starting point? We start to ‘go agile’ with years of internally branded waterfall as formally documented processes flowing in our bloodstream. We are likely vertically organized with Test (QA), Development, Product Management in silos. We have some Client-Server issue management tool, which is very expensive. Client-server issue management tools can be huge impediments when you are geographically dispersed (“when we are not in the home office, we end up with a web interface”) 20 Friday, May 21, 2010
  22. 22. Where are your Operational Expenditures really going? Are you really solving problems with your issue management processes... or perhaps, are you just working around them? 21 Friday, May 21, 2010
  23. 23. Look! Another Opportunity! 22 Friday, May 21, 2010
  24. 24. Why not Optimize Issue Management? Take a critical look at where you spend your OPEX. Do you have horrendous renewal rates for issue management systems? Do they really solve problems? Or do they make you work around them? Is the issue management system a HELPER (to solve the problems of optimizing product development?) Do you have incredibly complex workflows which you use to legislate product development behaviors. ...and do you spend time working around these workflows? 23 Friday, May 21, 2010
  25. 25. Simplicity Search within the organization for newfound simplicity: Get back to a simple place. Ask your initial Agile Pilot teams to help identify thee complex workflows as impediments. Save OPEX: there are awesome open source tools for issue management available. Spend time and due diligence on potential OPEX savings as you can leverage these savings for Agile tools (like a Continuous Integration tool.) 24 Friday, May 21, 2010
  26. 26. CODE QUALITY! 25 Friday, May 21, 2010
  27. 27. Improve Code Quality Creating Awareness is the first step Providing some visibility back to developers of “what are the challenges in my code?” How do you provide them with more knowledge about their code? Nobody can improve in a vacuum! Wait 3 months for QA to pass on the product, and nobody will remember. Knowledge is power. 26 Friday, May 21, 2010
  28. 28. If you take just one thing away from this presentation In addition to living and loving the Agile Manifesto and associated Agile principles You will need great tools AND great processes if you’re going to take Agile to scale. Who would have thought that a cat bathing tool existed? 27 Friday, May 21, 2010
  29. 29. Example Code Quality tools Continuous Integration (CI): Bamboo, Hudson, Maven CruiseControl..etc. Crucible with Fisheye for code reviews & reports to help with communication across geographical boundaries. Tools such as FindBugs for code static analysis. Tools such as Clover to measure code complexity. Can be used to look for hot spots, used beneath automated testing infrastructure so that you can see how well your applications are covered from an automated test perspective. (#tests = not an effective measurement of code quality!) Use of Code Analysis tools (PMD)+ your Wiki Command Line Interface (CLI) to publish metrics from CI Not an exhaustive list...so do your due diligence and leverage the OPEX savings here! 28 Friday, May 21, 2010
  30. 30. Benefits of Code Quality tools We create the awareness and build the knowledge! Teams are provided with better decision-making power! This helps us across geographical boundaries, giving us the actionable intelligence so that people are focused - not dealing with ‘noise’. Ancillary benefit: Using our Wiki CLI as the unifying force of “what we are building” and “how we are building it”, sets us up with the opportunity to bring all the information about a release to one place! 29 Friday, May 21, 2010
  31. 31. The need to move your organization to Agility should be clear: Committed Scope What the Market Really Needed! We gave you what we signed up to give you! Turns out, that wasn’t what the market needed! Project inception We commit to scope 30 Friday, May 21, 2010
  32. 32. Be Agile! Embrace Agility! Recognize early that we are beginning this Agile quest with processes built around resisting change, not managing effective change. Take your organization from a HEAVY process organization to the Agile world. Yet do this consciously: remembering your regulated environment with your business constraints. 31 Friday, May 21, 2010
  33. 33. Optimizing Agile Adoptions With a geographically distributed organization, you need distributed visibility of how teams are doing. Need effective backlog management! Need a Agile/Scrum tool that takes distributed teams effectively through planning boards to task and resulting metrics. Need a tool that can provide actionable intelligence to the team Example tools: Jira + Greenhopper , Serena, VersionOne, Rally, Scrumworks.... 32 Friday, May 21, 2010
  34. 34. Benefits of a great Scrum tool The team can focus on what is really needed and avoid the noise. Planning board works effectively for remote and geographically distributed teams, as well as for co- located teams. Transparency is key: global visibility from the team level to the product dashboard view. Opportunity to set up friendly competition between multiple product lines, where everyone can see progress to-date, code quality, with global visibility of each of the products. 33 Friday, May 21, 2010
  35. 35. Ancillary benefits Processes and tools HELP instead of HURT! We like to come to work! We focus on what matters! We are proud of our product! 34 Friday, May 21, 2010
  36. 36. First steps in creating your SDLC.. Accept that if you focus only on your development phase your constraint will soon be moving. Front and back ends will have to be adapted and optimized as well (portfolio management, services, sales.) User Stories developed iteratively Deliveries will be offered and sold iteratively How will this look? Define your SDLC scope. Plan to build your first draft Agile SDLC from success of your initial Pilot teams. 35 Friday, May 21, 2010
  37. 37. Merci! Catherine Louis - cll@cll-group.com catherinelouis - twitter http://www.linkedin/in/catherinelouis - linkedin 36 Friday, May 21, 2010