Showing posts with label Software Development. Show all posts
Showing posts with label Software Development. Show all posts

Sunday, 15 June 2025

Agile Manifesto in the Age of AI

 

 Reimagining Software Development for the Era of Generative Intelligence

How the foundational principles of Agile development are being transformed—and challenged—by AI-powered coding assistants and autonomous development agents

Twenty-three years ago, seventeen software developers gathered at a Utah ski resort and forever changed how we build software. The Agile Manifesto they created prioritized individuals over processes, working software over documentation, customer collaboration over contracts, and responding to change over rigid planning.

Today, as generative AI and agentic coding tools reshape the development landscape, we face a pivotal question: Do these timeless principles still hold, or do we need Agile 2.0 for the AI age?

The answer is we need change in manifesto




The New Development Reality

Before diving into how Agile principles evolve, let's acknowledge the seismic shift happening in software development. AI coding assistants can now:

  • Generate entire applications from natural language descriptions
  • Refactor legacy codebases in minutes rather than months
  • Write comprehensive test suites automatically
  • Debug complex issues by analyzing stack traces and logs
  • Translate between programming languages instantly
  • Create documentation that stays synchronized with code changes

This isn't just automation—it's augmentation of human cognitive capabilities. We're not just working with tools; we're collaborating with artificial intelligences that can reason about code, architecture, and even business requirements.

Revisiting the Four Core Values

1. Individuals and Interactions Over Processes and Tools

The Traditional View: Agile emphasized human communication, face-to-face conversation, and collaborative problem-solving over rigid processes and heavyweight tools.

The AI Evolution: This principle becomes both more important and more complex when "individuals" now include AI agents as active participants in development teams.

What's Changing:

  • New Collaboration Patterns: Developers are learning to effectively communicate with AI through prompting, providing context, and iterative refinement
  • Enhanced Human Focus: With AI handling routine coding tasks, humans can spend more time on creative problem-solving, architecture decisions, and stakeholder communication
  • Hybrid Team Dynamics: Teams must balance human-to-human collaboration with human-to-AI partnerships

The Risk: Over-reliance on AI tools could inadvertently reduce human-to-human communication. Teams might fall into the trap of working in isolation with their AI assistants rather than collaborating with colleagues.

Best Practice: Establish regular "AI retrospectives" where team members share their AI collaboration experiences, successful prompting strategies, and lessons learned. This maintains the human connection while optimizing AI partnership.

2. Working Software Over Comprehensive Documentation

The Traditional View: Agile valued functional software that delivers user value over extensive documentation that might become outdated or irrelevant.

The AI Transformation: This principle gets supercharged in ways the original manifesto authors couldn't have imagined.

What's Changing:

  • Rapid Prototyping: AI can transform requirements into working prototypes within minutes, making "working software" the natural starting point rather than the end goal
  • Living Documentation: AI can generate, maintain, and update documentation that stays synchronized with code changes, eliminating the traditional documentation debt
  • Self-Documenting Systems: AI-generated code often includes better comments, clearer variable names, and embedded explanations

The Paradox: While we can produce working software faster than ever, we must be more vigilant about ensuring it solves the right problems. Speed without direction is just sophisticated waste.

Best Practice: Use AI to rapidly create multiple working prototypes of different approaches, then engage stakeholders in evaluating which direction best serves user needs.

3. Customer Collaboration Over Contract Negotiation

The Traditional View: Agile emphasized ongoing customer involvement, feedback loops, and collaborative requirement discovery over fixed contracts and specifications.

The AI Enhancement: AI dramatically amplifies our ability to collaborate with customers in real-time.

What's Changing:

  • Real-Time Iteration: Changes can be implemented and demonstrated within the same customer conversation
  • Better Requirement Translation: AI can help bridge the gap between ambiguous customer requests and specific technical implementations
  • Rapid Experimentation: Multiple approaches can be quickly prototyped and presented to customers for feedback

The New Challenge: Customers might develop unrealistic expectations about delivery speed for complex features. The ability to quickly implement surface-level changes doesn't mean underlying complexity has disappeared.

Best Practice: Use AI's rapid prototyping capabilities to help customers understand requirements better, but maintain realistic expectations about the difference between prototypes and production-ready solutions.

4. Responding to Change Over Following a Plan

The Traditional View: Agile valued adaptability and responsiveness to changing requirements over rigid adherence to predetermined plans.

The AI Amplification: This principle becomes both easier to implement and more critical to embrace.

What's Changing:

  • Adaptive Architecture: AI agents can help refactor code to accommodate changing requirements more quickly and safely
  • Faster Feedback Loops: Changes can be implemented, tested, and demonstrated more rapidly
  • Continuous Evolution: Systems can be more easily restructured as understanding of requirements evolves

The Deeper Implication: With change becoming easier to implement, teams must become even better at understanding why changes are needed and which changes create the most value.

Best Practice: Establish clear value frameworks and success metrics so that increased adaptability serves strategic goals rather than becoming chaotic feature churn.

New Principles for the AI Age

While the original four values remain relevant, the AI era demands additional principles:

5. Human Judgment Over AI Automation

The Principle: While AI can generate code with superhuman speed, human judgment remains irreplaceable for understanding context, making ethical decisions, and ensuring solutions serve genuine human needs.

Why It Matters: AI can optimize for the metrics it's given, but humans must define what success actually means in the broader context of business goals, user experience, and societal impact.

In Practice:

  • Humans define the "what" and "why"; AI helps with the "how"
  • Critical decisions about architecture, security, and user experience require human oversight
  • AI suggestions are treated as starting points for human evaluation, not final answers

6. Intentional AI Partnership Over Blind Delegation

The Principle: Effective AI collaboration requires understanding AI capabilities and limitations, maintaining clear boundaries between AI and human responsibilities, and treating AI as a powerful tool rather than a replacement for thinking.

Why It Matters: Teams that blindly delegate to AI without understanding its reasoning or validating its output risk creating solutions that are technically correct but contextually wrong.

In Practice:

  • Team members develop AI literacy and understand how to effectively prompt and guide AI tools
  • Clear protocols exist for when to trust AI output and when to seek human verification
  • Regular evaluation of AI tool effectiveness and appropriate use cases

7. Continuous Learning Over Static Skills

The Principle: With AI capabilities evolving rapidly, teams must commit to continuous learning and adaptation rather than relying on static skill sets.

Why It Matters: The half-life of specific technical skills is shrinking, but the ability to learn, adapt, and effectively collaborate with AI is becoming a core competency.

In Practice:

  • Regular training and experimentation with new AI tools and techniques
  • Knowledge sharing sessions where team members demonstrate AI collaboration strategies
  • Career development paths that emphasize adaptability and AI partnership skills

Practical Implementation: Agile Ceremonies in the AI Age

Sprint Planning 2.0

Traditional Focus: Estimating story points, assigning tasks, and planning sprint capacity.

AI-Enhanced Approach:

  • AI Impact Assessment: Explicitly discuss which stories can benefit from AI assistance and which require primarily human insight
  • Learning Allocation: Reserve time for experimenting with new AI tools or techniques
  • Validation Planning: Plan for human validation of AI-generated solutions
  • Prompt Engineering: For complex AI-assisted tasks, plan time for developing effective prompts and iteration strategies

Sample Questions:

  • "Which of these user stories could we prototype with AI to better understand requirements?"
  • "What AI tools should we experiment with this sprint?"
  • "Where do we need the most human oversight for AI-generated code?"

Daily Standups Evolved

Traditional Focus: What did you do yesterday, what will you do today, what's blocking you?

AI-Enhanced Questions:

  • "What did you learn about effective AI collaboration yesterday?"
  • "Are there any AI-generated solutions that need human review today?"
  • "What AI-related blockers or limitations are you encountering?"

Sprint Reviews Reimagined

Traditional Focus: Demonstrating completed functionality to stakeholders.

AI-Enhanced Approach:

  • Solution Comparison: Show multiple AI-generated approaches that were considered
  • Decision Rationale: Explain why human judgment led to specific choices among AI options
  • Learning Showcase: Demonstrate new AI collaboration techniques discovered during the sprint

Retrospectives Plus

Traditional Focus: What went well, what didn't, what should we try next sprint?

AI-Enhanced Questions:

  • "How effectively did we collaborate with AI tools this sprint?"
  • "What AI-assisted approaches worked well or poorly?"
  • "What did we learn about prompt engineering and AI delegation?"
  • "How can we better balance AI efficiency with human insight?"

The Definition of Done Gets Smarter

Traditional Definition of Done criteria might include code review, testing, and documentation. In the AI age, consider adding:

AI-Specific Criteria:

  • Human review of all AI-generated code for context appropriateness
  • Validation that AI solutions meet non-functional requirements (performance, security, maintainability)
  • Confirmation that AI-assisted features actually solve the intended business problem
  • Documentation of AI tools used and key prompting strategies for future reference

Managing the Risks

The Speed Trap

Risk: The ability to rapidly generate code might lead to premature optimization, over-engineering, or building the wrong thing faster.

Mitigation: Maintain strong user research practices and require validation of assumptions before scaling AI-generated solutions.

The Understanding Gap

Risk: Developers might use AI-generated code they don't fully understand, creating maintenance nightmares and security vulnerabilities.

Mitigation: Establish code review practices that specifically focus on understanding and explaining AI-generated solutions.

The Dependency Dilemma

Risk: Over-reliance on AI tools could leave teams helpless when those tools are unavailable or produce poor results.

Mitigation: Maintain core coding skills and regularly practice manual implementation of critical system components.

The Future of Agile Leadership

Leadership in AI-augmented Agile teams requires new skills:

Technical Leadership:

  • Understanding AI capabilities and limitations
  • Helping teams develop effective AI collaboration strategies
  • Making decisions about when to trust AI vs. require human judgment

Cultural Leadership:

  • Fostering environments where humans feel valued alongside AI capabilities
  • Managing the psychological impact of AI on team dynamics
  • Maintaining focus on user value and business outcomes

Strategic Leadership:

  • Balancing speed enabled by AI with thoughtful decision-making
  • Investing in team AI literacy and continuous learning
  • Evolving organizational practices to leverage AI effectively

Conclusion: Agile's Enduring Wisdom

The Agile Manifesto's core insight remains profound: software development is fundamentally a human activity that requires collaboration, adaptability, and customer focus. AI doesn't change this truth—it amplifies it.

The most successful teams in the AI age won't be those who replace human judgment with artificial intelligence, but those who thoughtfully combine human creativity, empathy, and contextual understanding with AI's computational power and speed.

As we stand at this inflection point in software development, the choice isn't between Agile and AI—it's about evolving Agile practices to harness AI's potential while preserving the human-centered values that made Agile successful in the first place.

The future belongs to teams that can dance between human insight and artificial intelligence, maintaining the collaborative spirit of Agile while embracing the superhuman capabilities of AI. In this new world, the most Agile thing we can do is continuously learn how to be more effectively human in partnership with increasingly capable machines.

What's your experience with AI-augmented Agile practices? Share your insights and challenges in the comments below, and let's continue evolving these practices together.

Monday, 3 March 2025

Implementing GenAI in Engineering Teams - System Thinking Approach


In the rapidly evolving landscape of software development, Generative AI represents not just another tool, but a fundamental shift in how engineering teams operate. However, successful implementation requires more than just access to the latest AI tools—it demands a systematic approach to change management and team adaptation.


Challenges In GenAI Adoption

Many engineering teams rush to adopt GenAI tools like GitHub Copilot or Claude etc, hoping for immediate productivity gains. Yet, without a structured approach, these implementations often fall short of expectations or, worse, create new inefficiencies. The key lies in understanding that GenAI adoption is a systems challenge, not just a technical one.


A Systematic Framework for Implementation


Drawing from Donella Meadows' "Leverage Points" model, here's a practical framework for implementing GenAI in engineering teams, organised from foundational elements to transformative changes.


Start with the Foundations (Parameters & Buffers)



Before diving into complex transformations, establish your baseline:

- Set clear metrics for current development speed and quality

- Allocate 20% of team time for AI tool learning

- Maintain manual coding capabilities for A/B test

- Track costs and benefits per developer


Build the Structure


Structure your implementation around:

- A pilot team with clear objectives

- One primary AI tool (e.g., GitHub Copilot, Cursor , Aider , Windsurf etc)

- Specific use cases (test generation, documentation, new code , refactoring , code review etc)

- Regular feedback mechanisms


Optimize Information Flow


Success depends on effective knowledge sharing:


- Create an internal prompt library

- Document successful patterns and anti-patterns

- Establish clear guidelines on AI capabilities and limitations

- Regular updates on new AI features and best practices


Establish Clear Rules and Processes


Protect quality and security with:

- Mandatory review processes for AI-generated code

- Security scanning protocols for work produced by AI

- Data privacy guidelines

- Clear escalation paths for AI-related issues


Foster the Right Mindset


The most crucial transformation happens in how teams think about their work:


- Position AI as an augmentation tool, not a replacement

- Focus on high-value problem solving

- Encourage experimentation and learning

- Build confidence through small wins


Measuring Success


Track progress through:


Speed Metrics

   - Code completion time

   - Time saved on repetitive tasks

   - Documentation generation speed


Quality Indicators

   - Code review feedback

   - Bug detection rates

   - Technical debt metrics


Team Adaptation

   - AI tool usage rates

   - Prompt effectiveness

   - Knowledge sharing participation


Common Pitfalls to Avoid


Tool Overload: Starting with too many AI tools simultaneously

Unrealistic Expectations: Expecting perfect code from AI

Neglecting Training: Not investing in team AI literacy

Ignoring Process: Bypassing code review for AI-generated code

Poor Documentation: Not capturing lessons learned


The Path Forward

Successful GenAI implementation is a journey, not a destination. Start small, focus on concrete wins, and build momentum through systematic change. Remember that the goal isn't to replace human developers but to augment their capabilities and free them to focus on more complex, creative problem-solving.


Key Takeaways


1. Start with clear metrics and baseline measurements

2. Focus on one team and one tool initially

3. Build strong feedback loops and learning mechanisms

4. Maintain high quality standards

5. Foster a culture of experimentation and learning


The future of software development lies in the effective collaboration between human creativity and AI capabilities. Teams that can systematically implement these tools while maintaining their engineering excellence will find themselves at a significant advantage in the evolving technological landscape.

Remember, the goal isn't to completely transform overnight, but to build a sustainable, efficient system that leverages AI to enhance human capabilities rather than replace them.

Friday, 15 November 2019

Complexity Accidental vs Essential

Today it is hard to find team or organization that is not following agile but building software has not become easy, projects are missing schedule , over budget and it is also flawed.

Image result for software complexity"
Why it is so hard to build software ?

If you ask this questions to any engineer then 90%+ will say requirement, but is that the full truth ?

Lets try to decompose software construction. Every feature has 2 important component that decides whether feature will be successful or not.

  • Essential complication (ec)
  • Accidental complication( ac)


We will do some Functional programming refresher.

Feature = f( Essential Complication) + f(Accidental Complication )

Essential complication comes from domain like if you are building software for medical industry then it is complex. Accidental complication is complexity added by engineers, process & management to build feature.

Essential complication are hard to reduce because of domain, but to some extent it is possible to reduce by using good decomposition techniques. Decomposition is hard skill and comes from experiment of some fail projects.

Accidental complication can be controlled but it is not linear function, accidental complication is not same in every part of system and gets more complex over time. This also gives feedback on how much bad job we have done as engineer or product team.
Complexity comes in various forms like communication in team, less understanding , difficulty reusing some feature , extending program to new function, management problems etc.

Now we know accidental complication is exponential, so lets write formula again.

Feature = f( Essential complication) + f(Accidental complication * Unknown)) 

Now it will become clear why something takes many times longer than estimate or guess. Product owner also has part to play in adding accidental complication by marking assumption on importance of feature.

What can be done ?
If we need some predictability or consistence in delivery then we have to continuously work on reducing accidental complexity. Lets look at ways to keep to keep this in control.
  • Using higher level languages.
  • Incremental development by growing the software not building it.
  • Good buy vs build decision. 
  • Unified programming environment. 
  • Raid prototype to refine requirement.
  • Listen to design pressure.
  • Test driven development.
  • Stop "Get it out of the door" mindset.
  • Reduce "surgical strike effort" in delivery.
Very insightful quote from Frederic Brooks, both customer and engineer has to learn what to ask, expect, and commit otherwise only option is broken system.

“An omelette, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices—wait or eat it raw. Software customers have had the same choices. The cook has another choice; he can turn up the heat. The result is often an omelette nothing can save—burned in one part, raw in another.”
― Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering


Mythical-Man-Month by Mr Brooks is must read for every product owner , project manager and engineer.

If you like the post then you can follow me on twitter.

Wednesday, 2 October 2019

Progressive delivery

Coupling is one of the important pattern for building software and it is recommended to build loosely coupled systems. 
Lets talk about loose coupling pattern in software deployment context.


Image result for evolution

Industry has seen evolution in Devops space in form of continuous integration,continuous delivery, automated testing etc but world is moving fast and we need CI/CD++.  Next step after CI/CD is Progressive delivery.

Deploying  != Release
Progressive delivery could sound like cool tech jargon but it simply comes down to drawing line between Deploying in productions vs Activating in production.

This new way of deploying software gives control on how do you want to roll out new features to customers. It gives control on whether to upset all users vs small set of users to get some feedback before whole world knows about it.

A version of progressive delivery is also called Blue-Green deployment, A/B testing , canary testing, feature toggle etc.

Benefit of progressive delivery 
- Low ceremony way of enabling features to user.
- Safe way of testing things in production.
- Less git conflicts to manage because code does not sit in git after it is developed.
- Better operational management because deployment is done in Parts. Your support team will love it.
- Avoid frustration of working on noisy Pre production.  
- Product team are empowered to decided when they want to open it for external users.

Last with not least that Progressive delivery methodology allow team to control blast radius when rolling out new software.

Share your progressive delivery experience. 

If you like the post then you can follow me on twitter.

Sunday, 8 September 2019

Tracer bullet software development

Software development methodology is evolving very fast and every team has found version that works well in current context.

Software development methodology is going through continuous improvement.

The_Pragmatic_Programmer book talks about Trace bullet approach and as per that it comes down to feedback. The more quickly you get feedback, less change is required to hit the target.

I have used Tracer Bullet approach through out my career with good success.

I will share another approach or mindset of software development that can be used in some scenario to build better product and create value.

Explore or Discovery 
Image result for discovery images

Many time as team you have to find what is the next feature you should be building that will help in increasing adoption of product.
So i call this as Explore or Discover phase and this phase of development has very different goal and trade off. This phase means that you have to move fast, cut some corners to get feedback. This phase will not have enough tests, documentation, code quality is not good etc.

Important thing about this phase is you are actively collecting feedback on whether this is the next big idea your team will be investing.
In this phase you have to make sure you gain more than loose, so timebox discovery phase to keep track on resource that is consumed.

Outcome of successful discovery puts you in Growth phase and in many case this will be steep growth, but every unsuccessful outcome has lots of signal on next exploration.

 You Build to learn in this phase and once you learned then move to next phase or start another discovery.

Growth Phase
Image result for growth images

This phase is outcome of successful discovery and now you have found the next feature that market or your target audience need.
Trade off for this phase is very different from Explore phase, you have to stabilized feature , do changes based on feedback so users who have shown interest in idea are still engaged. Users who got on-boarded work like your sponsor, so keep them in loop.

Interesting things about this phase is your team will be in war room type of situation, everyone is trying to get over huddles and get feature out.

Word of caution this phase very intense and demanding. This phase is the real "Sprint" phase not the agile sprint! putting extra hours has good returns.
Another thing to watch out is to be persistent in exploiting maximum of new feature but many time team drops the ball and go back to discovery phase. 

I would say this phase also puts design pressure on team and you can refer to design-pressure-on-engineering-team post that talks about it.

Successful outcome of this phase is Expand phase. Team is exhausted after this phase but very motivated.

Expand Phase
Image result for expand images

Welcome to phase that requires building software in the way we learn in text book, this is the phase where engineering discipline are very important because solution has to be scalable, maintainable , reliable etc.
Now you can go to management and ask for more funds to get servers , expand team etc because this idea will generate some profit.

Don't build product like discovery phase in this stage otherwise you will become victim of your own success, below image should be good example of it.

Image result for victim of your own success

Conclusion
All of these phases has very different constraint and trade off and it is very important to know that, expand phase can't be managed like explore phase or vise versa and i have also found that engineering disciplined are very very different in these phase, so you need team that is aligned with mindset. If you get your team wrong then it can really very challenging to execute phase.

It is fascinating to see that our industry keeps on evolving and new development methodology are found.

It is much more than Agile or scrum.

I want to end with quote
As engineering team we should do continuous exploration and exploration is not linear process.

Some of other post on software development that you might interesting

need-driven-software-development-using
broken-promise-of-agile
cargo-cult-innovation-center

I will be happy to learn about new ways of building software, so please share it!

If you like the post then you can follow me on twitter.