Agiletools
- 1. No tools == No Agile!
- 2. Agenda Introduction Scrum @Nucleus Scrum @Nucleus with tools Screenshots Traceability Achievements & Vision Potential pitfalls Q&A
- 3. Introduction 3
- 4. My involvement with software products started in 2000 and has continued till date. I have been an Agile practitioner for ~5 years and have played multiple roles of developer, scrum master, architect and product manager. I have worked with products in all stages of the product lifecycle right from inception to maintenance and EOL. Currently @Nucleus working with ~4 Scrum teams following Lean and Agile principles to create the next generation product.
- 5. Scrum @Nucleus 5
- 6. Scrum •Daily Scrum •Daily Work •Daily Cycle •Sprint planning meeting PREPARATION •Business case & funding •Contractual agreement •Vision •Initial productbacklog RELEASE •Initial release plan SCRUM PROCESS •Product •Stakeholderbuy-in increment •Update •Assemble team product backlog •Impediment List •Scrum master •Product backlog •Sprint •Sprint retrospective review •Product backlog Delta •Product owner report SCRUM SCRUM ROLES ARTEFACTS •Product backlog burndown •Users •Stakeholders •Sprint backlog •Sprint backlog burn down
- 7. My team @Nucleus Follow the book We have a flat team structure We publish a sprint, version and release dashboard The teams are in the range of 8 We retrospect on the glad/ to 10 people mad/ sad points in a sprint and The team was trained assign actions from them effectively on Scrum & Agile Scrum master is not doing any project management Scrum masters are mentoring the team members Team members are coached to take ownership of the work done We create all backlogs: release, version, sprint & impediment We perform all of the Scrum ceremonies Sprints are demoed to PO and recorded
- 8. Done? When team says they are “DONE” for a * release Quality Control Functional testing – running the entire suite of tests Penetration testing done by a team of Penetration Testing internal experts Performance Testing Perforance testing done using performance test automation tools System testing / internal UAT done by System testing senior business analysts/ domain experts Integration testing done with other core Integration testing banking/ external systems
- 9. So… Question 1: Not putting a number/ percentage on compliance but do you think we are following Agile? Question 2: Does Nucleus as a company see benefits/ gains from this change in software development methodology? Question 3: Do our customers appreciate this change methodology, is there any value they derive from this?
- 10. But… “ Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. “ From the agile Manifesto
- 11. Risks Fixing bugs late is costly: Cost: Finding and fixing bugs late is Associated cost of doing these contradictory to fail early principle things manually and as a large chunk versus doing them slowly as part of each sprint Quality of code: What is the code quality, potential defects/ performance issues induced by bad quality of code. Critical path failures: How many times does a checkin lead to a completely dysfunctional product Non-deployable software: Against Agile philosophy of having deployable software after every release Code merge: When working with distributed teams code merges which are delayed may create complex issues low risk medium risk high risk
- 12. Developers when asked to test How do you expect us We can get a QC person to estimate, code and on the team later and test in the same 2 then have a couple of Oops did you week cycle? hardening cycles to talk about SOPs I ensure quality is taken use them for Cant we just rely on care of debugging the product owner, it is his job to mark it as done? I am a developer not a Why do we need to tester! run performance tests now, I mean there is still 6 months left to deliver? Use It is humanly impossible tools to do everything in a short timebox, with <=10 people without using proper tools.
- 13. Scrum @Nucleus With Tools 13
- 14. Scrum @Nucleus Process & Metrics Successful Agile Tools Deliveries Agile Teams
- 15. Continuous Integration Continuous integration is a development philosophy of “on checkin” developer integrations verified by automated builds and deployments. 1 Compilation Junit Java docs execution DB Performance integration & tests migration Functional Code tests inspection Deployment
- 16. Setup Prepare Product Backlog JIRA Target Deployment Server SVN Repository Update JIRA Product Owner Check out sources Eclipse STS Mylyin Plugin Deploy Share Results JIRA Task Board Run Tests Close Task Open Task Logs Time Notifies Jenkins to trigger build Sonar Build Email Maven Feedback Developers SubEclipse Plugin Continuous Integration Server Jenkins
- 17. Tools used Eclipse Sonar IDE with plug- Code Quality Jenkins / Fish Eye ins and Coverage Maven Per checkin Traceability Builds J – Units/ SVN Selenium Source Code Automated Library Test Suite JIRA Nexus Agile based Internal Project Automation maven Management repository Sprint is of 2 weeks. In which all engineering activities need to take place 17
- 18. Screenshots 18
- 19. Checkin Email
- 20. JIRA Traceability Traceability: Mapping to JIRA
- 21. Dev Build
- 22. Unstable Build
- 24. Build Summary
- 25. Integrated functional & performance tests Functional tests Performance tests
- 26. Code Quality
- 27. SCM Statistics
- 28. Traceability 28
- 29. Traceability Quality Audit Product Owner Scrum Team Quality Control Team Product metrics, User stories Product health score Dev tasks, Test scenarios, test enhancements, Traceability via Jenkins Traceability in cases, test case and JIRA defects and change JIRA execution requests Traceability to dev tasks in JIRA via common user stories 29
- 30. Achievements & Vision 30
- 31. Achievements • Reduced count of build failures • Increased overall test coverage • Improved traceability and ability to find root cause for defects • Team focus on delivering product • Reduced cost incurred on build & release management • The team sees value of build & release and is focused on “continuous improvements” • Team feels more confident of the delivery made to the customers
- 32. Vision Repeat the model for multiple product Manage teams and customer improve further deployments for by cutting down patch releases/ on waste core upgrades Integrate online functional performance and penetration scripts as part of build
- 33. Potential pitfalls 33
- 34. Human Factor Do not forget we are dealing with 1 human beings and they have limitations What is a build? The greatest factor for any Agile implimentation is the fact that we are dealing with human beings What is a build, the definition needs 2 to be clear and we need to perfect the team not the process. A lot of times we get carried away with the Locus process forgetting that process is meant to improve the team and the end goal is to improve The key player is the build engine: the team 3 Jenkins Incremental process Treat build & release as an 4 incremental process and better it in every sprint
- 35. Human Factor Do not forget we are dealing with 1 human beings and they have limitations Build may have different meanings for different What is a build? people while some may think that it is successful compilation others may go beyond. What is a build, the definition needs 2 to be clear It is very important to emphasize and make everyone agree on one common build definition then live with it. Locus The starting point for feature/ debt addition is at The key player is the build engine: the developer desk we have to make sure what is 3 Jenkins being checked in is sanitized. Incremental process Treat build & release as an 4 incremental process and better it in every sprint
- 36. Human Factor Do not forget we are dealing with 1 human beings and they have limitations It is very important that teams have this skill What is a build? without which either we will have a superfluous setup or a setup which does not work. What is a build, the definition needs 2 to be clear It is the build engine which orchestrates the entire flow after each checkin we need to understand and plan very meticulously for example: Locus • What will happen if someone checks in The key player is the build engine: code when build is broken? 3 Jenkins • What will happen if a build is in progress and someone checks in code? • The right notification scheme Incremental process • The right dashboards Treat build & release as an 4 incremental process and better it in every sprint
- 37. Human Factor Do not forget we are dealing with 1 human beings and they have limitations What is a build? What is a build, the definition needs While it may be nice to have everything up in one 2 to be clear go, we need to factor in product specific parameters. The goal is to reach a mutually accptable build and release configuration which Locus meets the product, team and business considerations. One solution may not fit all needs The key player is the build engine: and even exisiting solutions may need constant 3 Jenkins updation to get to the right configuration. Incremental process Treat build & release as an 4 incremental process and better it in every sprint
- 38. Questions? 38
- 39. Thank You 39
Editor's Notes
- About NG product: it is a web based Java/ J2EE application for loan processing
- We also have unit tests implemented with coverage > 60% hence we have followed all of the agile processes
- Software has to go through various filters before it is deemed usable, when do these happen for you? Right now we have a hardening sprint and sometimes a SWAT sprint where everyone gears up to find bugs and then fix them. These steps use tools and time of dedicated experts who are shared across teams. Having someone dedicated to a sprint team is not possible. So the point I want to make here is that even though deemed fit by a Scrum team a product has to go through other phases before it is actually usable. Going through all of these phases in 15 day sprint is not possible without the use of tools
- There is no clear benefit to the company and customer? Our sprint releases are not shipped to our customers, factoring in the fact that we do not have any external customers. Unless we have a customer other than the product owner who sees the development per sprint or per two sprints they will not see the advantage of using agile to speed up software development
- It appears even though we are following all agile practices we are violating the very foundation on which it stands. The benefits of adopting these practices should be seen by the team, organization and customer. Where the order should be customer first whereas the customer does not see a big advantage in the current scenario. The problem is that whole implementing Agile the teams tend to think of it as a tool to improve engineering discipline whereas they tend to forget the customer angle which is of paramount importance.
- Software development in general is a risky business. We depend on humans to write code and humans have emotions which makes them different from machines. The above presents another angle to the software development business which are the associated risks this may not be the wholesome picture and there may be more than these which will vary across companies and teams but these are some which are common across teams I have worked with.
- Finally we have to give a hearing to the team people who are making sure that the cogs turn and an output is produced. They are already pushed against a wall as they have to take up very short tasks which are of measurable business output. Measurement of velocity ensures constant improvements, the developers are already writing units to ensure coverage adding the testing burden to a team member is not something they are ready for.