The Agile Pretender


Published on

I recently did a talk on Agile and the importance of people over role/process obsessions. I didnt use this in the end, as I decided to adopt a more natural and example-based approach. Feel free to use however - the web is built on plagiarism after all ;)

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

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

No notes for slide

The Agile Pretender

  1. 1. The Agile Pretender The rise and fall and rise and fall and rise ..... of Agile “ It would be so much easier if the they all just kept their noses out until we’ve finished” - A Development Team
  2. 2. You never change things by fighting the existing reality. <ul><li>To change something, build a new model that makes the existing model obsolete. </li></ul><ul><li>Richard Buckminster Fuller </li></ul>
  3. 3. Methodology Trail <ul><li>Flowcharting originated in 1930s for defining process in engineering. </li></ul><ul><li>Iterative and incremental development (first recorded 1957) </li></ul><ul><li>Software Development Lifecycle appeared in 1960’s </li></ul><ul><li>Waterfall dominated in 1970’s and 1980’s (top-down approach) </li></ul><ul><li>Scrum entered the world in 1993 (originally defined for manufacturing in 1986) </li></ul><ul><li>Agile Manifesto defined in 2001 </li></ul>
  4. 4. Common Agile Errors <ul><li>Business still uses waterfall-based checkpoints to manage risk - at odds with(“Responding to change over following a plan”). </li></ul><ul><li>Sprints can become Waterfall milestones (Waterscrum) in this situation – more features in longer sprints, with Waterfall risk. </li></ul><ul><li>Perception that Agile projects have more risk - in fact Waterfall has more risk, because if one feature goes wrong, it will take longer to highlight (and knock impact can be severe). </li></ul><ul><li>That processes are at fault over people (common failures are due to roles being combined/omitted and team development skills gaps, or simply lack of Agile understanding) </li></ul><ul><li>Sprints poorly planned leading to rapid spillover </li></ul><ul><li>Test Automation instead of Testers </li></ul><ul><li>Poor Continuous integration pattern (ideally, with complete build and testing) </li></ul>
  5. 5. Agile Test Manager <ul><li>The main reason why the traditional role of Test Manager has carried forward? People are not used to being without one. </li></ul><ul><li>The Test Manager’s role has to change in the long term, by expanding their role beyond defining strategies and plans (the expectation is that testers generate test plans) </li></ul><ul><li>The Agile Test Manager has become akin to a QA Manager – who is concerned with the overall QA process to deliver a quality product. </li></ul><ul><li>I do not believe it’s a cause for concern, simply an evolution in our positions as Test Managers. </li></ul><ul><li>One of the weakest areas in Agile specifications is test management – and it’s down to us to address that. </li></ul><ul><li>The Agile QA Manager can spread between on multiple projects – defining test strategies, reviewing project processes and maintaining testing momentum. </li></ul>
  6. 6. Agile Tester <ul><li>A big difference for testers on Agile projects is that test cycles change – it never stops. </li></ul><ul><li>Regression testing is always wise, so a pre-Sprint demo testing (after iteration) is prudent - best performed by the testers. </li></ul><ul><li>The team is an important part of Agile philosophy and contributing and bonding into that process is imperative for testing. </li></ul><ul><li>Test Automation is the future, so learn it now. </li></ul><ul><li>Remember there is no room for Tester (or Developer) wallflowers on a Agile project! </li></ul>
  7. 7. We’re working Agile!
  8. 8. Agile Business <ul><li>The business approach to risk needs to change, avoiding Waterfall type check-points (milestones) to measure risk. </li></ul><ul><li>Agile focus is on delivering fully-tested small features which diversifies risk, which should be an effective selling point. </li></ul><ul><li>The Product Owner is there to put the Agile business approach into practice, in Sprint planning process. </li></ul><ul><li>Each project can run to its own Agile methodology. </li></ul><ul><li>The lines of communication and reporting methods to the business should be a standardised set of processes (Agile framework) </li></ul><ul><li>This framework should define project core team structure, project submission requirements, and reporting checkpoints & exit criteria. </li></ul><ul><li>Test Assurance can help to ensure that Agile business approach is carried through. </li></ul>
  9. 9. Startup project <ul><li>Daily standups including all Agile roles </li></ul><ul><li>Continuous integration </li></ul><ul><li>2 week Sprints </li></ul><ul><li>Product Owner that filled the role </li></ul><ul><li>Scrummaster that filled the role </li></ul><ul><li>QA involved in every process review </li></ul><ul><li>Free flow of ideas across the team </li></ul><ul><li>Nothing in this world is perfect, but that was as closest as I have seen to Agile in action.. </li></ul>
  10. 10. Middleware Mobile Project <ul><li>Project inclined towards a purer development methodology </li></ul><ul><li>Daily stand-ups </li></ul><ul><li>Continuous code integration and build testing </li></ul><ul><li>Complete unit test automation </li></ul><ul><li>Well planned Sprints </li></ul><ul><li>What was missing that QA facilitated? </li></ul><ul><li>Testers! </li></ul><ul><li>Load testing (an Always-on Email service) </li></ul><ul><li>End to end testing </li></ul>
  11. 11. Software Development Methodology <ul><li>Agile development focus is on completing smaller </li></ul><ul><li>working features. </li></ul><ul><li>Continuous integration principles to minimise </li></ul><ul><li>integration issues. </li></ul><ul><li>Applying software methodology as intended, with </li></ul><ul><li>periodic exploratory testing will help avoid &quot;feature </li></ul><ul><li>clash“ </li></ul>
  12. 12. Key Agile development elements <ul><li>Shorter iterations </li></ul><ul><li>This aims to produce smaller set of working features. </li></ul><ul><li>Continuous integration </li></ul><ul><li>Ensuring regular testable builds, and enforcing unit testing as a default. </li></ul><ul><li>Cross-functional team </li></ul><ul><li>Many skills make lighter workloads </li></ul><ul><li>Daily stand-ups </li></ul><ul><li>Highlighting impediments (albeit process or code), and general awareness of everyone’s daily activity. </li></ul>
  13. 13. Example of making Agile work for you
  14. 14. <ul><li>Implement Agile Business Strategy </li></ul><ul><li>The business should lay out guidelines on how to initiate projects, and follow them through. Define lines of communication and reporting methods to the business should be a standardised set of processes. </li></ul><ul><li>Select methodology for project management </li></ul><ul><li>This should be customised to be in keeping with company-wide Agile framework (if there is one) </li></ul><ul><li>Ensure that the team fulfils Agile assumptions </li></ul><ul><li>Agile roles are there for a reason – they are key to success. </li></ul><ul><li>Relevant Product Owner </li></ul><ul><li>Scrummaster </li></ul><ul><li>The Team (development and testing) </li></ul><ul><li>QA Manager (not solely on one project) </li></ul><ul><li>Continuous build and integration </li></ul><ul><li>Every developer should be integrating their code daily, and running a quick build and unit test. Every developer should take the latest code base in the morning, then everyone is working on the same page </li></ul>
  15. 15. A cautionary tale ... <ul><li>Certified and experienced Scrummaster consultant. </li></ul><ul><li>Noted Agile testing consultant </li></ul><ul><li>Developers were coached and mentored. </li></ul><ul><li>Product Owner fully engaged in process </li></ul><ul><li>High budget </li></ul><ul><li>Why did it fail? </li></ul><ul><li>The project was entirely misconceived as they were working on what was essentially a set of shared web services. </li></ul><ul><li>What they were trying to do was implement was what an SOA architecture would have supplied, by using complex and ultimately unmanageable API’s. </li></ul><ul><li>This type of work wasn’t in the development teams skillset. </li></ul><ul><li>If Agile had been applied at business level downwards, this error would have less likely occurred. </li></ul>
  16. 16. Tuning Development Methodology <ul><li>Agile aims to avoid impact of feature implementations going wrong, and impacting another feature. So ensuring an Agile development process is not optional. </li></ul><ul><li>Take into account the type of project it is (greenfield, refactoring , etc ...) </li></ul><ul><li>Don’t assume development will work Agile automatically! </li></ul><ul><li>QA Manager can assist in decisions, though primarily Scrummaster task. </li></ul><ul><li>Don’t be afraid to change methodology – switching Agile development methodologies has little impact outside “the team” . </li></ul><ul><li>Above all, don’t forget other project dependencies – they are part of the Agile process. </li></ul><ul><li>The main reason these differing methodologies exist, is to tune Agile for different approaches – not to fix Agile problem. </li></ul>
  17. 17. Kanban <ul><li>Ideal Usage: Brownfield (abandoned/underused) </li></ul><ul><li>Designed to make Sprint planning more flexible, with no fixed Sprints. </li></ul><ul><li>Tighter management requirement, but leads to more optimal Sprints. </li></ul><ul><li>Helps avoid corner-cutting exercises, to complete Sprints backlog. </li></ul><ul><li>More project transparency </li></ul><ul><li>Challenges: </li></ul><ul><li>More daily testing work for the testers </li></ul><ul><li>Product Owner must be full-time </li></ul><ul><li>Difficult to sell “moving target” concept to the business </li></ul>
  18. 18. BDD (Behaviour Driven Development) <ul><li>Ideal Usage: Greenfield (new) </li></ul><ul><li>Similar to TDD, but with more focus on allowing Stakeholders, Product Owner and testers to contribute to the application design. User story workshop approach. More time with analysis, less coding time. </li></ul><ul><li>Test Scripts are written directly from the User Stories and scenarios. There are tools that turn these into pseudo code – effectively a test script, code written in natural language. </li></ul><ul><li>This is more time-consuming process initially, but development happens much faster, as the focus of BDD is delivering features. </li></ul><ul><li>Challenges: </li></ul><ul><li>Committed engagement from Stakeholder(s)/Product Owner </li></ul><ul><li>Dependency on cohesive interaction between business and deveolopment. </li></ul>
  19. 19. Agile QA Summary <ul><li>Process improvement </li></ul><ul><li>QA should to be involved in every Agile process review. </li></ul><ul><li>Exploratory testing </li></ul><ul><li>Exploratory testing extends the boundaries of testing scope beyond strict user stories and scenarios. </li></ul><ul><li>Early reviews </li></ul><ul><li>Testers can provide developers AND the business with early Sprint feedback – a Sprint is a longer time than you think. If you are using kanban, this is essential. </li></ul><ul><li>Regression testing </li></ul><ul><li>This is where a QA “arc” can ensure periodically there is fuller evaluation of the product progress with every iteration. </li></ul>