Agile projects are ideally a collaborative effort among the team members and with the customers, and the planning process should be a similar endeavor. Everyone should get a clear understanding of the project as well as their respective roles and responsibilities. As the saying goes, well begun is half done. A well-planned kickoff meeting sets the tone for a successful project.
Operating on the philosophy that one must thoroughly know the rules before one can break them, a global company developed its own delivery model that is still as true to the agile mindset as is possible. Join Arjay Hinek in this lively session as he deconstructs his company's experiment in melding agile with construction project management to create a hybrid delivery model. At first, the teams were struggling with clear ownership, timely communication, and clear follow-through on work in progress. From modifying the user story mapping model in order to improve project initiation to dissecting and rewriting the values and principles of the Agile Manifesto, Arjay stretched agile practices to the limit to help his teams strive and grow through iterative and incremental delivery. Arjay will share the struggles, failures, and successes of this innovative experiment.
Substantial confusion exists about the roles and responsibilities of test management when using an agile software development process. Agile seeks to streamline project management and leadership under the role of a ScrumMaster, but what does this mean for test managers? How do they stay...
Testing dashboards can give stakeholders the false impression that projects are under control. But are they really? As a tester, you can see a counter indicating a high percentage of passing tests but know that you may still have critical failures in the product. Alexandre Bauduin will...
You've heard of a minimum viable product, which has only enough features to create a working model and provide feedback for further development. If you want to get started on a new project quickly, Allan Kelly suggests assembling a minimum viable team—only a few people, with only the necessary skills. They begin work right away, with a small budget and tight feedback loops, driving down risk.
Imagine this scenario: Business users are excited to finally get their hands on an implementation delivery that is on schedule, (mostly) on budget, and passed rigorous testing with flying colors. Unfortunately, when working with the new app or feature, the users realize that the way they described their needs didn’t translate into what they actually needed. Sound familiar? While she may not be able to offer telekinetic mind-reading tools, Kim Tatum is convinced that leveraging a behavior-driven development (BDD) approach helps bridge the gap between domain experts and technical teams. Join Kim to discuss how natural, human-readable language ultimately creates shared accountability and reduces misunderstandings. Review how this framework is implemented on a variety of delivery projects and walk through an implementation approach and leading practices.
Many organizations appear to suffer anxiety at the thought of programming. They want to get everyone but the programmers in a room to discuss a project down to the minute and the dollar, without a full understanding of the coding required. But a few hours of code experimentation generates far more understanding than days of debate by architects and analysts. Don't be scared of programming.
Of all issues that impact getting quality products out on time, the team should never focus on simply managing costs. To minimize the risk of perpetual product delivery delays, define what “done” really means.
The space shuttles Challenger and Columbia were two of NASA's biggest disasters. Investigations into these accidents discovered the engineering issues responsible, but management practices and cultural barriers also were found to be contributing factors. Does your organization have a healthy culture that lets you safely voice concerns? It could help you prevent tragedy.
Test plans are essential for communicating intent and requirements for testing efforts, but excessive documentation creates confusion—or just goes unread. Try the 5W2H method. The name comes from the seven questions you ask: why, what, where, when, who, how, and how much. That's all you need to provide valuable feedback and develop a sufficient plan of action.