20 DAYS:


A Post-Agile Product Development Framework


Building software is not hard.

Building the right software that solves the right problems and achieves business outcomes is very hard.

Conventional software development practices do not support the nature of business and people anymore.

Agile of course introduced a significant shift in the way teams worked and the ways products are built. The 12 Principles of the Agile Manifesto will likely stand the test of time (I hope it does), but its practices are progressively being diluted into other forms and there is a never ending argument of doing Agile correctly and with nearly all organisations claiming to do Agile, the term is becoming progressively meaningless.

20DAYS combines principles of Design Thinking, Lean and Agile to bridge the gap between people and technology. The core structure follows a constant feedback loop that revisits the actual users, the problem and solution in a 20 day period.

20DAYS is a framework to take ideas, assumptions, business problems and hypothesis through a process of ideation, conception, validation, production, delivery and continuous improvement.

<h1><u>20 DAYS:</u></h1> <br/><i><h2>A Post-Agile Product Development Framework</h2></i>

The framework suggests common tools and methods that can be introduced along the workflow, but it does not require or enforce any practice in-particular, as people work and excel in different ways.


It is designed to bring people together to determine and agree on outcomes.

A solution and strategy is developed with the focus being on how the team (client, users and Digital Village members) are going to have those outcomes realised.

With clear problem definition, outcomes set, and hypothetical solution in place, development begins following a feedback loop that is designed to ship working software into production within the first 20day module.

The process then begins again after a decision to either take immediate learning and put them back into product development or revisit the solution and strategy with stakeholders.

STEP 1: Discover Who and Why (Divergent thinking)


Why are you embarking on this project?
Are you solving a problem?
Do you have a great idea?

Outcomes

  • Discover the customer problem
  • Discover the user/s

  • Tools
  • User Interviews
  • Affinity Clustering
  • Rose Thorn Bud
  • User Journey Map
  • Empathy Map

  • View tools and methods you can use in this phase

    The framework suggests common tools and methods that can be introduced along the workflow, but it does not require or enforce any practice in-particular, as people work and excel in different ways.



    STEP 2: Define Problem & Outcomes (Convergent Thinking)

    With a collection of ideas, assumptions, concerns, risks and possibilities, we democratically refine the collective thinking of the group into agreed problems to be addressed and the outcomes to measure.

    Outcomes

  • Defined Users
  • Defined Problem
  • Defined measurable outcomes

  • Tools
  • How Might We statement

  • View tools and methods you can use in this phase
    The framework suggests common tools and methods that can be introduced along the workflow, but it does not require or enforce any practice in-particular, as people work and excel in different ways.



    STEP 3: Develop Solution (Divergent thinking)

    How will we achieve the measurable outcomes?
    What are the great ideas?

    Outcomes:

  • A collection of possible options and ideas

  • Tools
  • Creative Matrix
  • Alternative Worlds
  • Importance/Difficulty Matrix
  • Visualise the Vote

  • View tools and methods you can use in this phase
    The framework suggests common tools and methods that can be introduced along the workflow, but it does not require or enforce any practice in-particular, as people work and excel in different ways.



    STEP 4: Define Solution (Convergent thinking)

    In this step, we focus the collective intelligence of the team to determine and agree on the best solution that will meet the desired outcomes.

    Outcomes

  • Defined Problem and hypothetical solution
  • Clearly defined and measurable outcomes

  • Tools
  • Concept Poster
  • Round Robin

  • View tools and methods you can use in this phase

    The framework suggests common tools and methods that can be introduced along the workflow, but it does not require or enforce any practice in-particular, as people work and excel in different ways.



    STEP 5: Build Solution (Design & Engineering)

    With a plan in place, the next iteration begins to test a new hypothesis, trial a new feature or begin the next development sprint. The Producer collaborates with the cross functional teams to flesh out the solution and build the solution.

    Outcomes

  • Working software
  • The framework suggests common tools and methods that can be introduced along the workflow, but it does not require or enforce any practice in-particular, as people work and excel in different ways.



    STEP 6: Measure (Analysis, Automation & Testing)

    The collection of feedback and data from what has been built is carried out until there is enough evidence to form a conclusion and validate the solution (or not).

    Outcomes

  • Test Results
  • Metrics
  • The framework suggests common tools and methods that can be introduced along the workflow, but it does not require or enforce any practice in-particular, as people work and excel in different ways.



    STEP 7: Learn (Decision)

    This is the feedback loop that either goes directly back to the build step or back to discovery phase.

    Outcomes

  • What did we learn?
  • How do we know?
  • What should we do now?
  • The framework suggests common tools and methods that can be introduced along the workflow, but it does not require or enforce any practice in-particular, as people work and excel in different ways.

    Why 20DAYS

    Communication

    Common problems in IT project delivery such as the often mis-alignment between business strategy and product development. Communication of intentions, objectives and problems is often lost in translation between tech teams and management. Which results in the wrong things being built and business outcomes not being realised.

    Culture

    Accountability is often passed down the ranks as human nature and ego motivates people to ‘not look bad’. The fear of failure is something that strangles innovation and can only be changed through a shift in culture. 

    Outcomes

    It is a beautiful aspect of humanity that each person is completely unique. People generally don’t consider this and expect other people to see the world as they do. Unfortunately, this is not the case and it naturally creates walls of misunderstanding. Particularly between management teams and tech teams who have usually grown into the world with completely different backgrounds and view the world with uniquely developed filters. 

    Opinions of what’s important and of value differs greatly. The business side typically doesn’t care for tech and just wants outcomes at the best price in the shortest time possible. And engineers love digging deep in solving problems and can often over-engineer or over-design solutions. 

    By bringing people together, designing for outcome delivery, building quickly and getting continuous feedback, the 20day method builds a culture of togetherness, has people align and focus on outcomes and generally makes work more enjoyable.

    Start a Project With Digital Village

    Are you ready for a 20-day turnaround on your project, with your own team of Digital Specialists and a Producer to run the project for you?


    Continuous Improvement & Innovation


    Continuous Improvement

    The process is fundamentally a feedback loop of constant iterations to trial and test ideas and functions.

    Modular

    Projects are broken into smaller modules to reduce risk, deliver faster and allows easy and transparent billing.

    Collaborative

    Working together to combine peoples thinking produces well rounded solutions and buy in from all.

    Data Driven

    Data-driven development iterations make sure that you are building what is most important for your users at that time.

    Cost Effective

    Reducing unnecessary development and planning small modules of ongoing development is better for cashflow. There is no hidden costs and there is no lock contracts.

    Efficient & Effective

    Costs are reduced and the right product is built from the start because nothing is being built without it first being validated.