Uploaded byStojan Peshov
Post-Agile Methodologies and all that Jazz
The document discusses the evolution and challenges of Agile methodologies in software development, highlighting issues like unsatisfactory processes, lack of collaboration, and the complexities in larger teams. It argues that while Agile principles focus on customer satisfaction and adaptability, they often fail in enterprise environments due to cultural resistance and inadequate practices. The document suggests a need for a re-evaluation of Agile, proposing concepts like experiment-driven development and antifragile systems to foster true innovation.
More Related Content
Similar to Post-Agile Methodologies and all that Jazz
Post-Agile Methodologies and all that Jazz
- 1. Post Agile and allthat Jazz
- 3. Me, myself andJava ● ETF, FEIT, FINKI ○ Eureka, Freelance, Genrep, Polar Cape ● 2002: Introduction with Java ○ Portals (CMS), ETL, hibernate ● EE since 2007 ○ spring, jsf, j2ee ● Current projects ● mobile (cordova, angularjs), test automation
- 4. Is Agile oldenough?
- 5. What is Agile? ●Ability to deliver early value to your customers ● Scrum is a framework based on empiricism: ○ inspection, adaption and transparency
- 7. Agile software developmentprinciples 1. Customer satisfaction by early and continuous delivery of valuable software 2. Welcome changing requirements, even in late development 3. Working software is delivered frequently (weeks rather than months) 4. Close, daily cooperation between business people and developers 5. Projects are built around motivated individuals, who should be trusted 6. Face-to-face conversation is the best form of communication (co-location) 7. Working software is the primary measure of progress 8. Sustainable development, able to maintain a constant pace 9. Continuous attention to technical excellence and good design
- 9. Is Agile bad? ●processes, behaviours & relationships which are unsatisfactory ○ people complain being pushed into it ○ and stuck inside without power to improve it ● the three roles, the five meetings, the one artifact ○ inertiа of the process ● CSM - Certified Scrum Master is like driver’s license ○ without experience .. it’s useless ● can't just change the IT department
- 10. Is Agile bad? ●estimate everything ○ with or without writing tests ● estimating with hours instead of points ● No CI / CD, no QA, no code reviews ● no time to clean tech debt ○ leave it for the next release ○ low quality code ● no continuous improvement
- 11. Is Agile bad? ●Reported vs Actual Progress ○ Not being honest about the progress ● Cultural differences / communication ○ when “Yes” means “Yes, I will do that” or “Yes, I’m listening” ● Emergent Design causes Software Entropy ○ Lack of architecture produces Big Ball of Mud ● Bad results with big, complex systems ○ Agile Fails in Enterprise
- 12. Agile Fails inEnterprise ● Lack of clarity ○ distributed / remote teams ● Continual reliance on legacy methods ○ transition to agile requires a significant shift in culture ● Inadequate experience with agile ○ Failure to adopt, small isolated projects, all roles should be included ● Lack of collaboration in teams composed by different companies
- 13. Agile Fails inEnterprise ● Lack of alignment in other areas of the enterprise ○ all teams must work agile or none ● Larger teams and big pyramid structures ○ more complexity, larger meetings and lowered productivity. ○ many bosses v.s. self organizing teams ○ two-pizzas team ● Not changing the objectives ○ measuring plan instead of change, adaption and flexibility
- 14. Is Agile Dead? ●Death is an inevitable process, ○ and everything, everywhere will continue to die ○ But it will take a while ● The job of the consultant is to grab a wave ○ and make money while he can, then grab another ● Nothing lasts forever, ○ but things based on solid engineering last longer ● Who said Agile is dead?
- 15.
- 16.
- 17. What’s Agile allabout Not about: Making money Self promotion Certificates Control
- 18. What’s next? ● Rediscoveringthe Heart of Agile ● Experiment Driven Development (EDD) ● Programmer Anarchy ● Antifrigile Manifesto ● Modern Agile ● MTFCKR ● Lean Startup ● Design Thinking
- 19. Rediscovering the Heartof Agile “Agile has become overly decorated. Let’s scrape away those decorations for a minute, and get back to the center of agile” - Alistair Cockburn
- 20. Experiment Driven Development(EDD) ● TDD is about design and verification of code. ○ EDD checks out whether the business works by tracking goals. ● EDD is to post-Agile what TDD is to Agile ○ displaces “working software as primary measure of progress” ○ with “validated learning and key metrics”
- 21. Programmer Anarchy ● Thereare no PMs, Iteration Managers, BAs, QAs / testers or “managers of programmers” ● with no managers to give power to their programmers to go ahead and develop, programmers go ahead and take total responsibility for the success of each project ○ in a form of self-organised “anarchy” ● “what if you were guaranteed not to fail” ○ They want programmers to lose the “fear of failure” ● Programmers work directly with the customer, ○ which builds more trust and understanding about how the SDLC is affecting delivery ● ...is still Agile Manifesto compliant
- 22. Antifragile Manifesto ● thesystem is self adaptive, so it grows like a human being. It receives stimuli which allows to make it stronger. ● it needs care. Like any human being, it may not be auto sufficient, it needs adjustments for its evolution. ○ This level of attention may be only given by a context aware organization, which perceives the contingency of Antifragility. ● it uses ontologies. Ontologies are non linear and scalable technologies. Thus, they are the ideal ground for the adaptivity process. ○ Such technologies represents a way to classify and recognize ongoing phenomena which are part of the system fitting.
- 23. Modern Agile Guiding Principles: ●Make people awesome ● Make safety a prerequisite ● Experiment and learn rapidly ● Deliver value continuously
- 24. Programming, Motherfucker We thinkthe shit on the left, is really just the con in the middle, and that we really need to just do the thing on the right… Programming, Motherfucker.
- 25. Before conclusion ● Agiledid not work ○ It shouldn't, you should! ● We have done it wrong over and over again? ● Improvisations ● Learning process ● Scrum reveals your problems, does not solve them for you.
- 26. Will it change? ●It will change, ○ because the market needs that, ■ progress needs that, ● society needs that. - Matthew Kern ● Something very weird was happening ● and i want it happening to me
- 27. Conclusion There are twopaths: 1. Evolution a. we need to evolve the process along with the languages 2. Revolution a. We are hungry for a change, something new
- 28. Evolution of buildingapps ● Microservices ○ allowing incremental changes in very discrete and manageable amount ● DevOps ● Low-code development platforms (LCDPs) ○ creating apps through configuration of functions, ○ rather than coding those functions ● TLA+ (Temporal Logic of Actions)
- 29. Bonus Slide: Jazzv.s. Agile ● Freedom ● Collaboration ● Fun / Enjoying ● Creative ● Should include the audience Agile, It all started well Just as in jazz, you improvise never know where you’ll end up. So, fell free, be creative, deliver us the future..
- 30. Twitter: @spesov linkedin: StojanPesov email: stojan.peshov@polarcape.com
Editor's Notes
- #9 Are there others?
- #10 The ‘new’ criticisms made against agile – that is, by those who have grown up with it, not those who opposed it in the first place – are rarely criticisms of the agile manifesto. there are two essentials to agile: treating people well; and never stop learning. Each of these two is only truly possible when the other is also practised. The essence of what makes Scrum work isn’t the three roles, the five meetings, the one artifact. It’s Inspect and Adapt. When things are not going as you like, you’re supposed to fix it."
- #12 No one really goes into any project blindly. The groundwork must be laid, the infrastructure must be decided upon, tools must be selected, and a general direction must be set. A focus on a shared architectural vision and strategy should be established early. Unbridled, change can undermine structure. Orderly change can enhance it. Change can engender malignant sprawl, or healthy, orderly growth. The biggest risk associated with Piecemeal Growth is that it will gradually erode the overall structure of the system, and inexorably turn it into a Big Ball of Mud.” Emergent design: https://effectivesoftwaredesign.com/2013/06/17/the-myth-of-emergent-design-and-the-big-ball-of-mud/?lipi=urn%3Ali%3Apage%3Ad_flagship3_pulse_read%3Bs7FY8nBpStKznB491yT3tg%3D%3D
- #13 Lack of clarity Sharing knowledge Continual reliance on legacy methods Mixed teams - pre-existing rigid/waterfall frameworks are to blame. Cultural differences Lack of a Testing Strategy QA must evolve as well Agile does not scale https://www.infoq.com/articles/agile-fails-enterprise?lipi=urn%253Ali%253Apage%253Ad_flagship3_pulse_read%253Bs7FY8nBpStKznB491yT3tg%253D%253D
- #14 Question: is Agile best suitable for startups?
- #15 Some people invent or try new things Others are just followers, they start propagating it until it becomes a common sense Some even build religion around it Until the first ones invent something new Success creates a religion or cult, and defeat is being ignored. No such doctrine is perfect. Thinking you will change the world with a manifesto is naive, and if you succeed you may not have improved the world.
- #19 http://alistair.cockburn.us/Rediscovering+the+Heart+of+Agile
- #22 At the start of the day the programmers choose their own work during daily stand-up meetings There are no PMs, Iteration Managers, BAs, QAs / testers or “managers of programmers” – all the normal rules of managing software development in a professional environment are gone. This is on the basis that formality and rules are constraining to creativity and productivity It runs on the concept that with no managers to give power to their programmers to go ahead and develop (managers “empowering” their teams), programmers go ahead and take total responsibility for the success of each project in a form of self-organised “anarchy” Integral to this is the adoption of the mindset “what if you were guaranteed not to fail” and the idea that disagreement and failure is expected, and both are ultimately productive outcomes. They want programmers to lose the “fear of failure” Programmers work directly with the customer, which builds more trust and understanding about how the SDLC is affecting delivery And to top it off Programmer Anarchy is still Agile Manifesto compliant:
- #29 https://www.theatlantic.com/technology/archive/2017/09/saving-the-world-from-code/540393/