Agile Executive Forum: Financial Implications and Business Benefits of Adopting Agile
•Download as PPTX, PDF•
2 likes•1,313 views
Financial Implications and Business Benefits of Adopting Agile by Rod Cerrada Jr. at the Agile Executive Forum hosted by Orange and Bronze Software Labs. October 26, 2011
Recommended
Recommended
More Related Content
More from Orange and Bronze Software Labs
More from Orange and Bronze Software Labs (9)
Recently uploaded
Recently uploaded (20)
Agile Executive Forum: Financial Implications and Business Benefits of Adopting Agile
- 1. Rod Cerrada Jr. VP of Operations, Cerquit Solutions www.cerquit.com
- 2. Financial Implications and Business Benefits of Adopting Agile Agile Executive Forum By: Rod Cerrada Cerquit Solutions, Inc. www.cerquit.com www.cerquit.com
- 3. Trade-off Triangle • It conceptualizes the idea that Resources, Schedules, and Features are related to each other. • Any of the side changes the team have to make trade-off somewhere to maintain project balance • if new features needs to be added it have to make trade-off in resources, schedule, or other features www.cerquit.com
- 4. • Resources – Resources can be team, machines, budget, and/or tools that is needed by the project to accomplish its goal • Features – Outlines the project scope and requirements to satisfy the customer • Schedule – the time required to accomplish the project New Features www.cerquit.com
- 5. Business Benefits www.cerquit.com
- 6. Incremental over Big Bang • Agile welcomes changes. The product owner has a chance to change the course every sprint. – For a company who develop software products, you can add features in the middle of development for your product to be highly competitive in the market. – For a company who develop in-house software, you can add and prioritize features with high business value • Agile discover issues at earlier stage of the development thus improve quality • Agile ships builds every end of sprints thus create transparency and shortens the feedback loop www.cerquit.com
- 7. Traditional (Waterfall) Agile Jan Feb Mar Apr Jan Feb Mar Apr S S S S P P P P R R R R I I I I N N N N T T T T This is the only time the project visible to the customer Big Bang Release Incremental Releases www.cerquit.com
- 8. Increase Business Value • Agile improves the process through regular retrospect • Agile increases customer satisfaction and confidence to the product • Agile builds trust and relationship with customer through regular and open communication • Agile improves the quality of the product • Agile shortens time to market • Agile reduces Risk www.cerquit.com
- 9. Agile ships working increment of the product to customer thus increase visibility and transparency 2 to 4 weeks cycle Changes, Issues, Customer/Product Feedback, or New Owner reviews and Feature(s) validates the release www.cerquit.com
- 10. Agile eliminates noise in the process that increase team’s productivity and focus Tasks www.cerquit.com
- 11. Output over Theory • Agile is focused more in communication with the team and the product owner to understand the customer requirements instead of documentation • Agile is focused on bridging the communication gap between team members because feedback loop is much shorter • Agile discovers issues before it strikes • Agile can start the project with minimal documentation www.cerquit.com
- 12. The traditional model of gathering requirements and building specifications is based on a lot of formalising, handing over documents, and approval processes. Customer/ Analyst Developer(s) Tester(s) Worst case scenario Product Owner www.cerquit.com
- 13. In agile processes, the feedback loop is much shorter and more frequent, so problems get discovered quickly. Communication between the team and product owner is always open. www.cerquit.com
- 14. Financial Implications www.cerquit.com
- 15. Faster Delivery Faster ROI • Less Management Overhead • Increase efficiency of the team results to lesser cost • Product Owners could throttle the budget without sacrificing high valued features • Quality output results to low maintenance and downtime • Agile does not recommend Over Time results to low operation cost • Shorten time to market thus increase revenue and help position the product in the market. • Agile increase competitive edge of the product in the market • Agile produces Happy developers = productive developers = less turn over www.cerquit.com
- 16. Organic Growth. In agile, you don’t need huge team to start the project. It grows as the demand increases and it shrinks as the demand slows down. This results to lesser cost of implementation and efficiency. Demand Decreases increases www.cerquit.com
- 17. Team Benefits • Agile increases team confidence in the product • Agile promotes self management and teamwork • Agile produces highly maintainable product • Scrum meeting over documentation • Team are focus at one common goal and one point person • Career growth www.cerquit.com
- 18. How to Cope Up with the Agility of Agile Development • Setup Standards – Coding Standards – Development Standards • Test Driven Development • Fameworks and tools • Design Patterns (MVC, MVP) • Development Infrastructure – Source Code Control – Automation using Continuous Integration (CI) – Code Coverage www.cerquit.com
- 19. Reference • Agile Project Management with Scrum by Ken Schuaber • Peopleware by DemMarco & Lister • Goolge “Scrum” or “Agile Development” • http://www.it- cortex.com/Stat_Failure_Rate.htm • Microsoft Solutions Faramework - http://technet.microsoft.com/en- us/library/bb497060.aspx www.cerquit.com
Editor's Notes
- Brief intro about myself and Cerquit Solutions, Inc.Position and responsibilityPlug Cerquit ProductsCerquit Loans Management SystemCerquit Warehouse Management SystemCerquit Accounting SystemBrief talk about experienceUsed to be evaluated based on my technical skills and capability as architectNow I’m evaluated based on figures“I will share with you the financial implications and business benefits of adapting agile based on my experience in Cerquit Solutions”Before I will start with the main presentation, I will give you a brief overview about trade-off triangleI learned this5-6 years ago when I’m studying the MSFT solutions framework. This triads will help you in scoping out projects.
- Before I will start with the main presentation, I will give you a brief overview about trade-off triangleI learned this5-6 years ago when I’m studying the MSFT solutions framework. This triads will help you in scoping out projects
- Resources can be QA/Testers, engineer, architect, machines, development environment, wages for engineersFeatures can be the ability of the system to send alerts to the usersSchedule can be the time to market needs to be aligned with software developmentWhen new feature(s) is added by the product owner, it can be a feature that will give edge to the product or feature critical to the business.Are we going to add resources to accommodate the feature without extending the timeAre we going to extend the schedule to accommodate the featureAre we going to remove some features to give way to the new featureThis is where the product owner role will come into play. Product owner ensures that the features that will provide the highest ROI for the project are completed first.
- Why Agile? -> because software does not end after deployment it continues to evolve in order to meet the requirements, compete, and demands of the customers. This is true especially to company who develop products. In the case of Cerquit, we have a accounting system product when BIR release any revenue regulations we need to be always updated and needs to be implemented to our system to always keep in the competition.
- Do you have a chance to remove other features to give way with the critical feature without major impact to schedule or cost or spent time consuming process of filing change request ?Did you know that only 13% (130) of 1000 project did not fail and it was found out that 4 out of 5 key factors were associated to inability to deal with changing requirements, and problems with late integration?In our case, with our Cerquit Accounting System from time to time BIR will release new revenue regulations or security requirements that we need to integrate to our product in order to be competitive in the market. There are also cases that during the audit BIR will request for enhancement to tailor fit the system to the business.STATSA study in the United Kingdom shows that of 1,027 projects, only 13% did not fail, and waterfall-style scope management was the "single largest contributing factor for failure, being cited in 82% of the projects as the number one problem.”another study of 6,700 projects, it was found that four out of the five key factors contributing to project failure were associated with and aggravated by the waterfall model, including inability to deal with changing requirements, and problems with late integration
- TraditionalOne time releaseIssues and feedback will only captured after the release that in most cases will delay the project.Issues and feedback is too late that will affect the design of the product. Worst, it will have domino effect.Sometimes you can not even proceed to maintenance because of too many issues at hand that results to extend the scheduleAgileIncremental releaseChanges and feedback are welcome every sprintIssues are resolved earlierResults is fastMinimizes Risk, Decreases Time to market, and Increase ROI because Product Owner can release the system anytime he feel that the system is ready
- According to the Standish Group’s Resaearch in year 2000, 25% of all projects still fail outright through eventual cancellation, with no useful software deployed. a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost over 189% of their original estimates. On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. in 1995 American companies and government agencies will spend $81 billion for canceled software projects.These same organizations will pay an additional $59 billion for software projects that will be completed, but will exceed their original time estimates48% of the IT executives in our research sample feel that there are more failures currently than just five years ago.REASON: Waterfall and inability to adopt change.If you are a product owner would you like to belong to these statistics?
- Changes, feedback, and new features can be integrated while developing the product.Customers/Product owner can check and review the build and give feedback that will be included in the next sprint.In my experience, for projects with tight deadline we use 1 week sprint.
- Noises are staff that bypass the project manager and assign task directly to engineers.Issues, tasks will be discussed during scrum meeting.
- How much time do we spend to create comprehensive documentation of the project? How often do you see your engineers reading the documentation?Site the recent example with our client from Australia that don’t have documentation but he already know all the requiremnts because its all his idea. He ask “Can we start without documenation?” “I have a tight budget because my previous engineers spent almost 3x the estimated time and did not deliver the project”Say “Please bear with me there are a lot of questions in my presentation”ER diagramDetailed specifications, etc?1-2 months? More than two months?
- Business analysts first extract knowledge about requirements from customers, formalising it into specifications and handing that over to developers and testers. Developers extract knowledge and translate it into executable code, which is handed over to testers. Testers then take the specifications, extract knowledge from them and translate it into verification scripts, which are then applied to the code that was handed over to them by the developers. In theory, this works just fine and everyone is happy. In practice, this process is essentially flawed and leaves huge communication gaps at every step. Important ideas fall through those gaps and mysteriously disappear. After every translation, information gets distorted and misunderstood, leading to large mistakes once the ideas come through the other end of the pipe.Have you play the XXX (communication game)? That game clearly explains the communication gap if we pass the message along with more that two persons.“Bear with me, I have a meeting see you tomorrow in your office” ice breaker…
- Team in agile are self managing. It is up to the team to decide the best course of action. They are empowered! What a novel idea, empowering the people that are doing the actual work.Overtime is a sign of trouble. What are the reason why you allow overtime?The time the software release its already obsolete
- Some take it into number of engineers without knowing the task is too saturated. Where other engineers don’t have enough task.
- Test cases Career growth because they are empowered on how to think and solve the problem their skills are harnes and tested along the way. They will learn from their mistakes.
- AGILITYmeans adopting a posture that allows you to respond rapidly to changing market conditions and customer demands.The first time we implemented agile we find it quite time demanding and we feel the pressure of the sprints coz we need have a potentially shippable functionality of the project every end of sprints. Until we have our development infrastructure setup.Setup standards will stream line your process, it minimizes turn over cost and speed up the implementation.Imagine if we don’t global standards like in the case in traffic – green go, red stop.Development infrastructure gives mobility and agility to your team. And most important it increase quality of the product and efficiency of the team - in return increase ROI. Like for instance a 1000 test cases can be finished by CI in less than a minute but human testers can finish it in 2K to 5K minutes (33 hours to 83 hours which equivalent to 4 days to 2 weeks of work)And what is best with automation is that you can run it anytime you want and it does not complain.