Closed BenRongey closed 4 years ago
What do you think? A. Agile methodology initially appears chaotic due to it's non-linear, non-deterministic, and dynamic features, but in the end these are actually it's major strengths. The very nature of software development is a game-changer in terms of planning and production, as software tends to change rapidly and evolve constantly. The entire methodology (in my eyes) revolves around the competition between adaptive development versus predictive development. The problem with predictive development is the emphasis on early-phase analysis, and if that analysis goes wrong, then the team or the entire project may have trouble course-correcting to the new reality. The entire purpose of Agile is to solve this outdated (when describing software) methodology.
How do agile teams measure progress? A. According to Agile Principle # 7, working software is a primary measure of progress. This means that while you may have a rockstar development team, if they haven't created working software then they're as good as the useless software they've developed (so far!). For a typical software engineering team, usually the project manager would measure the progress of a program via tracking of stories through Github and/or Kanban. If they so wanted, they could create a burn-down chart of points (of stories) completed on a per-sprint basis. The easiest way to make sure progress is progressing is via regular meetings (especially face-to-face interaction) including daily standup meetings to make sure that everyone is accomplishing goals and minimizing blockage.
How do agile teams work together? A. Agile teams work together several different ways. Agile Principle # 6 suggests that face-to-face communication is best (especially co-location). The principle of co-location is that coworkers on the same team should generally be situated together to better establish the identity as a team and to improve communication. Every team should include a customer representative (in scrum, a Product Owner). This person is agreed by stakeholders to act on their behalf and is available to developers to answer questions throughout the sprint or iteration. Agile teams should also use an information radiator for development purposes. It is typically a large display near the development screen where passers-by can see it. It presents an up-to-date summary of the product development status. In Revelry's case, we use Kanban. We also have regular meetings (such as the daily standup and sprint retrospectives) to stay focused and remove any blockers.
What are some ways in which the Revelry "Lean Agile" approach addresses the 12 Agile Software Development Principles? Do you see any ways in which our approach doesn't address the 12 Principles? A. Revelry's "Lean Agile" addresses nearly all of the 12 Principles. For example, customer satisfaction (Principle # 1) is achieved by making the customer involved in the process. The lean part of "Lean Agile" puts emphasis on regularly shipping valuable software, which allows for easy changing of requirements (Knocking out Principle #s 1-4). Where "Lean Agile" or specifically Revelry's policy may not address the 12 Principles is Principle # 6, specifically the portion about co-location. The nature of Revelry's setup is that a large portion of the development team is spread out in different locations. Revelry addresses this however, with daily standups and regular face-to-face meetings via Zoom.
Read the 12 Agile Principles here: https://en.wikipedia.org/wiki/Agile_software_development#Agile_software_development_principles
Questions: