|
|
|
|
|
|
| |
| SPONSORED BY: Rally Software |
Agile Project Management — Try It Free
Sign-up now for a free, 10-seat subscription to Rally's Jolt award winning Agile life cycle management solution. Unite Agile project management with tracking of requirements, tests and defects for simpler, low-burden management of your software projects. Sign-up now for your free subscription!
http://www.rallydev.com/community_ed.jsp?src=iterations061108
|
| MEDIA SPOTLIGHT |
StickyMinds SoundByte: Michele Sliger and Mary Gorman
In this episode, Michele Sliger talks about non-IT examples of agile in motion. Then, Francesca talks about Mary Gorman and Bryan Sullivan's column and what's coming out in the June issue of Better Software magazine.
http://www.stickyminds.com/podcasts#SMSB0508b
|
|
|
| |
|
|
| |
WHAT'S NEW:
Check out the latest Web seminar brought to you by StickyMinds.com and Better Software magazine
|
"Agile Reporting and Metrics: Project Intelligence for Successful Software Delivery" * Sponsored by ThoughtWorks * Learn from and discuss with three of the world's foremost agile metrics experts about what metrics you should be tracking, how to inform management and other stakeholders of project progress, and which tools help identify risks. Join us June 24, 11 a.m. ET. http://www.sqe.com/go?WS062408agile
Register and attend this Web seminar to be automatically entered into our drawing for an iPod Shuffle!
|
|
|
| |
|
|
| |
AGILISM: Defining the Movement
Causal Loop Diagrams |
"Systems can be modeled as nodes representing system variables and connecting lines representing causal effects. The changing value of one variable can cause another to increase or decrease as described by equations. Understanding how a system really works is the first step toward using, improving, automating or explaining it to others.
Causal Loop Diagrams are used to model dynamic systems. The simple diagram notation of nodes and lines identifies the important variables in a system and how they interact."
From ExcelSoftware.com
|
|
|
| |
|
|
| |
CONTENT POINTER:
Recognizing Agile Candidates
By Johanna Rothman |
Recognizing candidates who are capable of performing well on agile teams doesn't require keyword searches through a stack of resumes. It requires asking candidates questions that allow them to show you they understand the principles and can apply them in their daily work--even if their resume doesn't list particular terms. In this StickyMinds.com weekly column, Johanna gives some excellent tips for the interviewer and the interviewee.
http://www.stickyminds.com/s.asp?F=S11417_COL_2 |
|
|
| |
|
|
| |
BOOK REVIEW:
Agile Retrospectives: Making Good Teams Great
By Esther Derby and Diana Larsen |
Reviewed By: Janet D. Kennedy
Agile Retrospectives: Making Good Teams Great brings the skills that experienced facilitators use to the realm of the technical team leader. The forward by Ken Schwaber, well known for his work with Scrum methodology, lends credibility to the topic and should be sufficient to hold the attention of most skeptical readers. The book is well organized and informative. Following the instructions, even an inexperienced team leader can have a successful retrospective.
Keep reading at http://www.stickyminds.com/s.asp?F=S954_BOOK_4 .
|
|
|
| |
|
|
| |
POWERPASS POINTER: Magazine Archive
You Can Teach an Old PMO Agile Tricks
By Michele Sliger |
Every manager has a story to tell. Find out how one management professional tackles a fictional dilemma. The story may be made up, but the solutions are tried and true. In this installment, Michele Sliger tells the tale of the movement of a Program Management Office away from waterfall toward agile.
http://www.stickyminds.com/s.asp?F=S9695_MAGAZINE_2
|
|
|
| |
|
|
| |
| 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 |
|
|
| |
|
|
| |
THE AGILE EXPERIENCE:
Three Common Misconceptions about Agile Teams
By Esther Derby |
At a recent workshop, two managers had strong reactions to my description of self-organizing agile teams. "You can't just turn people loose and let the team make all the decisions. They'll mess things up," one manager declared.
"With all these ScrumMasters, agile coaches, and self-organizing teams, sounds like I'm out of a job," another said with resignation.
I frequently hear these points of view when I visit organizations that are adopting agile methods. In this article, I'll put these concerns to rest, along with two other misconceptions about agile teams.
Misconception: Self-organizing teams don’t need managers.
The fact that your company is using agile methods doesn’t mean every manager is out of a job. Self-organizing teams need managers, too. But they need different things from their managers than traditional manager-lead teams do.
There's a reason we use the term "self-organizing" rather than "self-organized." That’s because it's a process.
Most agile teams start from more traditional, manager-lead teams and begin the journey by organizing and managing their own work. Gradually, the team takes on some of the decisions that have traditionally been management decisions. That can include managing their own team membership, shaping product decisions, and allocating bonuses amongst team members.
But they don't get there without expert coaching from their managers, and they won't get there on day one.
Agile teams need their managers to communicate the organizational context, transfer knowledge and skills, coach, and remove impediments. And I'm pretty sure most agile teams would appreciate it if their manager dealt with the budget and HR matters.
Misconception: Timeboxing forces any group to become a team. Put a group of people together, hand them a challenge, and they'll jell.
I wouldn't bet on it. Teams do need a compelling task. They also need the technical skills required by the work and interpersonal skills to form a social system. They need resources such as tools and access to information. And they need coaching to form as a team.
The pressure cooker method of team formation is more likely to burn people out than result in the productivity of a real team. And calling a group a team doesn’t make it so.
Timeboxing is one of the structures that can help teams succeed; and teams still need attention to the interpersonal skills that enable them to work collaboratively and build trust.
As a manager, you can provide resources and coaching to help people develop the skills they need.
Misconception: Teams grow less productive over time, so they should be shaken up every few months.
Teams need time to develop the social glue that enables high performance. They understand each other's strengths and weaknesses, develop shared knowledge, and discover how to learn together.
When new people are constantly arriving and leaving, a group may never develop the shared approaches and shared knowledge that permit teams to outperform a group of individuals.
Some teams—when they've had time to form and create a strong team culture—do become adept at adding new members. Even then, it's best to limit the number of new members added at any given time. Changing more than 30 percent of team membership causes a reboot of the team. Constant turnover prevents a team from truly forming.
As a manager, you can help by keeping teams together long enough to jell and by protecting teams from the revolving door syndrome. In the end, agile teams require the same coaching and attention as other highly productive teams. And as a manager, you are still needed.
Find out what you missed in past issues of iterations at: www.stickyminds.com/eNewsletters/iterations/Default.aspx?eNewsletter=Archive
|
|
|
| |
|
|
| |
ADVERTISEMENT:
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
|
|
|
| |
|
|
| |
AGILE IN MOTION:
The Reality of Agile Training
Interview with Don Gray |
Consultant Don Gray considers himself an agile archeologist and anthropologist. He uses his knowledge to help organizations and teams transition into agile. In his years of training and consulting, Don has seen the misconceptions Esther Derby writes about above. Below is an interview in which he shares some of his techniques for helping organizations and teams avoid those misconceptions. Learn more about Don Gray and his techniques by visiting his Web site at www.donaldegray.com.
Francesca Matteu: Explain the difference between a "self-organizing" team and a "self-organized" team.
Don Gray: The difference is in the verb tense and reality. "Self-organizing" signifies on-going activity, for example, still doing "inspect and adapt." "Self-organized" indicates the arrival at a destination. Finished, complete. Nothing left to do with respect to this. But what is reality?
In my experience "change is the only constant." What changes for teams? On a daily basis the tasks that need to be completed change. The development environment itself may change (hopefully for the better). Occasionally (hopefully, only occasionally) team membership changes. All of these changes create a new reality the team needs to wrap around and absorb. Organizing how to respond to these changes works best when those closest and most familiar with the details handle the job. Since the team is closest, most familiar, and lives with the results of the organization, it's best for it to do it.
As Russell Ackoff said, "Few problems, once solved, stay that way. Changing conditions tend to unsolve problems that previously have been solved."
FM: What strategies do you employ to help agile teams (or any team for that matter) become more self-organizing?
DG:
0. Start where the team is and have an idea where the team would like to be.
1. Don't do for the team what the team can do for itself. I filled in as a ScrumMaster for a team where the previous ScrumMaster called each person by name during the daily stand up. I thought the team could decide what order to report in, so when I filled in I said "OK, let's get started," and then kept quiet. After a week or so the team members got the idea that I wasn't going to call on them by name, and they started checking in with each other instead of reporting to me.
2. Allow for failure. I talked with a product owner a couple of days before the product demo. As we reviewed the burn-down chart, we saw that the team wouldn't meet the sprint goal and complete the stories it committed to. Rather than abnormally terminate the sprint, we decided to go ahead and let the team work through the problems it encountered and created during the retrospective.
3. Encourage reality. Change takes time and energy; that's why retrospectives have such great value and power. They create a shared understanding of what's happening in the team and what can be changed to achieve better results.
4. Have a common goal and keep the team focused on the goal. Incremental iterative development methods do this naturally.
The role of the agile coach/ScumMaster/facilitator is to modify tactical activities while keeping the overall strategies in place.
FM: What are some agile coach/ScrumMaster practices that facilitate a self-organizing team? What are practices that destroy them?
DG: Some facilitating practices include: helping the team to find answers, helping the team build trust and improve communication, ensuring the burn-down chart stays current, working with the team to assign tasks on a "who is available" and "what needs to be done" basis, and normalizing the experience (change takes time).
Some destroying practices include: always providing answers for the team members, assigning tasks to team members immediately after the planning session, yelling at team members when it looks like they may not complete the sprint backlog, making sure that testing doesn't start until all the code has been completed for the sprint, or skipping the retrospective because the team needs the additional time to start work on the next sprint.
FM: What advice can you give to teams struggling to be more self-organizing?
DG: Strategically: Start where you are and know where you want to go. Hold retrospectives to monitor your progress. Tactically: Make your own decisions and be responsible for your actions. Assign tasks on a "what's next, who's available" basis. Establish group norms for behavior and enforce them. Hold a lunch time study group and read a book of interest.
|
|
|
| |
|
|
| |
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 |
|
|
| |
|
|
|
|
|
|
|