Agile in a Flash 33

How to Be a Team Player – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #33)

> Cooperation: Focus on shared goals

> Information: Feedback loops closed

> Humanity: Respect for struggles of others

> Equality: Recognition of peers

> Energy: Common effort toward common problems

--

Agile teams require close collaboration, but transitioning agile teams often struggle because of poor working relationships among team members. With these five shared values, you will find that you can usually put aside personal issues and past history to work successfully together.

Cooperation. Focus on the work you do together, and try to make the team successful instead of jockeying for position

Information. Look for ways to determine whether the new work system is producing good results. Prepare to give and receive honest feedback. Be increasingly

transparent.

Humanity. Teach and learn. Be humane to teammates by being patient when your strengths are not equal or their circumstances and training differ from

your own.

Equality. Neither a take-credit nor a blame-shoveler be.

Energy. Do not exhaust the people you work with. Keep up. Work hard when working, and then go home after seven to nine hours.

Agile in a Flash 32

When Not Pairing – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #32)

> Build nonproduction code(8)

> Create meaningful and lasting documentation

> Work on spikes for future stories

> Learn a new tool or technique

> Identify production code needing refactoring

> Refactor tests

> Improve existing test coverage

-8. Test frameworks, tools, the build, and so on

--

It’s not always possible to pair, even in shops where pairing is standard practice. Realities such as variant working hours and odd numbers of programmers make full-time pairing difficult. For these reasons alone, it’s probably a bad idea for your team (or worse, someone outside the team) to mandate 100 percent pairing on everything.

Card 30, ABCs of Pair Programming, clearly defines when you must pair: when developing any production code. Refer to the other side of this card for a list of what you might do, other than twiddle your thumbs, when no pair partner is available.

Your team should derive ground rules for work done during pair-less times. Start with this list. Sometimes, unfortunately, you’ll need to change production code, but let that happen only rarely. Your team should derive ground rules for this circumstance. Since the primary goal of pairing is review, some form of follow-up review is the most sensible place to start.

--Opportunities to improve environements

Agile in a Flash 31

Retrospectives – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #31)

> Set the stage: Get everyone to speak. Agree on rules. Use a safety exercise.

> Gather data: Feelings are legitimate data!

> Generate insights: “Why?” Begin discussing how to do things differently.

> Decide what to do: Commit to one to two action items or experiments.

> Close the retrospective: Review the retrospective itself. Capture info. Thank all.

--

Retrospectives are regular team opportunities to reflect on our past performance and then commit to adapt. The retrospective meeting is a great tool for managing continuous improvement, an essential quality of “being agile.” These steps will help keep your meetings running smoothly.

Start a retrospective meeting by using a safety exercise that anonymously determines how comfortable everyone is with speaking openly. Next gather data about what occurred over the last relevant period (usually an iteration or release). Just the facts, ma’am—prevent participants from predetermining solutions. The team can then analyze the facts to uncover the underlying problem they must tackle.

Only then should they discuss solutions and plan a course of action. By meeting end, the team must commit to one or more concrete changes to how they work. These “change stories” require acceptance criteria–specific goals to be met by a certain time. Consider using SMART (Specific-Measurable-Attainable-Relevant-Time bound) goals to vet the quality of a change story.

Accept a change story only if measurements show it meets the acceptance criteria. In other words, track and test it.

Absolutely read Agile Retrospectives [DL06], which includes the meeting structure outlined here and exercises to keep your meetings lively, sane, and useful.

Agile in a Flash 30

ABCs of Pair Programming – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #30)

> All production code

...must be developed by a pair

> Both parties contribute to the solution

...switching roles between “driver” and “navigator” frequently

> Change pairs frequently

...once to three times per day

> Develop at a comfortable workstation

...that accommodates two people side by side

> End pairing when you get tired

Constrain to no more than three-fourths of your workday

--

Pair programming—two programmers jointly developing code(7)—can be an enjoyable practice that results in better-quality solutions. Follow our ABCs of pairing to avoid applying it as a practice that’s neither effective nor fun.

Pairing on production code is a must—it’s a form of review—but you can still work solo on other tasks. See Card 32, When Not Pairing.

Pairing is not one person watching over another programmer’s shoulder. That seems like it would be a waste of time! Pairing instead is “two heads” collaborating on a better solution than either alone would produce.

The least obvious and most abused rule is that pairs should not remain joined at the hip for days at a time or more. That’d just result in more workplace violence! Instead, ensure that at least three people, not just two, contribute to and review a solution. This creates some context switching overhead, but adherence to agile quality practices (particularly TDD and refactoring) will minimize the overhead.

Pairing must be enjoyable and comfortable to be sustainable. Make sure your environment isn’t causing you pain, and don’t overdo it. We advise also keeping refreshing mints or gum on hand.

--

7. Lisa Crispin reminds us that pairing also works well for other efforts, including designing tests.

(Pair programming may or may not fit your team needs)

Agile in a Flash 29

Successful Stand-up Meetings – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #29)

> All team members stand for the duration

> Each team member shares with the team

– What did I accomplish yesterday?

– What will I accomplish today?

– What obstacles do I have?

> Team coordinator notes obstacles (to be cleared before the next stand-up meeting)

> Break into follow-up meetings as needed

--

A stand-up meeting is the first opportunity for the team to get together and begin collaboration for the day. Successful stand-ups are short and to the point and generally follow the rules shown on this card. You actually do stand to help constrain the meetings to five to ten minutes.

Beyond the rules we show here, create your own rules to help keep stand-ups lively but to the point. For example, some teams toss around a token indicating who has the floor. One team we met required newcomers to sing for the group (Jeff sang I Feel Pretty).

Stand-ups are designed for the day-to-day team. It’s important that the team prevent others from derailing the focus of the meeting. Scrum dogmatically requires outsiders to be silent, for example, but you could simply ask offenders to stifle it.

Having tedious stand-ups? Your team is likely avoiding collaborative work. If we each work a story alone, there’s little reason to converse or even listen to one another. You may as well just email a status report and save the time of a standup. Better yet, work as a team and collaborate on delivering a new story every day or so if possible. Your stand-ups will be far more interesting!

Remember that stand-ups are only a starting point for daily team conversation. The meaty dialogue must occur afterward, throughout the day.

Agile in a Flash 28

The Only Agile Tools You’ll Ever Need – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #28)

> White boards, flip charts, and markers

> Pairing and integration stations

> Index cards

> Toys and food

> Stickies and sharpies

--

What, not a single piece of software? If you and your whole team work together in a single room, you don’t need high-end agile project management software.

White boards, flip charts, and markers. Sketch designs and useful notes on the white board to broadcast them to all who enter. You’ll find that very little of this information needs to survive beyond an iteration. Instead of archiving it on a computer, summarize on a flip chart page, and tape it to the wall.

Pairing and integration stations. Developer comfort and a screamin’ machine on which to pair are of utmost importance—with, of course, the best developer environment available to build and test the product.

Index cards. Cards are our ubiquitous idea bulbs. They stack, tack, and sort quite well and are just small enough to prevent us from writing too much down.

Toys and food. Distractions help us relax and focus; snacks keep us energized. Concerned about the cost? Contrast it with a license for a high-end agile tool that you don’t need. There is no requirement for the team to be unhappy.

Stickies and sharpies. Little reminders are quicker and more visible than emails or other software-based solutions. And you can never have enough pens at your disposal.

If you have a good coach, you won’t have to ask for refills for these items.

Agile in a Flash 27

Shu-Ha-Ri – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #27)

> shu Embracing the kata

> ha Diverging from the kata

> ri Discarding the kata

--

Kata are movement patterns practiced by martial arts students and instructors. Shu-ha-ri are the three mastery levels for these movements. Embracing shu-ha-ri can help us understand why agile is much more than a set of simple practices.

shu 
You replicate the instructor’s basic moves as precisely as possible, ingraining them until they are second nature. Wax on, wax off. You follow rigid rules for stand-ups to learn how to quickly communicate daily with your whole team.

ha 
You have some leeway to diverge a bit from strict application. Lightbulbs turn on as you begin to recognize the true usefulness of the skill. You begin to see how important it is to hear in the stand-up meeting what you are doing as a whole team. But you also realize that there’s no reason for the team to wait for the next formal stand-up to quickly share information.

ri 
Rules are not constrictions; they are stepping stones to learning and freedom. You no longer think about rules—you simply apply the ingrained movements and can also specialize them based on prior experience. You may even forego formal stand-ups, for even greater success, if the whole team has

learned to communicate frequently throughout each day.

Rules are meant to be broken but only after you’ve truly experienced them. Having mastered the rules, you are free to ignore them—particularly now that you know and accept the risks of ignoring them!

These take time and must be allowed to develop !

Agile in a Flash 26

Communication-SMITH with Information Radiators– The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #26)

Be Communication-SMITHS with information radiators that are

> Current

> Simple

> Minimal in number

> Influential

> Transient

> Highly visible

> Stark

--

Information radiators, aka big visible charts (BVCs), are wall hangings you design to broadcast important information. In yo’ face! Your team won’t have to proactively seek out their relevant info. (Unhip folks just call ’em posters.)

Current. Stale information is soon ignored. Ensure it’s current, or take it down.

Simple. Dense or complex BVCs fail to communicate. Present information so people can understand and digest it in a few seconds.

Minimal in number. Killing too many trees creates a thick, impenetrable forest on your wall. Also, exposing too many problems at once can be demoralizing.

Influential. Worth while BVCs influence the team (and perhaps managers, customers, or other stakeholders) to improve how they work.

Transient. BVCs that expose problems should be short-lived; otherwise, it’s clear you’re not solving your problems. Highlight challenges for which you can demonstrate progress in a few days or iterations.

Highly visible. Radiating information requires your BVCs to be readable by everyone who enters the team area.

Stark. BVCs don’t exist to convince others of your team’s excellence. Don’t mask problems with them—use BVCs to display progress and expose problems.

Agile in a Flash 25

Iterate with Principle – The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #25)

> Team commits to stories they can complete

> Team works stories from prioritized card wall

> Team minimizes stories in process

> Team collaborates daily

> Customer accepts only completed stories

> Team reflects and commits to improvements

--

Team commits to stories they can complete. Start each iteration with a short planning session to understand the customer’s stories and determine what the team is confident they can deliver.

Team works stories from prioritized card wall. The customer posts prioritized stories; your team selects the highest-priority story and moves it to an in-progress bucket. The card wall, real or virtual, is visible to everyone.

Team minimizes stories in process. Your team works on the smallest sensible number of stories at once, maximizing completion rate so that many stories are truly done well before iteration’s end.

Team collaborates daily. Having few stories in process means you must collaborate frequently throughout the day. A sole stand-up meeting isn’t enough.

Customer accepts only completed stories. Stories must pass all programmer and acceptance tests. Anything less than 100 percent gets your team zero credit; incomplete work provides no business value. Don’t over-commit.

Team reflects and commits to improvements. Iterations are opportunities for incremental change, whether to improve quality, throughput, morale, or any other process and team concerns. Run a retrospective!

Everything else is implementation details, which are up to your team to determine.

Agile in a Flash 24

A Winning Hand for Playing Poker – The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #24)

1. Agree on a short size scale

2. Team briefly discusses a story

3. Everyone silently selects a point card

4. Team reveals all cards in unison

5. If outliers exist, discuss and re-vote

--

James Grenning’s Planning Poker is a fun, consensus-based technique to expedite your story estimation sessions. It requires a short scale of story sizes, such as 1, 2, 3, 5, 8, or XS, S, M, L, XL. The units are not days or hours but purely relative sizes: 1 being tiny, 2 being twice as large. The larger gap between higherpoint values reflects the reality of diminished accuracy for larger estimates. Stories

larger than the scale must be broken into smaller stories.

Each Planning Poker participant brings an estimation deck (perhaps hand-drawn) containing one card for each value in the scale. The customer and team discuss and design a story until all understand and agree on its meaning. Each team member who will help build the story then secretly selects a card representing

their estimate of the story size. All cards are revealed simultaneously. The private selection and reveal prevent otherwise overly influential folks from dominating the estimates!

If everyone agrees precisely, move on. If not, discuss the outliers to find out the rationale behind lower or higher estimates. Timebox the discussions. If you can’t agree upon a final estimate because of insufficient information, have a quick follow-up estimation session after any needed investigation. Otherwise, quickly select the more conservative estimate. Cheers! Move on.

Agile in a Flash 23

Story Estimation Fundamentals – The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #23)

> All contributors estimate

> Break story into tasks to verify scope

> Come to Consensus with Planning Poker

> Decrease granularity as story size increases

> Estimate with relative sizes

--

Estimates are always wrong—it’s just a matter of degree! But dates are important to the business, and agile provides many chances to improve estimates over time.

All contributors estimate. Those who build the software are the only ones who get to say how long they think it will take.

Break story into tasks to verify scope. In agile, design and planning go together. Designing raises many questions that dramatically impact the plan.

Come to Consensus with Planning Poker. This simple technique for deriving consensus on estimates keeps your planning meetings focused, lively, engaging, and on track. See Card 24 (next card), A Winning Hand for Planning Poker.

Decrease estimation granularity as story size increases. Estimation accuracy rapidly diminishes once stories grow beyond a few hours or a day. Don’t deceive yourself by attaching precise estimates to larger stories.

Estimate using relative sizes, not calendar days. Once a bread box, always a bread box—a story’s size doesn’t change over time. Its size relative to other stories is also constant, regardless of developer capability and availability. Remember: all contributors estimate, even in the most mature teams.

Agile in a Flash 22

Acceptance Test Design Principles – The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #22)

Well- designed acceptance tests are

> Abstract

> Bona fide

> Cohesive

> Decoupled

> Expressive

> Free of duplication

> Green--

Acceptance tests (ATs) are as enduring and important an artifact as your code. Their proper design will minimize maintenance efforts.

Abstract A test is readable as a document describing system behavior. Amplify your test’s essential elements, and bury its irrelevant details so that nontechnical staff can understand why it should pass.

Bona fide To ensure continual customer trust, a test must always truly exercise the system in an environment as close to production as possible.

Cohesive A test expresses one goal accomplished by interacting with the system. Don’t prematurely optimize by combining multiple cases into one test.

Decoupled Each test stands on its own, not impacted by or dependent upon results of other tests.

Expressive A test is highly readable as documentation, requiring no research or analysis from its readers. Name it according to the goal it achieves.

Free of duplication Duplication increases risk and cost, particularly when changes to frequently copied behavior ripple through dozens or more tests.

Green Once a story is complete, its associated ATs must always pass. A failing production AT should trigger a stop-the-production-line mentality.

Agile in a Flash 21

Acceptable Acceptance Tests– The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #21)

Acceptance tests are used to verify that the team has built what the customer requested in a story.

> Are defined by the customer

> Define “done done” for stories

> Are automated

> Document uses of the system

> Don’t just cover happy paths

> Do not replace exploratory tests

> Run in a near-production environment

--

Are defined by the customer Acceptance tests (ATs) are an expression of customer need. All parties can contribute, but ultimately, a single customer voice defines their interests as an unambiguous set of tests.

Define “done done” for stories ATs are written before development as a contract for completion. Passing ATs tell programmers their work is done and tell customers that they can accept it.

Are automated You can script, and thus automate, all tests that define expected system capabilities. Manually executed scripts are a form of abuse.

Document uses of the system Design readable tests so they demonstrate, by example, valid uses of the system. Such documentation never becomes stale!

Don’t just cover happy paths It’s hard to capture all alternate and exceptional conditions. Inevitably you’ll miss one. Add it to your AT suite.

Do not replace exploratory tests Exploratory testing highlights the more creative aspects of how a user might choose to interact with a new feature. It also helps teach testers how to improve their test design skills.

Run in a near-production environment ATs execute in an environment that emulates production as closely as possible. They hit a real database and external API calls as much as possible. ATs are slow by definition.

Agile in a Flash 20

Shrink XL Stories to Fit – The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #20)

> Defer alternate paths, edge cases, or error cases

> Defer supporting fields

> Defer side effects

> Stub dependencies

> Split operationally (for example, CRUD)

> Defer nonfunctional aspects

> Verif y against audit trail

> Defer variant data cases

> Inject dummy data

> Ask the customer

--

Deliver completed stories in each iteration. Avoid XL (extra large) stories that “go dark,” requiring many iterations before you can show completed product. Consider splitting off alternate paths, edge cases, or error cases, using acceptance tests to delineate each. (But remember, they must still show business value.)

In many cases, you can split off secondary details: supporting data fields (distill to a few core fields), input validation (assume the input data is perfect), or side effects (worry later about, for example, impacts to downstream feeds). You might similarly defer nonfunctional constraints (such as logging, graceful error handling, performance, or auditing) and variant data cases (for example, have a

shipping system send all packages to the same address).

Here are some other options for putting those XL stories on a diet:

> “Fake it until you make it,” by stubbing dependencies on third-party systems or by injecting dummy data and doing data collection stories later.

> Split along CRUD (Create, Read, Update, Delete) boundaries. You don’t have to build “create” stories first!

> Use audit trails (or logs) to verify progress not visible to the user.

Finally, ask your customer—don’t be surprised if they come up with an even

better idea for breaking down your bloated stories!

Agile In a Flash 19

Sail on the Three C’s – The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #19)

> Card

> Conversation

> Confirmation

--

Cards are superb for story derivation and planning, but focus on the dialogue they create—not so much on their format or wording. Sail to success on Ron Jeffries’ three C’s (see http://xprogramming.com/articles/expcardconversationconfirmation).

Card Story cards are little physical things with purposefully insufficient space for every detail about what should be built. They are promises for subsequent communication that must occur. Ron says cards are tokens; the card isn’t the real thing—it’s a placeholder for the real thing.

Conversation So, what is the real thing? Collaborating to build and deliver software that meets customer needs! To succeed, you must converse continually. You must continue to negotiate supporting specifics for a story until all parties are in agreement and the software is delivered.

Confirmation A story’s specifics must ultimately be clear to the customer and your team. The customer uses acceptance tests (ATs) to define this criteria. These ATs exercise the system to demonstrate that the implemented story really works. When all ATs for a story pass, the customer knows that the story is truly done—the software does what they asked.

Think of stories in a more ephemeral sense. Once you build the customer’s need (represented by the story) in code, the story has been heard. Only the working feature and the tests that document how it behaves remain. Rip up that card!

Agile in a Flash 18

Categorize Requirements with FURPS – The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #18)

> Functionality

> Usability

> Reliability

> Performance

> Supportability

--

As you mature in agile (see Card 27, Shu-Ha-Ri), consider ideas outside its realm, such as HP’s FURPS (http://en.wikipedia.org/wiki/FURPS) requirements categorization scheme.

Stories technically are not requirements; they are informal expressions of customer need. You can still categorize such needs using FURPS. Most significantly, FURPS reminds you that stories can represent more than just the immediate goals a user wants to accomplish by interacting with the system—the functionality.

More than with Functionality stories, you must vet -URPS (excuse us!) candidates against INVEST characteristics of a good story (see Card 17, INVEST in Your Stories). For example, it’s hard to define acceptance criteria for usability, but otherwise you have no idea when the story is done.

Functionality User features your customer wants, of course!

Usability Product effectiveness, aesthetics, documentation, and so on.

Reliability Failover, downtime, recovery, system accuracy, and so on.

Performance Max response time, throughput, memory consumption, and so on.

Supportability Testability, serviceability, monitorability, extensibility, and so on.

Car Talk Puzzler - Mind Gym for the Team

I am a fan of the NPR show Car Talk and they have a weekly puzzler for listeners to solve.  I found this to be a great "Mind Gym" exercise for solving issues that have many combinations.

For the last couple of weeks, they have had a great puzzler that I almost solved but is worthy of engineers to attempt and to consider.  Linked below is the text of the puzzle

http://www.cartalk.com/content/prison-switcharoo-0?question

You can figure if you would solve the issue and send your friend to freedom or to be fed to the alligators.

In programming, we find our proposed solutions focusing upon numbers and information that become, or are, irrelevant to the actual solution.  As the Car Talk host suggested, a group of students were fixed upon the number 23 as being prime.  Yet, the number 23 only diverts attention from the solution. This mind gym exercise can help us to examine how we look at other problems in the workplace (i.e. is our focus correct, are we over-analyzing the facts, and what is truly the objective of our projects.) Remember, the objective here is not to be fed to the alligators.  

We, as programmers, could go one step further and ask how to program a calculation that solves this in your favorite language.

**The hint to figure your base case and to solve for 3 prisoners can help a bunch.

Agile in a Flash 17 - INVEST in your stories – The Plan

INVEST in your stories – The Plan

Agile in a Flash by Jeff Langr and Tim Ottinger (card #17)

> Independent

> Negotiable

> Valuable

> Estimable

> Small

> Testable

--

Customers describe their needs as briefly stated stories, best captured in a few words on index cards. Vet these candidate stories against Bill Wake’ s INVEST mnemonic (see http://xp123.com/xplor/xp0308). Fix them if they’re not up to snuff.

Independent Your customer wants cool features now, not boring data inputscreens. Can you deliver? Yes! Each story is an independent, incremental need. You don’t need the “add” story yet. Life isn’t neat and orderly.

Negotiable A story is not a contract! It’s a promise for more communication. Don’t fill your story cards with every last detail.

Valuable Stories represent small bits of business value for your customer. Each implemented bit lets them see what you can deliver and provide feedback. Stories promising implementation of technical details (such as “build a database layer”) provide no visible business value—never create them!

Estimable A reasonable estimate might not exist if a story is too big or if you don’t know what’s involved. Go back to the drawing board.

Small Stories are small, many fitting into an iteration and none approaching the full iteration’s length. An ideal story would take your team a day to deliver.

Testable If you can’t verify a story in some manner, you’ll never know when it’s done! Tests are often the best way to flesh out your understanding of a story.

Google Java Standards

Just got this web site with the Google Java Standards.

http://google-styleguide.googlecode.com/svn/trunk/javaguide.html

Useful points:

• Files are all in UTF-8
• Braces always used: void method() {}
• One statement per line: how many times have you seen someone a gigantic boolean condition all on one line?
• Enums formatted as if an array (no methods or docs)
• Testing caught exceptions can be ignored if, and named, "expected"

We can find issues with files not formatted correctly, especially when using a tool like Camel and Bean IO to convert files to Java objects.  Using the base UTF encoding, we keep characters that can hurt the code from causing issues.

Braces are important for visually defining connected elements of the code and for asserting logic.  It may be a couple key strokes  less to exclude them, but someone working on that code may incorrectly change the logic and behavior of the code because they did not see the connected operations.

One statement per line helps readability, debugging and can help to deter code smell.

return (x == y && x== z || x== a || x ==b )

Remember here that java works with order of operations as top to bottom.  A debugger will just error on the one line if there is an error, and as well, a Boolean condition that is nested in the line may make determining the overall outcome difficult.  By breaking the conditions into individual comparisons, the debugger can reveal if the logic is accurate and which statement is causing the logic to be true or false.  This might better, even more, refactored into other methods were the Boolean logic is more concise to one comparison rather than as a chain.

(x == y

&& x== z

|| x== a

|| x ==b)

Testing that causes exceptions should name the exception as "expected" helps testers understand what the test is trying to accomplish or asserting. Something is being thrown in order to prove that incorrect parameters or other bad condition is being attempted.

@Test(expected = Exception.class)

methodThatCausesException(){ //operation that causes exception}