During an Agile consultation, some questions often come back on the table. Here are a top 5 of the most common questions clients have:
Question 1: How would you describe agile?
Agile is adaptable and open to different interpretations.
Keep this in mind when interviewing project manager candidates.
Agile is a project management framework that emphasizes iterative development in order to produce high-quality results.
Agile is essentially a methodology that focuses on producing working software, collaborating openly, and optimizing processes.
Collaboration is valued more than any particular set of tools, processes, or technical specifications.
Other aspects of agile principles may be included in a more detailed response.
Project managers should be aware that agile teams embrace change, even late in the development process, and place a premium on working software over extensive documentation.
Question 2: What distinguishes agile methodology from traditional methodologies?
The primary distinction between agile methodology and other traditional methodologies is that agile methodologies use an incremental development model, whereas traditional methodologies use a sequential model. The development and testing phases of agile methodology run concurrently.
Traditionally, the testing phase begins after the development phase is completed. The agile methodology allows for greater flexibility by making it easier to implement changes.
Changes are difficult to incorporate in traditional methodologies because requirements are frozen before development work begins.
Agile methodology necessitates less documentation. Because of the rapid delivery, developers make changes to the code as needed. Traditionally, the development process begins only after the team has received the completed documented requirements.
Customers participate in all stages of the agile software life cycle, reviewing the product and suggesting changes as needed. Customers are primarily involved in the requirements gathering phase in traditional methodologies. They typically see the finished product at the end of the development life cycle.
Question 3: Which would you prefer, Scrum or Kanban?
This is a question almost every team asks, and not the easiest one to answer. To choose between Scrum and Kanban, you must first understand their differences to determine which is most applicable to your team’s environment. If each coach prefers one methodology over the other, each customer, each team, and each product will have requirements and constraints associated with one of the two.
A team that begins with agility and transforms itself after years of V-cycle work requires assurance, visibility, and the display of a schedule and milestones. It will then discuss Scrum and its concepts of “burndown,” “iterations,” “roles,” and “estimated product backlog.” They may, however, be drawn to the kanban with swimlanes method, which enables them to re-prioritize elements that have become critical (such as bugs) during the course of a project and are better suited to a heterogeneous or specialized team.
For these reasons, methodology flexibility is recommended through the use of Scrumban, which combines the best of both methods. Agility should not be a constraint on teams; it should enable them to perform at their best to deliver a valuable and high-quality product. The method must adapt to the team, not vice versa.
Question 4: Why does the burndown counter not decrease as tasks are completed?
What a perplexing query! The team is working, but the burndown, a metric used to track the progress of work, is not decreasing, velocity is decreasing, and User Stories are taking longer to develop than expected. By delving deeper and interrogating various team members, we quickly identify the issue: the developers are working on tasks other than the User Stories in the backlog, and thus are not delivering the expected value.
The Product Owner is frustrated that his functional User Stories are not being delivered; the Product Manager is frustrated that his functional User Stories are not being delivered.
The developers are frustrated because they are completing high-value technical tasks while the burndown continues to rise. This intense frustration is the result of a lack of communication, visibility, and organization.
A critical rule is that the Product Owner must be aware of and track all tasks in the backlog (in JIRA, on the physical board, …).
The Scrum Master (or technical lead) must present these tasks to the Product Owner, who is the backlog’s sole guarantor. The Product Owner may include one or more technical tasks, which will be estimated and prioritized in the same manner as the other User Stories.
He can also choose to devote a certain number of points to these technical tasks during each sprint, leaving the team free to choose its subjects.
Question 5: We spend a great deal of time in meetings and yet are still required to produce a large number of points. Is this acceptable?
No, it is not acceptable to spend time in a meeting and then be required to produce the same number of points as if the meeting never occurred.
Please note that this is not to say that developers should spend all of their time in front of their computers and should be denied meetings because their sole responsibility is to produce. Developers, like the rest of the team, must avoid burying their heads in the sand and unpacking the backlog; they may be required to attend meetings throughout the sprint. However, we must make every effort to make these meetings as productive as possible.
To begin, there are the traditional sprint ceremonies, which I subtract directly from my velocity calculation (= for a two-week sprint, I subtract between 1 and 2 velocity points per developer for the ceremonies).
There are two possible solutions for unexpected meetings:
- If we know, for example, that the Product Manager returns information at the end of each sprint, we can allow some points to these meetings. For example, if a team of five developers with a velocity of 20 points has a two-hour sprint meeting lasting two weeks, three points will be deducted from the velocity calculation.
- If we do not know when and for how long these unexpected meetings will occur, we will need to review the sprint backlog on an individual basis and adjust the number of points committed.
