Having established that a very large part of the success of agile projects is associated with effective communication, this section focuses on a particular set of activities in agile projects where communication is conducted in a more formal manner– agile meetings.
All agile methods stress the importance of regular, structured face-to-face meetings involving the project stakeholders, and this is certainly supported by virtually all of the case studies.
A wide range of reasons for and styles of meeting are advocated in the various agile methods, and range from simple fifteen-minute stand-up meetings to review progress, agree next tasks, and identify risks and barriers to achieving those tasks(as seen in Scrum projects), to several days for joint application design workshops(such as those held in RAD projects).
This section provides best practice guidance on agile meetings distilled from the experiences described in the case studies and other sources.
Agile Project Start-up Meetings
Project start-up meetings are an essential best practice in many of the existing agile methods(forming part of the preproject phase in DSDM, for example). A number of the case studies also cover the role and use of start-up meetings in the projects that they document.
Kingston, for example, describes the value of holding an initial project start-up meeting to introduce the stakeholders, confirm roles and responsibilities(and lines of communication), review and agree the tasks and overall timescales(at least at a high level), and to plan and prepare for the first iteration.
Denningreports the value of employing traditional project management approaches to agile testing projects and describes how PRINCE2project management controls, including a formal start-up meeting, were used to provide an appropriate approach to kicking off an important commercial project. In this casestudy, Denning’s company was contracted as a third-party testing partner, and it was commercially expedient to formally identify the project sponsor and have the terms of reference agreed and documented.
To ensure that all participants who are permitted to speak at an agile start-up meeting are given an equal opportunity to participate, and to ensure that those less extrovert members of the meeting are still encouraged to provide their valuable contribution to the proceedings, consider using the agile communications techniques described by Evans in her case study.
Agile Iteration Start-up Meetings
The established agile methods, such as Extreme Programming(XP)with its iteration planning meetings and Scrum with its sprint start-up meetings, all promote the role and use of formal start-up meetings for each iteration. These meetings are used to agree the tasks to be worked on(selecting user stories in XP, for example) and their timescales, to agree how the tasks are assigned, and to identify risks and discuss their mitigation.
A number of the case studies(Kingston, and Phillips,;for example)also include a checkpoint in iteration start-up meetings to review and, where appropriate, incorporate the lessons learned from previous iterations. Phillips reports that reviewing the lessons learned has been particularly beneficial in terms of keeping the project testing processes as up to date as possible and ensuring their relevance to the project testing requirements.
Kingston explicitly includes the discussion and agreement of the test plan for the iteration, plus any specific timescales, resources, and/or staff that are needed to support the iteration test plan in the iteration start-up meeting agenda.
Both Scrum and XP promote the use of short daily stand-up meetings(typically limited to fifteen minutes). The purpose of these meetings is specifically to talk about what was achieved the previous day, what is planned to be worked on today, and what risks or barriers there might be to achieving these goals.
Such meetings are highly focused on the work at hand, even to the extent of only permitting certain team roles to speak while others attend simply to listen to the proceedings(such as the pig and chicken roles in Scrum projects). in XP, an interesting incidental goal of the daily meeting is to reduce the need for other meetings that might take place through the day.
Sewell reports that the benefits of holding daily stand-up meetings have included helping to reinforce the concept that effective testing is the key to delivering higher-quality code and also in breaking down the “us and them” issues many projects observe between developers and testers.
May provides a cautionary warning that overrunning, poorly focused, and poorly facilitated stand-up meetings are likely to be a symptom that an agile project is failing to be run in an agile manner. May urges that teams adhere closely to the duration and principles of the stand-up meeting and observes that where such meetings overrun or are ineffective, it is likely to be because the meeting has been hijacked to discuss design issues or to debate how best to fix a particular problem.
Interim Iteration Meetings
Gilb, Chana , and Kingston all report significant benefits of working to a “natural” iteration period(such as a one-or two-week iteration interval). These authors also discuss the role of regular interim iteration meetings and their benefits in ensuring that good progress is maintained, specifically in the iteration but also in the project in general.
Gilb describes the benefits of such meetings in providing an additional opportunity for the project manager and customer to review progress against the iteration plan and for the customer to review and approve the tasks and associated design for the next tranche of development and testing activity. Chana reports the benefits of integrating a weekly iteration meeting into an existing regularly scheduled team telephone conference call. In the case of his project, Chana was able to provide progress updates to his project manager during the course of the call and obtain feedback from the usershis teammates)on the state of the developing system(a team Wiki)as well. Chana cautions care in piggy-backing on an existing meeting and recommends that the agile review items are formally included in the meeting agenda and covered off early in the meeting.
Kingston describes the benefits of such a regular meeting on an offshored agile project. Specifically, a weekly telephone conference call with the developer team in India was employed as an additional project control to confirm that the tasks in the current iteration were on track and that there were no risks or dependencies that might cause the team to fail to meet its deadlines. Kingston does advise caution in obtaining progress report information outside of a face-to-face meeting environment and recommends that all estimates are firmly challenged(often with the same question being repeated in a slightly different manner)to avoid any misunderstandings due to language or cultural differences.
Gilb makes the important observation that a very important lesson to be learned is that there is always another lesson to be learned. A key practice in his Evo method is to continually fine-tune the agile best practices by capturing iteration and project lessons learned and acting on them.
In an agile project environment it is particularly important that the agile process and practices being used on the project are, and remain, as effective and efficient as possible. Sewell makes the point that during the course of a single project(even of moderate duration)it is possible for testing best practices to change, for new techniques to be published, or for new tools to become available(or even new releases of existing tools with new functionality). Being receptive to such changes and, where appropriate, adopting and using them can help fine-tune the effectiveness of an agile project.
Phillips describes the use of a testing specific retrospective at the endof each iteration in which the lessons learned in the previous iteration are reviewed and, where appropriate, actions are put in place to improve the testing process and/or keep it up to date with respect to new best practices or tools that may have become available since starting the project. In agile retrospectives it is particularly important that all members of the team are encouraged and given the opportunity to contribute their views, and the techniques for improving communication between team members described by Evans are particularly appropriate to these meetings. Another valuable perspective on agile retrospectives, and techniques for making them successful.
Although many of the more recent agile methods emphasize the benefits of short,sharp, and highly focused meetings, there may be project tasks that must be accomplished that do not lend themselves easily to a fifteen-minute stand-up meeting. RAD and DSDM, for example, both include guidance on running longer sessions, such as RAD’s joint application design workshops. Where complex issues need to be discussed, where important decisions need to be agreed upon, and where key project artifacts(such as the business requirements document or the project test plan)need to be generated, a longer style of meeting may be necessary.
Denning emphasizes the role of more traditional project management approaches to running agile projects, including the role of longer meetings where necessary and their success in managing customer expectations.
Maymakes a case for “extended meetings” on projects where the customer and development team are not co-located to ensure the developers have gained a thorough understanding of the customer needs as well as an appreciation of the customer culture and preferred means of working. In practice, these meetings could be scheduled across a number of days to achieve their goals.
Agile Project Closedown Meetings
With the emphasis the case studies place on learning from experience in agile projects(Gilb)and process improvement(Tilt, for example), an agileproject closedown meeting can provide an excellent opportunity to reflect on the lessons learned throughout the project.
Kingston describes the successful use of such a meeting and its value in providing an opportunity to harvest the lessons learned from all of the previous project meetings.
Meeting Focus: A Final Thought
As a final thought on the subject of agile meetings, I offer a particularly embarrassing moment from my own career, which emphasizes the need for good focus in meetings as well as the need for a strong facilitator.
I still cringe when I recall a project meeting I attended in my younger days, which was being chaired by a formidable project manager, a lady named Ruth Woodhead. In what I thought was a slack moment in the meeting, and while Ruth had to take a short but important phone call, I began to chat with a colleague about the recent rugby success that Wales had been enjoying. The next thing, Ruth was asking me conversationally–“John, do you like the radio quiz show ‘Just a Minute’?” “Definitely,” I answered enthusiastically, thinking I could earn some brownie points(and not spotting the trap); “DEVIATION,” she said simply, instantly taking back her iron grip of the proceedings, and leaving me blushing acutely! Suffice it to say, I have never forgotten the lesson.
Agile Testing Related Interview Questions
|ETL Testing Interview Questions||Manual Testing Interview Questions|
|Selenium Interview Questions||Database Testing Interview Questions|
|Automation Testing Interview Questions||Software testing Interview Questions|
|Performance Testing Interview Questions||Embedded Testing Interview Questions|
|A/B Testing Interview Questions||Hadoop Testing Interview Questions|
Agile Testing Tutorial
Old-school Development And Testing
Agile Development And Testing
From Waterfall To Evolutionary Development And Test
How To Test A System That Is Never Finished
Implementing An Agile Testing Approach
Agile Testing In A Remote Or Virtual Desktop Environment
Testing A Derivatives Trading System In An Uncooperative Environment
A Mixed Approach To System Development And Testing: Parallel Agile And Waterfall Approach Streams Within A Single Project
Agile Migration And Testing Of A Large-scale Financial System
Agile Testing With Mock Objects: A Cast-based Approach
Agile Testing – Learning From Your Own Mistakes
Agile: The Emperor’s New Test Plan?
The Power Of Continuous Integration Builds And Agile Deve- Lopment
The Payoffs And Perils Of Offshored Agile Projects
The Basic Rules Of Quality And Management Still Apply To Agile
Test-infecting A Development Team
Agile Success Through Test Automation: An Extreme Approach
Talking, Saying, And Listening: Communication In Agile Teams
Very-small-scale Agile Development And Testing Of A Wiki
Agile Special Tactics: Soa Projects
The Agile Test-driven Methodology Experiment
When Is A Scrum Not A Scrum?
Analysis Of The Case Studies
My Agile Process
The Roll-out And Adoption Of My Agile Process
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.