I’ve known Chris McMahon through the Internets for a number of years, but only met him in person at Agile 2009. His talk was immediately after mine and seemed to be one of only a few purely experiential sessions: this is what the situation was, this is what we did and this is what we learned in the process. I like this session a lot more than pure workshop ones, though I’m beginning to see their value too. So even though I know a bit of inside-baseball into the Socialtext automation rig, I still got over two pages of notes. Not to mention the paper that he mentioned exists somewhere that I’m sure he’ll add a link to in the comments. (Won’t ya, Chris…)

• Manual test cases looked the same-ish as their automated counterparts
• Tests were named after features
• Manual tests were note there for regression purposes, but as placeholders for future automation
• Poverty of Oracle problem – automation reports only one problem
• Tip – Break out of the frame to increase testability
• Once the manual test is automated, throw out the manual one
• There is a need for both canned data and data created through the tests. Canned data is for when you have a large required data set for a test
• Lewis Carol poems make great (string) seed data (especially for search)
• If you are creating data, make sure to make it unique through something like Julian timestamps
• Weave a ‘web’ of tests through your application
• 90/9/1 Rule – 90% of people read content, 9% comment on it, 1% create new content
• Smell – All automated tests share the same initial path through the system (a branching strategy)
• Smell – At a certain number of steps (~200 in Socialtext’s case) the script is too large to (easily) diagnose script failure causes and needs to be refactored
• Ran scripts end-to-end, continuously
• If a script fails, run it again immediately and only on second failure mark it as failed. (But don’t lose the fact that you ran it the second time)
• Scripts can have manual prompts in them for human inspection points. Speeds up screen traversal and environment handling
• Four points for efficient, long-term automation
  1. Ability to abstract into fixtures / dsl
  2. Strive for feature coverage
  3. Build a web of tests
  4. Have fast, routine reporting of failures
• The only reason to automate is to give expert testers time to manually test

On yesterday’s Blue Jays post-game they were talking about the role of coaches. Most callers seem to want blame the coaches for lack of player performance, but in reality, the players are the ones who are ultimately responsible for their performance on the field. That view is championed by the host of the show who described the role of a coach at the major leagues as a facilitator of work.

Having been immersed in Agile for a week, this seems to ring similar to the role of a scrum master.

The scrum master removes roadblock and impediments and lets people do their job. (Really, that is all.) In other words, they facilitate work. This also means that the success of the team is completely dependent on the teams. Not the scrum master. The only time the scrum master can be held to task for the failure of a team is if they leave a roadblock in place they could have removed.

The Cult of the Coach exists in baseball. I suspect that the Cult of the Scrum Master also exists. But, if the scrum master is there just to facilitate work, then it is completely misplaced. In high functioning agile teams, the scrum master should be largely invisible working, if not behind the scenes then beside them, to grease the system to allow their team to operate.

So we can now add facilitator of work to the ways we can describe the role of scrum master to our existing circus ring master analogy.

I was surprised that Arin Sime’s talk on getting traditional clients to work in an Agile manner didn’t absolutely pack the room. A client doesn’t have to be external; it could be internal as well. But maybe most people who were at Agile 2009 were already in teams that had made the jump from traditional processes.

The talk itself was really well done. It shows that he has done variations of the talk already and included a slick hand-out which had all his main points on it. (And a list of this company’s upcoming speaking gigs which actually added to the layout.) I also really liked that he based his content on the results of a survey he conducted, not just on hunches and his own experience which added a layer of credibility.

The meat of his talk was 12 strategies for to use to convince organizations to adopt Agile on projects you are bidding for.

1. Trial by Sprint
2. Case Studies of Success
3. Client/Customer Testimonials
4. Find a champion in Key Stakeholders
5. Use metrics of success
6. Show how Agile combats common IT project failures
7. Examples of industry/government leaders using Agile
8. Compare to other methodologies
9. Listen to their needs and address them
10. Sneak it in
11. Compromise
12. Agile Project Management Office

On the testing front, the big theme at Agile 2009 seemed to be ATDD, or more specifically ATDD using the Robot Framework. Pekka Klärck (the creator of the Robot Framework) and Elisabeth Hendrickson (from whom I first heard of ATDD) did a great demo(y) session which did a better job of explaining both of things than watching screencasts or reading articles could do.

• Structure the requirements conversation so the outcome is a set of concrete acceptance tests
• A key characteristic of agile developers is confidence (we have the tests to prove it does what was wanted)
• Defining the product backlog results in shared understanding and a set of concrete, automatable tests
• Implement the ATDD tests at the same time as the production code (which itself is written in a TDD manner)
• Express tests in a natural language
• ATDD tools separate the driver of the interface from the expressions of intent
• Elisabeth types really well.
• Don’t capture “I don’t care” feelings from product owners in acceptance tests. They are not requirements. If they were, they would care.
• There are business facing expectations which need to be discussed. And there is all the other stuff around it that doesn’t.
• It is possible to have duplication of tests between the ATDD suite and the unit testing suite as they operate with different expectations and assumptions.
• 3 Pillars
  • Automated unit tests
  • Automated acceptance tests
  • Exploratory testing built into the process
• Whiteboards and flipcharts are more productive for capturing requirements than any other product currently available.
• The Julia Child method of coding – have the code already written and just uncomment it
• ATDD emphasizes the interactions between people

Edit – It seems I got Pekka and his Robot Framework confused with Aslak and Cucumber. My sincere apologies; I’m still not back at 100% brain functionality and the ATDD tools are still just a big blob of ‘new toy’ in my brain.

Here is the summary of Mitch Lacey‘s Agile 2009 talk:

A high-performing agile team is tight knit. They have worked hard to become a cohesive unit and have developed a bond. This chemistry can be thrown off balance when someone is added to the team in the middle of a project. It does not matter how flexible, capable, or agile savvy the new team member is. If they have not been involved in the care and nurturing of the team’s culture and is not invested in the same way that the other team members are. When the new team member is not flexible, capable or agile savvy, the effect can be devastating.

I paid more attention to the double use of ‘culture’ in the subject and went. Culture is at the heart of any process, Agile or otherwise. Here are my notes, and here are Mitch’s slides.

• This only ship criteria that should matter: Are you proud of this?. If the answer is ‘no’, don’t ship it.
• Bruce Tuckman’s group development model: forming, storming, norming, performing
• ‘I was doing everything under my perceived control’ – there is often a gap between perception and reality. That gap can be a double-edge sword though.
• Role of a Scrum Master is to build team to high performing and maintain it
• Did you solve the problem? Well, depends on the context you are analyzing from
• What he called Robert Merton’s Strain theory seems to be his Theory of Deviance
  • Societies provide both culturally-valued goals and culturally-valued means to achieve them
  • Strain happens when when the two differ
  • Conformity is the attaining of societal goals by socially accepted means
  • Ritualism is the acceptance of the means but the forfeit of the goals
  • Retreatism is the rejection of both the means and the goals
  • Rebellion is a combination of rejection of societal goals and means and a substitution of other goals and means
  • Innovation is the attaining of goals in unaccepted ways

  Now think in terms of company culture rather than societal culture.

• Do you really know your company’s goals? The real ones, not just the ones on the corporate website.
• Without knowing the goals, you are just walking around saying ‘why’
• If you are doing that, are you doing the best job possible?
• Interesting metric: time from bug open to bug close
• Innovators evolve into Rebels
• The movement to Rebellion often result in / because of new (team level) goals
• Need to somehow bridge the gap between the group and the deviant. From both directions.
• Where you are in the Deviance Typology is context sensitive. Might be Rebellion to the organization, but Conformity to the group.
• As a change agent you control only two things: yourself and your environment
• How to measure the maturity of your development process: Will you release code into production Friday afternoon at 5? If not, then you need to be fixing stuff.
• To identify social deviants
  • Understand your company culture
  • Understand the team goals and means. And the alignment of the two.
  • Know the reward structure
  • Be open minded
  • As the team; people who who the bad eggs are. Trust them.
• Success criteria
  • High quality product
  • Customer feedback
  • Team health
• Don’t ask a question if you are not willing / can’t take action
• Social contracts can’t be unbroken

I’m going through my bag which has lots of Agile2009 notes, but found this article from Business Week in the process. It seems apt after spending a week with people that associated themselves often as ‘developers’ or ‘testers’ and only a few ‘member of the development team (commonly known as the developer-tester)’.

• Corporate America has had too much of fancy leadership disconnected from plain old management.
• It became fashionable some years ago to separate “leaders” from “managers”— you know, distinguishing those who “do the right things” from those who “do things right.”
• U.S. businesses now have too many leaders who are detached from the messy process of managing.
• You’re a manager with serious, informed doubts about a strategy, but the leadership is too removed from the fray to hear you. (Sound (too) familiar to anyone?)
• Studies show that vital information is typically transmitted to a CEO informally—orally, often, rather than in formal reports. Leaders removed from managing aren’t going to get these messages.
• Detached leaders tend to be more concerned with impressing outsiders than managing within.
• A robust company is not a collection of leftover “human resources.” It’s a community of engaged human beings.
• Being an engaged leader means you must be reflective while staying in the fray—the hectic, fragmented, never-ending world of managing.
• Instead of distinguishing leaders from managers, we should encourage all managers to be leaders. And we should define “leadership” as management practiced well.

Or where are you on this spectrum? Manager? Leader? Or a Manager/Leader?

While I certainly wouldn’t call myself and Agile Coach, I certainly play the role of (more) Agile (ish) Advocate. And as such, I suspect I am going to have Coach-like issues to contend with. The warning signs (temptations) That Stevie Borne discussed in her session 10 Temptations of an Agile Coach (new or experienced) will then (hopefully) come in handy.

1. Meddling – To interfere with team’s activities when you shouldn’t. Doing so takes away from the team’s ownership of the process. Instead, let them experiment and learn from their mistakes.
2. Impatience – Remember, change takes time
3. Mastery – When you have all the answers so you freely give them, then the team doesn’t learn to rely on themselves, the process becomes ‘yours’ not ‘theirs’ and they begin to be afraid to fail. Instead of spoonfeeding the one true solution, share with them a number of possible solutions and let them choose which one they act on. Can also ask the team how they would solve the problem.
4. Changeful – Changing things all the time; often just for the sake of change. If you change too often, you can’t tell if something is working or not. Keep a change in place for at least two iterations. Change too much and the team focus can slide from the ‘why’ into ‘how’.
5. Inflexibility – The opposite of changeful and can be in terms of uniformity or dogmatism. This leads to teams losing sight of the value behind practices. As a coach you need to learn new techniques that still reinforce the principles. Somethings though, like timeboxes, you need to hold fast on; but you better be able to explain why when challenged.
6. Control – When you start speaking for the team, you remove their empowerment. And that is rather central to Agile
7. Utopia – The belief that Agile will solve all your problems and is the only way to work is a myth. It sets up the belief that either the team is failing Agile, or it is failing them. When Coaches believe this then it sets them up for catastrophe when problems arrive. And they will.
8. Love – Wanting everyone to love you will eventually cause people to hold back honest feedback in an effort not to hurt your feelings. You also can’t effectively play the ‘bad cop’ as they are typically un-loved
9. Fuzziness – Problems talked about in vague terms with no path to resolutions increases the frustration around those problems. Use the 5 Whys technique to find the real problem, name it, and then solve it.
10. Avoidance – Avoiding failure or conflict causes both the team and the coach to miss growth opportunities. Remember, some failure is ok. Likely necessary actually.

Giving and Receiving Effective Feedback by Elizabeth Keogh was probably the top session for me today. Effectiveness, growth and indeed agility all rely on good, timely feedback. This session was used examples of good and bad feedback to showcase what to, and perhaps more importantly, what not to do.

• When we solicit feedback, it is usually from people we like (and in turn like us back)
• When you ask whether feedback is good or not, ask ‘for whom?’
• There are two purposes behind feedback: strengthen confidence and increase effectiveness
• Those purposes are what you should measure effectiveness of feedback with
• Three types of praise:
  • Porpoise – positive reward of desired activity
  • Sandwich – good / bad / good
  • Atkins – Sandwich minus the bread
• The mood in the room seemed to indicate support for sandwich, but see Esther’s Praise Sandwich Tastes Icky, II as the counter argument.
• It is possible to change behavior based on feedback
• If you are getting nothing but positive feedback, you could be in the wrong role as you have nothing to further learn or improve on
• Give feedback to people directly
• Face-to-face is safer (than email)
• Anonymous isn’t as effective (though I know the kids at Rypple disagree.)
• Feedback should be given with the goal of helping the receiver
• Feedback should be timely
• The rapport of the two parties will determine the wording of the feedback
• When management is asking for feedback from minions, ‘help me to…’ is a useful template
• One-on-one problems are rarely one-on-one problems. They are usually a problem stemming from a behavioral problem of one side of the problem.
• Admitting fault in public can raise the comfort level of the team and allow for more honest feedback
• Ask for pointed feedback rather than broad, fuzzy feedback
• Her big list of things to do when providing feedback
  • Anchor the things you value
  • Provide examples
  • Talk about the things you see, hear, etc.. People can argue you observation, but they can’t argue that you observed it
  • Talk about the impact on you
  • Ask for help
  • Make suggestions
  • End with the bright future
  • Provide feedback quickly
  • Provide feedback safely
  • Provide feedback directly to the person concerned

Neal Ford is one of the more well-known ThoughtWorkers and was the consultant I was paired with for a 1-on-1 this morning. The focus of the conversation was In an organization which has a top-down, command-and-control structure (owner), how do you adapt Agile practices since they are who needs to change the most?. Lots of useful stuff.

• What is their perceptions of what is good about the existing process? The new process will only succeed if those perceptions are still met.
• The notion that far off stuff changes, needs to be accepted. This prevents long, waterfall-ish planning.
• Done is a myth. What they get is a subscription to development and change.
• Dr. Laurie Williams has published a number of articles/studies on the efficiency improvements of Agile.
• Does a bowling ball fall faster than a golf ball? The answer seems non-logical. A lot of Agile is like that too. Such as the benefits of TDD and pair-programming.
• If people are analytical or scientific, then phrase arguments and proofs to that strength.
• Scrum provides project management practice improvements and XP provides the software engineering ones. Need both for true success.
• Mockrunner is a lightweight [mocking] framework for unit testing applications in the J2EE environment
• Unitils provides general assertion utilities, support for database testing, support for testing with mock objects and offers integration with Spring, Hibernate and the Java Persistence API (JPA)
• ThoughtWorks has a separate build on some SOA projects to just check the WSDLs of the components they depend on.
• First step is to formalize iterations. And make them super fine grain; one week.
• Start using proper story metrics
• Discipline in planning and execution allows you to do so statistical analysis of projects over time
• Demonstration trumps argument
• Pick one metric to focus on at a time.
• One ThoughtWorks project has a graph of cyclomatic dependency that shows it spikes given schedule pressure
• I need to run my TODO/FIXME script more often…
• Noone tells a bridge engineer to cut corners and skip demonstrated good practices when designing a bridget. Yet, we do it all the time in software.
• There is no credit limit on the technical debt account.

Today’s Baseball Today show (which I don’t have to miss due to the joys of podcasting) had 3 segments, and provided three different quotes that stuck out.

The first was in reference to a pitcher that is having some control issues with his pitches:

The wrong pitch thrown with conviction is always better than the right pitch thrown half heartedly.

Commit. And then do your best. You are going to get knocked around some days (iterations), but don’t just shrug your shoulders and ‘sorta’ do something.

The next one was in the context of a player who has had a couple injuries and has in the past played through them.

The role of the Manager and medical staff is to protect the player from himself.

Now, switch a couple words, primarily Manager with Scrum Master (or perhaps even better Coach) and player with team. Suddenly it directly relates to software development.

The last quote was from an interview between an Uncle who is a pitching coach with the Angels, and his nephew who is a reliever for the Jays. Says the Uncle:

The difference between AAA and the Big Leagues is being consistency.

Now lets play the word switcheroo game again. Agile for AAA and High Functioning Agile for Big Leagues. One thing I have heard repeatedly the last little bit is that Agile is all about discipline and consistency. Without that you lose the advantage of comparing between iterations for things like velocity and accuracy of estimations.