Agile3 Freature & Milestones Driven Development (AFMDD) Framework

Freatures & Milestones Driven Development (FMDD) Framework

 

The Agile3 Framework Goals..

  1. Focus on building software best practices/fundamentals, product features and achieve milestones - One of Agile3 Framewor goal is to reduce the process jargon from software development and focus more on 
    • Software Development Best Practices to build robust and configuration driven software
    • Strong Architecture Foundation - In a story driven development, the developer is focussed on narrow vision of delivering the story within 2 or 3 week sprint... There is not much room for debate on overall product feature and its vision, opportunity to do competitive study, improvise the feature and innovate. With Agile3 Framework the focus is more on Feature hence absolutely no reason to compromise on architecture. 
    • No quick and dirty way of coding
    •  
    • Better QA Testing - Testing team need not fit in the testing activities in a rush rush manner to fit in weekly timebox
    •  
  2. Focus on Product Features
    • Product Features - to help the team understand the purpose and vision behind the feature and help them innovate, improvise and implement the features
    • Feature driven thinking - as oppose to short sighted story
    •  
  3. Focus on Milestones
    • Speed to Market/Milestones Driven - In a changing competative world speed to market is very important to adapt 
    •  
  • Never miss a release date! The product release seems to slip more often than not especially in scrum. There are many reasons for this such as a defect requiring redisign due to "quick and dirty" method applied earlier, a QA cycle that is not properly defined and executed etc. While a very good Agile coach may help resolve and this problem may not be applicable to all agile teams, It is still a problem. 
      • With Milestone Date driven approach, these issues can be resolved to most extent... 
  1. Boost Creativity/Innovation - In Scrum and few frameworks - Product Owner writes up a feature in defined format. It makes Product Owner too powerful and leaves very less room for 
  • Instead Agile3 Framework gets rid of product owner role. Each product needs a direction - The Product Lead gives this direction in a Feature theme spec. The primary difference is, product lead explains rationale behind feature set request- however leaves at that, and entire team understands the requirement, works on it to flush it out... where as in Scrum, a single Product Owner does all this that may result in a) single point of failure if PO makes decision b) too much power with PO c) rest of the team is left out in feature defintion
    •  
  1. Boost employee happyness quotient
    • Development should not be a stress chamber 
    • Truly People over Process (One Agile Core principle)
    • Motivated team as oppose to team taking advantage of "getting thru daily standups"
  2. Better Role Definition
    • Give control back to Engg Manager over Scrum Master
    • Mitigate the single point of failure -"The Product Owner"
    •  
    •  
  3. Better Timebox Management
    •  
    • Variable length timebox for each feature. If you always fix the sprint length you end up either wasting time because you finish early or you move items because you can't finish.
    •  
    • Timebox concept is there, but not like sprint
  4. Simplified and Self Organized Project Management
    • Cut down the process meetings (In Scrum - planning, daily standups, retros, estimation poker etc) - its just not the meeting times, the cost of preparation is too high
    • Simplified Velocity Measurement
    • No waterfall in the end -- The Mile week is when some hardening activities happen hence the hardening is not left all the way to end increasing cycle of testing and hence in some project it becomes waterfall in the end

    The Agile3 Framework Goals..

    1. Focus on building software best practices/fundamentals, product features and achieve milestones - One of Agile3 Framewor goal is to reduce the process jargon from software development and focus more on 
      • Software Development Best Practices to build robust and configuration driven software
      • Product Features - to help the team understand the purpose and vision behind the feature and help them innovate, improvise and implement the features
      • Speed to Market/Milestones Driven - In a changing competative world speed to market is very important to adapt 
    2. Focus on Product Features
    3. Focus on Milestones
    4. Strong Architecture Foundation - In a story driven development, the developer is focussed on narrow vision of delivering the story within 2 or 3 week sprint... There is not much room for debate on overall product feature and its vision, opportunity to do competitive study, improvise the feature and innovate. With Agile3 Framework the focus is more on Feature hence absolutely no reason to compromise on architecture. 
    5. Never miss a release date! The product release seems to slip more often than not especially in scrum. There are many reasons for this such as a defect requiring redisign due to "quick and dirty" method applied earlier, a QA cycle that is not properly defined and executed etc. While a very good Agile coach may help resolve and this problem may not be applicable to all agile teams, It is still a problem. 

      With Milestone Date driven approach, these issues can be resolved to most extent... 

    6. Boost Creativity/Innovation - In Scrum and few frameworks - Product Owner writes up a feature in defined format. It makes Product Owner too powerful and leaves very less room for 

    7. No quick and dirty way of coding

    8. Development should not be a stress chamber 

    9. Boost employee happyness quotient

    10. Give control back to Engg Manager over Scrum Master

    11. Truly People over Process (One Agile Core principle)

    12. Mitigate the single point of failure -"The Product Owner"

      Instead Agile3 Framework gets rid of product owner role. Each product needs a direction - The Product Lead gives this direction in a Feature theme spec. The primary difference is, product lead explains rationale behind feature set request- however leaves at that, and entire team understands the requirement, works on it to flush it out... where as in Scrum, a single Product Owner does all this that may result in a) single point of failure if PO makes decision b) too much power with PO c) rest of the team is left out in feature defintion

    13. Feature driven thinking - as oppose to short sighted story

    14. Cut down the process meetings (In Scrum - planning, daily standups, retros, estimation poker etc) - its just not the meeting times, the cost of preparation is too high

    15. Variable length timebox for each feature. If you always fix the sprint length you end up either wasting time because you finish early or you move items because you can't finish.

    16. Simplified Velocity Measurement

    17. Motivated team as oppose to team taking advantage of "getting thru daily standups"

    18. Better QA Testing - Testing team need not fit in the testing activities in a rush rush manner to fit in weekly timebox

    19. Timebox concept is there, but not like sprint

    20. No waterfall in the end -- The Mile week is when some hardening activities happen hence the hardening is not left all the way to end increasing cycle of testing and hence in some project it becomes waterfall in the end

     

    he Agile3 Framework can be explained primarily by first focusing on what from Scrum and Kanban Frameworks are incorporated and what other principles.

    Agile3 Framework

    Scrum - Scrum organizes its principles in 3 major categories -- Roles, Artifacts and Events...

    Category Feature Borrowed From Agile3 Framework Agile3 Comments
    Roles Product Owner   Modified It is stupid to name one person as product owner. This risks entire product what gets build -- which is total contradiction to "team ownership" - how can team be owner if the story is defined by one person? Also introducing team ownership can be more motivating. Product Leader concept is much better option.
      Scrum Master   Modified The scrum master is not a bad idea except that the "certification" to become scrum master tend to be extremely bad and the chances of finding a bad "Scrum master" is lot more than good. Hence a modified approach is to build a process such that the role of scrum master itself diminishes to great extent...
      Team   Yes  
    Artifacts Backlog   Yes  
      Product Increment   Yes  
    Events Sprint   Yes  
      Sprint Planning   No  
      Daily Scrum   No  
      Sprint Review   No  
      Sprint Retrospective   No  
      Release Retrospective   No  
      Time box Sprint delivery Must   No  
    Visualize Work is visualized thru a sticky like workflow Kanban Yes - minus visuals  
      Limit WIP Items      
    Enhance Flow Manage flows and bottle necks      
    process policies Explicit entry - exit