|
|
|
|
|
|
| |
| SPONSORED BY: TargetProcess |
Agile Project and Resources Management
Designed with simplicity in mind, TargetProcess helps to reduce the complexity of software project management and simplifies Planning, Tracking, QA and Resource allocation activities. TargetProcess supports SCRUM, XP and other Agile processes. Sign up for a 30-day trial or download our Free full-featured Community Edition.
http://targetprocess.com/Product/Try/Trial.aspx?source=Iterations
|
| MEDIA SPOTLIGHT |
Gray Matters Podcast: Linda Rising
In this episode of Gray Matters, Joey McAllister chats with Linda Rising at the 2008 Better Software Conference & EXPO about deception. Do we deceive ourselves and others about estimation? Do we have a choice?
http://www.stickyminds.com/podcasts#GM0608 |
|
|
| |
|
|
| |
WHAT'S NEW:
Check out the latest Web seminar brought to you by StickyMinds.com and Better Software magazine
|
"Ensuring Business Value from Distributed Testing in an Agile Environment" * Sponsored by Cognizant * In agile environments and across distributed teams, prioritizing and communicating values becomes imperative to ensure the right product is developed. For such teams, storyboards that clearly state the business value are of tremendous value to everyone on the project: to stakeholders, testers, project managers, and the customers. Business value is the key metric that every team member should be following. Join us Thursday July 24, at 11 a.m. ET, when speakers Pollyanna Pixton and Shiva Balasubramaniyan describe how to use clearly defined business values to help distributed teams succeed. http://www.sqe.com/go?WS072408AGILE
Register and attend this Web seminar to be automatically entered into our drawing for a StickyMinds.com PowerPass! |
|
|
| |
|
|
| |
AGILISM: Defining the Movement
Continuous Integration |
"Continuous integration describes a set of software engineering practices that speed up the delivery of software by decreasing integration times. It emerged in the Extreme Programming (XP) community, and XP advocates Martin Fowler and Kent Beck first wrote about continuous integration near the turn of the millennium."
From wikipedia.org |
|
|
| |
|
|
| |
CONTENT POINTER:
Secrets to Automated Acceptance Tests
By Jeff Patton |
Has your team been on the search for a fully automated acceptance test? Before you set out on that adventure, check out some of the accomplishments and perils behind the quest for complete automation, as explained by Jeff Patton. Fully automated acceptance tests may seem like the solution to many problems, but you should know that it comes with a few problems of its own.
http://www.stickyminds.com/s.asp?F=S13798_COL_2 |
|
|
| |
|
|
| |
BOOK REVIEW:
Continuous Integration
By Paul Duvall, Steve Matyas, and Andrew Glover |
Reviewed By: Dan Luciano
Continuous Integration by Paul M. Duvall, et al. is an excellent book and should be on every software developer's bookshelf. The book, written in a clear style with plenty of examples, is for all levels of developers, from novice to expert. The book is divided into two parts: The first part gives an excellent background on the principles and practices of using a continuous integration approach to developing software. The second part is a more detailed explanation of those principles and practices.
Keep reading at http://www.stickyminds.com/s.asp?F=S1071_BOOK_4 . |
|
|
| |
|
|
| |
POWERPASS POINTER: Conference Material
Agile Release Planning: When "You'll Get It When You'll Get It" Won't Sell
By Stacia Broderick |
When some people hear the words "agile planning," they think it is an oxymoron. While more knowledgeable people think of agile planning as getting ready for one iteration of development, there is more to agile product planning than a single iteration. Although agile teams like to focus on one iteration at a time, what do we say when executive management asks questions like "What will this product actually do?" or "When will it be ready for the customer?" or "How much will it cost?" When the answer "You'll get it when you get it" just won't sell, you must perform high-level release planning to address these important questions. Stacia Broderick describes an agile release planning framework under which agile development can be effective. Stacia takes you through the complete process she recommends for release planning and explains, most importantly, why and how the agile release plan can and must remain just that—agile.
http://www.stickyminds.com/s.asp?F=S12794_CP_2 |
|
|
| |
|
|
| |
| Agile Development Practices Conference 2008 |
November 10-14, 2008 | Shingle Creek Resort | Orlando, Florida
Learn the latest in agile methods, technologies, tools, and leadership principles from thought leaders who deliver inspiring keynote presentations, in-depth tutorials, and a wide range of conference classes. Network with your peers during informal gatherings and discuss your challenges with experts in agile practices.
* Register Early and SAVE $200! * http://www.sqe.com/go?ADP08Iteration |
|
|
| |
|
|
| |
THE AGILE EXPERIENCE:
Rolling Lookahead Planning
By Mike Cohn |
Agile processes replace some of the upfront planning of a traditional process with a just-in-time approach in which plans are progressively refined. For the often-used example of a team working in isolation, progressive refinement usually takes the form of creating a high-level release plan and then planning each iteration as it starts. While this is often sufficient for the lone team working on a desert island, it will generally be inadequate on a project being built by multiple teams. When a team needs to integrate its work with the work of other teams, all teams involved will usually benefit from what is known as rolling lookahead planning.
A team doing rolling lookahead planning will begin its iteration planning meetings just like any other team. Usually this is by doing commitment-driven iteration planning, which takes most teams two to five hours to plan a two- to four-week iteration. This is because commitment-driven iteration planning requires the team to determine which product backlog items it will commit to deliver during the iteration by carefully considering each. Product backlog items are discussed and considered in roughly the priority order established by the product owner or customer. The tasks necessary to complete a product backlog item are identified and estimated. When the team finishes discussing the work involved to complete a product backlog item, team members decide whether they can commit to completing it in the coming iteration.
Once the current iteration has been planned, the team remains in the iteration planning meeting and plans two more iterations. Wait, before you panic let me point out that while it often takes two to five hours to plan the first iteration, this is because the second and third iterations are planned at the user story or product backlog item level rather than with tasks as was done with commitment-driven iteration planning for the current iteration. Using data such as its historical average velocity, or a projection of future velocity if there’s a good reason to deviate from history, the product owner and team identify the product backlog items that are likely to be developed in the next two or so iterations.
The team is not committing to deliver these more distant items in the same way it is committing to complete the product backlog items of the current iteration. Specific commitments will be made to those iterations when each rolls forward to become the current iteration. Until then, each is planned only at a high level and only by identifying the work likely to be done in each iteration.
A team does not perform rolling lookahead planning to identify design considerations for the current iteration, although that may occur and be a side-benefit. The chief purpose of rolling lookahead planning is the coordination of work to be done by multiple teams. As new iterations roll into the planning horizon, teams look ahead to the functionality likely to be developed in those iterations. In doing so, teams on a large project are likely to find dependencies upon one another.
For example, suppose both your team and mine are ready to plan the fourth iteration of what will be a seven-month project. We conduct separate meetings, committing to features to be developed in iteration four. We separately identify and estimate the tasks to be performed in that iteration. Before concluding our separate meetings, our teams each use historical velocities to forecast what they will do in iterations five and six.
After both iteration planning meetings are over, you tell me that your team has identified a dependency on my team. You need me to develop something and pass it along to you so that you can complete a particular product backlog item. I tell you that my team cannot do it during iteration four as we just finished planning that iteration. That’s fine with you because you don’t need it until iteration six as it just now rolled into view. We agree that my team will develop the requested functionality in iteration five, delivering it to you at the start of iteration six. By looking ahead two iterations we have successfully avoided the emergency of "my team needs this from you this iteration" that can otherwise be common on large agile projects.
Rolling lookahead planning, and specifically looking ahead two iterations, is a useful technique that belongs in the toolbox of any agile team working on a large project.
Find out what you missed in past issues of iterations at: www.stickyminds.com/eNewsletters/iterations/Default.aspx?eNewsletter=Archive |
|
|
| |
|
|
| |
ADVERTISEMENT:
New Agile Training Courses from SQE Training
|
Implementing Agile projects in your organization and want to master Agile Development techniques? SQE Training has a new agile training program for you. Learn, experience, and practice the ScrumMaster approach to managing development. Practice using test-first design development methods. Gain experience developing programs in small verifiable steps for better designs. Create user stories that describe what the user really needs. Attend two courses in the same location and save up to $300.
Register today! http://www.sqe.com/go?AGWK1 |
|
|
| |
|
|
| |
AGILE IN MOTION:
Planning for Dependencies
Interview with George Schlitz |
A principal agile coach and cofounder of BigVisible Solutions, George Schlitz has been using agile practices on projects since 2000. In the following interview, George discusses rolling lookahead planning, its advantages, and a recent implementation on a large program he coached.
Iterations: What is "rolling lookahead planning"?
George Schlitz: In short, with rolling lookahead planning we try to maintain a "window" of planning more than one iteration in advance. This allows us to schedule stories with dependencies in a most-efficient and least-risky way when the dependencies are on other teams. This practice is very useful on large programs that have situations involving teams needing to wait on the results of other teams to complete specific stories.
So, Story1 might require the results of Story12 to be completed. If team 2 is doing Story12 and team 1 is doing Story1, then Story1 should be planned for the iteration after team 2 completes Story12. In agile release-planning workshops, I encourage this practice. When we leave the release-planning session, stories with dependencies on other teams are scheduled to start after expected completion of the dependencies. If you plan Story1 for the same iteration as Story12, hoping that Story12 will somehow get done early enough for team1 to get Story1 done, you are taking on a lot of risk. In my experience, this is successful very rarely. A combination of this scheduling and placing "feeding buffers" behind the dependencies help protect the ability to start the dependent story.
Iterations: What are the advantages of rolling lookahead planning?
GS: Scheduling of stories with dependencies in a manner that introduces the least risk and least churn. It encourages thinking about implications of stories and dependencies.
Iterations: Give an example of rolling lookahead planning in action.
GS: On a large program I was recently coaching, we conducted a release-planning exercise. During this exercise, each team came up with a by-iteration release plan—the list of stories each would attempt to accomplish during the upcoming release. Some of these stories consumed results of stories from other teams. We scheduled stories ensuring that we did not start stories in an iteration if they had unresolved dependencies on other teams. This helped us avoid various wastes ... we took on stories when they were "ready" in one regard. Buffers for the stories that were needed by other teams and encouragement for teams to tackle these stories first helped ensure that they were completed. |
|
|
| |
|
|
| |
Iterations is an extension of StickyMinds.com and Better Software magazine—and a reminder that your "online resource for building better software" is just a click away at www.StickyMinds.com |
|
| |
|
|
| |
SUBSCRIBER SERVICES
|
You are receiving this issue of iterations as part of your StickyMinds.com membership, Better Software magazine subscription, or iterations subscription. We hope this publication will be a useful and enjoyable benefit. To change your email address or update your preferences, go to www.stickyminds.com/eletters.asp?fx=change. To ensure optimal receipt of these emails, please add iterations@lists.stickyminds.com to your address book or all messages from @lists.stickyminds.com to your email white list. To unsubscribe, go to www.stickyminds.com/eletters.asp?fx=unsub.
If this eNewsletter has been forwarded to you by a friend, you can register for your own free subscription to iterations at www.stickyminds.com/eletters.asp
SOFTWARE QUALITY ENGINEERING • 330 CORPORATE WAY • STE. 300 • ORANGE PARK, FL 32073 |
|
|
| |
|
|
|
|
|
|
|