|
Two of my favorites quotes from the book use the metaphor of digging holes in the ground.
The first is from Steve McConnell, one of my favorite software writers, who talked about establishing an elevating goal for a project:
"If you're out digging ditches, that's not very elevating or inspiring.
But if you're digging ditches to protect your town that's about to be attacked by an enemy, well, that's more inspiring, even though it's the same activity.
And so the leader's job, really, is to try to determine or frame the activity in such a way that people can understand what the value is." |
|
The second is from Scott Ambler, whose books and articles on software process have consistently helped me steer my projects over the years:
"You can't always tell when a team is dysfunctional. If there's negative shouting and screaming, that's a problem. But sometimes, you can be on a
team where everyone's trying, but nobody's communicating, and nobody's reaching their goals. The easy analogy is that during the day you've got people
digging a hole, and at night other people are filling it up. Everybody's working really hard digging and filling holes,
but in the end nothing of value is actually occurring." |
I like these quotes in particular because they're not necessarily about software development but speak to some basic truths of working with teams.
» View Andrew & Jenny's Presentation
» Read Andrew & Jenny's Beautiful Teams
|
Transitioning to Agile: Solving Problems of Transition (Roundtable) |
Management-Mandated Multitasking: A Common Pitfall of Transitioning to Agile
by Johanna Rothman
The team is working in time boxed iterations, delivering working releasable product at the end of each one. Sometime around iteration 9 or 10,
when the team has hit its stride, management says,
"Hey, Agile Team. We need you to do your magic on this other project over here."
The team says, "Sure, at the end of this iteration."
"No. We want you to work on both projects at once."
What do you do?
Never Say Yes
Saying Yes is a guarantee that you will fail. Instead, consider these strategies:
|  |
Shorten the iterations. It's possible management needs to make decisions sooner than your iteration's length.
If you're using four-week iterations, reduce them to two weeks. Then, management only has to commit to something for two weeks at a time.
Manage support work differently. If you have support work (which often cannot wait), maybe you need a support team with rotating membership.
Each iteration, remove people from the creating-product team, and have them do support. You change who those people are each iteration to share the support load evenly.
Integrate support into the backlog. Maybe you don't need an entire support team, but you have some support issues that arise every so often.
As part of your backlog, add a few cards for "unknown support work" and give them story points, so you have reserve time for support.
Consider breaking your team in
two to work two projects "at one time." If you have a larger team, say 8 or 9 people, break them into two smaller teams, one assigned to each project.
You could also insist management start managing their project portfolio. But that's fodder for another article!
Whatever you do, don't just blindly accept more simultaneous work or projects. That's not a recipe for success.
» Read more of Johanna's articles on her Managing Product Development blog
|
In Agile, Where Does Developer Testing End and Tester Testing Begin? (Roundtable) |
Where Does Developer Testing End and Tester Testing Begin?
by Abby Fichtner
& Nate Oster
If Programmers are testing their code, what are Testers doing? How is there time for testing in a 2-week iteration?
These questions all assume some big hand-off from the programmers to the testers. But in agile, we all work together towards the same goal,
rather than handing off from one group to the next. Here are some ways testers and developers can work together to build quality into our software:
Drive Development from Acceptance Tests. Have testers work with the product owner to define acceptance criteria for each story before coding starts.
Have them define tests that must pass for a story to be "done."
Pair a Programmer & Tester on Each Story.
Testers create an objective definition of "done" by defining tests that must pass.
Programmers code functionality and help automate tests. Testers do exploratory testing and refine test scenarios with the programmer, allowing programmers to
fix issues in real-time to gain immediate feedback.
Hold Everyone Accountable for Quality. Hold programmers responsible for internal quality through clean code backed by automated unit tests.
Hold customers responsible for defining their conditions of satisfaction.
Have testers help customers articulate quality needs and work with programmers to ensure all quality needs are met.
Build a Safety Net with Automated Tests. Use automated tests to validate the software several times per day to enable the team to proceed with
confidence as they evolve the system.
Adopt a Stop the Line Mentality. Continually inspect and adapt to ensure problems are caught and fixed immediately, before any further work is able
to build upon them.
Demo Production-Quality Software to Customer at end of each Sprint. Frequently check in with the customer to ensure the software is fit for purpose and
that the team is moving in the right direction.
» Join Abby & Nate for their workshop on this topic at Agile 2009
|
Modern Approaches to Infrastructure: On Premises or In the Clouds (Presentation) |
Infrastructure for Agile: Reaching for the Clouds
by Mario Moreira
 |
Given that when applying Agile, you start coding almost immediately, how do you get the infrastructure set up quickly?
Some projects use an Iteration zero for infrastructure tasks, but even then, the time and effort required to establish your infrastructure can
far exceed the time it takes to start development on an agile project.
The good news is that today there is a new option available to companies that don't want to spend considerable time and large amounts of capital
to establish and host their infrastructure locally. This new option is renting "Infrastructure in the Clouds."
The infrastructure game has been changed.
|
Renting infrastructure in the clouds is a more recent concept and option where organizations are utilizing infrastructure (servers, software, etc.)
in the internet cloud. This service is sometimes known as cloud computing but has a variety of other names each with different focuses including
software as a service, application service provider model, platform as a service, and application infrastructure provider.
A distinct advantage for Agile teams is that the cloud infrastructure approach enables users to use only what they need, something
directly in line with lean thinking. This "use what you need" approach minimizes infrastructure debt and allows the product team to scale
to their need in a just-in-time manner. An additional advantage is that it helps minimize upfront capital expenses since you don't have to
buy hardware, software, and other components. Effectively the infrastructure (e.g., servers, software, etc.) becomes more of an operating
cost (pay per use approach).
This may be just the solution needed for those companies envisioning the next wave of innovative products so they can focus less on the
infrastructure and more on taking their ideas to the next level!
» View Mario's Presentation
» Learn more about infrastructure options in Agile Journal: Infrastructure - on Premises or in the Clouds
Running Effective Daily Standups
by Dan LeFebvre
Almost all agile methods include a practice called the Daily Standup Meeting. However, there seems to be much confusion about the
purpose and usefulness of these meetings. Many people believe the daily standup is a status meeting for the ScrumMaster.
Others feel it's an unwelcome interruption to the flow of their work.
The real purpose of the daily standup is for the self-organizing team to check in with each other to make adjustments
as needed to meet their iteration's commitment. Here are some tips for running effective daily standups:
- Limit the time to fifteen minutes.
- Pick a regular time to meet, preferably in the morning, and start on time, regardless of who is absent.
- Have each person answers these three questions:
a) What have you accomplished since the last meeting?
b) What are you working on next?
c) What is slowing you down?
- Sometimes ask a 4th question "On a scale of 1 to 10, what is your confidence that the team will meet the sprint commitment?" Discuss all answers ranked below 8.
- Hold it at the task board or with the electronic board open.
- Promote self-organization by having the team lead the meeting.
SM should stand in the back, not at the task board, while team members update the sprint burn down.
- Encourage people to add tasks to the board when new things come up.
This makes the task board (sprint backlog) the official record of the sprint.
- Keep an impediments list on the wall. And use it.
- Use a talking stick or marker if there are many interruptions during the meeting.
- Defer all discussion and problem solving until after the meeting and follow-up as needed in smaller groups.
Connect To Your Audience
by Claudyne Wilder
Everyone wants to keep the audience engaged while looking and sounding confident and in charge of the information.
Here are some specific ideas on how to do that, courtesy of Claudyne Wilder, author of
Point,
Click & Wow! The Techniques and Habits of Successful Presenters:
|
Channel Your Nervousness |
» Practice out loud -- do a real rehearsal
» Make sure presentation is the right length
» Really look at your audience & see their interest
» Breathe and relax as you talk
|
|
|
Motivate Your Listeners |
» First two minutes, connect to your audience
» Change the pace with your voice, gestures, slides
» Tell stories that relate to audience's interests
» Dress the role
|
|
|
Manage Questions |
» Tell people when to ask questions
» Repeat the question if audience could not hear it
» "Briefly" answer the question
» Answer the question to the whole room
|
|
|
Conclude With Conviction |
» Rehearse your ending
» Keep a confident voice
» Have an energetic stance
» Conserve your energy so energetic at the close
|
|
» View Claudyne's Presentation
» Learn more and sign up for monthly Presentation Points at Wilder Presentations
| |