As an Agile Leader, Where do I Start?

In my view, We should Start right from Backlog Creation until Retrospectives:

  • Backlog Creation
  • Backlog Refinement
  • Daily Stand-ups
  • Execution Practices
  • Demonstration/Reviews
  • Retrospectives

Backlog Creation

Good Time for the Product Owners to produce the Product Road-map, that can show the anticipated deliverable’s over time. The Product Owner re-plans the Road-map based on what the team produces.

Backlog Refinement

In iteration-based agile, the Product Owner can use this time to make the team understands what the stories are along with their size and the relationship between them. In flow-based Agile, Just-in-time refinement would be fine where the team can take the next card off the to-do column and discusses it.

Product Owner is expected to lead this discussion and the Servant Leader is expected to facilitate the same

Daily Stand-ups

A brief, daily collaboration meeting in which the team reviews progress from the previous day, declares intentions for the current day, and highlights any obstacles encountered or anticipated. Servant Leader is expected to help the team learn how to integrate those items.

Execution Practices

  • Continuous Integration – A Practice in which each team member’s work products are frequently integrated & validated with one another.
  • Test at all levels: Employ System Level Testing for End to End Information and Unit Testing for the building blocks. In between, understand if there is a need for integration testing and where. Agile teams have a strong preference for automated tests so they can build and maintain a momentum of delivery.
  • Accepted Test Driven Development (ATDD): The entire team gets together and discusses the acceptance criteria for a work product. Then the team creates tests, which allows the team to write just enough code and automated tests to meet the criteria.
  • TDD (Test-Driven Development) & BDD (Behavior Driven Development): Writing automated tests before writing/creating the product actually helps people design and mistake-proof the product.
  • Spikes (Time-boxed research or Experiments): Spikes are useful for learning and may be used in circumstances such as estimation, acceptance criteria definition, and understanding the flow of a user’s action through the product. Spikes are helpful when the team needs to learn some critical technical or functional element.

Demonstrations/Reviews

The team receives feedback about how the product looks and operates through a demo. Demonstrations or Reviews are a necessary part of the Agile Project Flow. Product Demonstration is a fundamental part of what makes a project agile.

A team that does not demonstrate or releases working product cannot learn fast enough and is likely not adopting agile techniques.

  • In Iteration-based agile, the team demonstrates all completed items at the end of the iteration.
  • In Flow-based Agile, the team demonstrates completed work items when it is time to do so, usually when enough features have accumulated into a set that is coherent.

Retrospectives

Team members retrospect to see how they can inspect and adapt their process to succeed. Capture items to improve at each retrospective. Servant Leader is expected to help the team learn how to integrate those items.

Iterations & Increments

Iterations help a team Creating a cadence for delivery & Getting different kinds of feedback. The Team produces increments of value for delivery and feedback.

Few Thoughts on Comprehensive Documentation

Software Projects are typically initiated with the goal of creating valuable, high-quality software. Software Projects without documentation is certainly problematic and hampers support and maintenance, but comprehensive documentation without functional software is valueless to most organizations.

What would be the reason that the Software Projects often get caught up on interim deliverables such as extensive documentation?

  • With the mood to make software development more of an engineering discipline in the 1980’s and 1990’s, there was a heightened demand for documentation and because this period was also the advent of increasingly large teams, complex software systems, and a legacy of undocumented, unsupportable applications, such documentation was essential.
  • Many software developers are detail-oriented and process-driven; although these characteristics are often highly beneficial, they can also mean the developer’s focus can easily be distracted from the real reason they are undertaking software projects – to write valuable software.

Closing Thoughts

Considering the above stated Developers Focus Distraction, the Agile Manifesto’semphasize on valuing

working software over comprehensive documentation

Because, these projects are commissioned in the first place To build working software, and is absolutely Not To build extensive documentation with the expense of working software. Isn’t it? Do You also Agree?

Please share your views as comments:

You could also visit my other Articles on https://www.hangoutagile.com/blog

Join our Whats-app Group (+91 702 538 1111 – Hangoutagile Community) specifically to discuss your:

  • Day to day business challenges
  • Learning on Lean/Kanban/Agile Transformation & Coaching
  • Best Practices on Lean/Kanban/Agile Transformation & Coaching
  • Experience on Lean/Kanban/Agile Transformation & Coaching

Please share your Cell Number along with LinkedIn Profile URL to the Email ID: Nadia@diaame.com OR WhatsApp to +91 702 538 1111.

Are You Curious to Participate in any of My Agile Coaching or Training Certification Events, Please write to Info@diaame.com

!!! :-😊) HAPPY LEARNING :-😊) !!!