Quick Agile Links Week #3

November 30, 2009 in Agile, Links, Science by Mark Levison

This week I’m leading off with a pair of items on the brain and recovering from challenging cognitive tasks: Cognitive Recovery Time and A Dream Interpretation: Tuneups for the Brain (NY Times, login required). The first suggests that your brain needs time to recover after doing something challenging. The second reinforces the importance of sleep and dreams in integrating ideas and information. What does this mean for TEDx attendees next week? I’m not sure except that we presenters will have to work hard to make our ideas stick. I also think it’s a bad sign for the typical two-three day Agile training course.

Joe Little shares his: Agile Principles—examples: all WIP is bad; bad news doesn’t get better with age. You learn the fastest by small mistakes.

Ilja Preuss says something that’s been on my mind for a while: Index Cards are Tools, too!

Johanna Rothmann tells “How Not to Win Friends and Influence People”, and I’m only disappointed that she didn’t name names.

Finally Abby Fichtner reminds us: Agile Leadership: Methodology Ain’t Enough

0 Comments

Read More

I’m Speaking at TEDx Ottawa

in Science by Mark Levison

6a00d8341cc2cf53ef0120a6a18bf8970c-pi[1]

It’s just been announced that I’m speaking at TEDx Ottawa (a mini TED—ideas worth spreading) next weekend on my favourite topic: “Learning Best Approaches for Your Brain.” I’m pretty good company sharing the stage with the founder of Bridgehead, a man who has run across the Sahara and many more great speakers besides. I would invite you to rush out and buy a ticket, but attendance is limited to 100 people, and the tickets sold out a long time ago. On the upside, the entire event will be recorded and available online, so you will be able to see all the talks at a later date. Now I’m off to shrink my presentation from its original 90 minutes to the 15 that TED requires.

4 Comments

Read More

Why use an Agile Coach?

November 23, 2009 in Agile by Mark Levison

metal Whistle

Occasionally, I’m asked why should you use an Agile Coach. I’ve read a book or taken a CSM course. It seems pretty easy. So why would I want to hire a coach?

With a single team you can bootstrap without too much trouble. Even then a good coach will still help you navigate the adoption process.

So why use a coach?

  • You want to get going faster
  • You want to avoid the mistakes that most people make when they start (Scrummerfall, Command and Control Management)
  • You’ve started and don’t know how to deal with the organizational impediments that Agile has revealed
  • You want to scale
  • You want to recover an “Agile Attempt” that went off the rails
  • You want to recover a traditional project that is late and over budget
  • You’re struggling to Agile in a hostile environment
  • …

The reasons vary with each client, but in my mind, it’s simply that Agile may be easy to describe, but it’s hard to do.

Update: Don Grey and Esther Derby have already written on this topic. Great minds think alike.

3 Comments

Read More

Quick Agile Links #2

in Agile, Links by Mark Levison

Following from last week, I’m doing a weekly series of posts on interesting Agile Links I’ve seen in the past week.

Steven “Doc” List, has a pair of posts on blame: A Culture of Blame and With Blame Goes Guilt—a healthy reminder about where we should place our focus.

Mike Dwyer: Lessons Learned with Distributed Scrums—his experience mirrors my own working with a distributed/dispersed Agile team. Distributed is still painful, but tools like this go a little way to minimizing the pain.

0 Comments

Read More

Tool Vendors Reply to My Agile Challenge

November 19, 2009 in Agile, Tools by Mark Levison

imageLast week I challenged Agile Tool Vendors, and the post got a little bit of attention. I received replies from Rally: How Agile is Rally?, Danube: How Agile is Danube?, and MicroTool: How We Use Agile to Develop Our Tools?.

In addition there were several comments with replies: Robert Dempsey:

CEO and Founder of Atlantic Dominion Solutions. We developed Scrum’d: http://www.scrumd.com. A great post and an excellent challenge. To answer your questions:

# Your Definition of Done

We define done for each user story. Acceptance criteria includes the behavior a user can expect from the app when using it, the workflow for the feature, that it needs to be tested (and how it will be tested), any validations that occur, and if there is documentation for the feature that it is updated.

# Whether you use TDD? Or at least Unit Testing?

We do full TDD for all our stories. We didn’t start out that way, but now that we have a full test suite, we keep it that way. Also, if a bug is found, then a test needs to be written for that and the code fixed.

# What do you do for Acceptance Testing?

We have staging servers set up for internal testing. We also have a few select customers that we let into our staging servers, and I show (in person) some of our current and potential clients the features to get their feedback as well. In addition, we use Get Satisfaction for our support site and ask that commentators who suggested features that we implement to check out the release and see if it’s what they wanted.

# How often do you release?

This depends. We try to do monthly releases. Sometimes it’s longer, but typically it’s less. The release schedule really depends on the importance of features to our user community.

# What did you learn in your last retrospective?

You don’t always get it right the first time, but anything you do release needs to work correctly. Also, continuous integration is a huge help as your product gets bigger, and of course, testing is an absolute necessity. We would rather delay a release to ensure quality than release stuff that won’t work.

Marcin Niebudek (creator of TinyPM)

I like challenges, so…

Our DoD for stories:

  • code meeting minimal requirements committed
  • unit tests passing
  • feature is working under FF, Chrome, and Opera
  • feature is working without any significant failures under IE
  • feature is tested and accepted by at least one team member that was not implementing the story

Our DoD for release:

  • WAR and .exe distros built successfully
  • all unit test passing
  • all functional bugs fixed
  • all UI bugs fixed or small UI bugs (mostly for IE) at least scheduled to be fixed
  • installation and upgrade documentation updated
  • installation tested on Windows and Linux
  • new features list updates at product web site

Do we use TDD? Well, I would not say that because our coverage is not 100%, which means some of our code is not unit tested (glue code), but, yes, we do unit testing with "test first" style for all domain and business logic code, and we tend to shift into BDD style right now.

As our Product Owner is also an active developer, for acceptance testing, we tend to verify features within a team, as we have strong and common vision of a product within the team (see also acceptance in our DoD for stories). It’s a low ceremony process (as are all our processes in the team).

How often do we release? Every 2–3 months.

What have we learned from our last retrospective? That we need to shift into feature branches to be able to release small stories more often while the big ones are still in progress.

Do you see any flaws or warning signs in what I’ve posted here? Go on, say it… we’re always happy to improve…

It would be fun to hear from Target Process, ThoughtWorks Mingle team, VersionOne, AgileBuddy, and anyone else I might have missed.

5 Comments

Read More

Quick Agile Links

November 16, 2009 in Books, Links, Tools by Mark Levison

An idea shamelessly stolen from O’Reilly Radar. Every week I will publish a short article with 4-6 relevant Agile links. I’m open to feedback on the frequency etc.

Given last weeks announcement from Jerry Weinberg, it seemed appropriate to kick of with a couple of items related to him:

The Scrum Alliance twittered about a new list: Scrum Alliance community discussion group: “All healthy discussion is welcome. Differences in opinion and thought are encouraged. Spam, abusive language and direct advertisements/attacks aimed at splintering the community’s energy are prohibited and violators will be warned/banned. Heated debate, differences of opinion, methods other than Scrum or desire for a different SA community group are all open topics. Please be respectful of each other and be mindful that email is often toneless and can therefore be easily taken wrong.” My take – this is a good place to discuss issues that would get you kicked off ScrumDev.

Given/When/Then And Example Tables Using the Robot Framework – Shows how to BDD/ATDD style grammar’s in RobotFramework.

The Airplane Factory game: “The Airplane Factory Game is a simple game to introduce people to Agile and SCRUM. And also, it could be easily adapted to Lean, XP, etc. This article will explain briefly the game, showing the rules, some tips and results. Also, you will be able to download it” I’ve not had a chance to try this game yet – but the premise does seem interesting.

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

0 Comments

Read More

My Challenge to Agile Tool Vendors

November 10, 2009 in Agile, Tools by Mark Levison

image I keep on seeing announcements for the next great Agile Task Tracking tool. I just saw one posted to Scrum Development where it’s author said: “I haven’t done much testing, so if you find a bug and want me to fix it let me know :-)”.

My reply: Congrats I’m sure you have an excellent application. I’m wondering if you see the irony – you’re posting to an Agile group and say that your app has hardly been tested? What is your definition of Done? Do you use TDD? At least Unit Testing? What was your approach to acceptance testing?

My Promise

Here is my promise to all of my future clients, I won’t show you an agile tool that wasn’t developed using Agile methods. From future tool suppliers I need to know:

  • Your Definition of Done
  • Whether you use TDD? Or at least Unit Testing?
  • What do you do for Acceptance Testing?
  • How often do you release?
  • What did you learn in your last retrospective?
  • ….

If you can’t answer these questions I’m not interested in your tool.

Update I mis-understood the author’s intent. He’s not releasing a tool, so much as testing the waters to see if there is any interest. For these purposes I think he did the right thing. I still stand behind the statement I would show a client a tool where the vendor couldn’t answer the above questions.

16 Comments

Read More

Code Smells -> Refactoring -> Unit Tests

November 3, 2009 in Software Development, TDD, Tools by Mark Levison

Striped Skunk - Mephitis mephitis Two weeks ago I gave an introductory tutorial on “From Code Smells to Unit Tests” (pdf) at Agile Tour Toronto (thanks to the organizers for a great conference). The slides presented an introduction to Technical Debt, SOLID Principles, The Sea of Complexity, Basic Code Smells, Refactoring and Unit Testing Basics, and Good Practices, Bad Practices. As usual, the slides were only taste of what was said. In the session, two elements didn’t work: First, I wasn’t expecting to have to explain SOLID Principles—I was caught off guard and was ill prepared. Second, the pair Refactoring Demo tanked. The plan was to invite audience members up to refactor Martin Fowler’s Movie Example (git hub browseable, zip file) and then they Sea of Complexitywould make small improvements five minutes at a time.The goal was to help people integrate what we had already covered in the seminar by doing it live. There has to be another way of providing an integration event. Basically, I would need to give the audience a way for experiencing refactoring for themselves.

Please try the Movie Example (git hub browseable, zip file) and see how far you can get with some simple refactorings.

References:

BTW David Koontz did the hard work of typing in Martin Fowler’s Movie sample – I just modernized it (Java 1.2 –> 1.6).

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

1 Comments

Read More

Don’t Do Agile

November 2, 2009 in Agile by Mark Levison

Via the Agile Ottawa Blog: Don’t Do Agile:

Tim Bacon will be talking this month about the focus in an Agile rollout is the change required and not so much on “Agile”. This will be an exciting discussion and will certainly give pause to think of Agile in a different light.Agile Practices

Tim specialises in assisting teams or organisations to introduce Agile software development methods such as Scrum or XP. He is a passionate “people person” and an advocate of test driven development and software craftsmanship, with over a decade’s experience working with software development teams in the UK, Ireland, Netherlands, Sweden and Switzerland. Tim enjoys his work most when helping teams to see that they can produce more and better software with less stress.

Time and Date: Tuesday November 10th: Networking from 6:00 – 6:30; Presentation from 6:30 to 8:00

Location: the Code Factory (2nd Floor – 246 Queen Street), you need to buzz for the elevator.

0 Comments

Read More

Learning Best Approaches for your Brain Slide Deck

in Books, Science by Mark Levison

go2.wordpress[1] As regular readers of this blog will know I’ve given a talk based on reading’s in Neuroscience, called “Learning Best Approaches for Your Brain” – several times this year (Agile 2009 and Agile Ottawa). After several requests I’m posting the slide deck (pdf) here – but I’m afraid that it will really only be useful to the people who attended the talk. Here’s the promo I’ve been using:

Do you mentor, coach, teach or just help other people? Do you wonder why after your greatest teaching moments people just don’t get it? In recent years neuroscience has started to provide us with a number of insights into what happens when we’re teaching. These insights make it clear that learning is really about building and reinforcing existing neural networks. Instead of providing lots of new ideas out of the blue, we need to understand the learners existing context and work with that. Instead of focusing on mistakes and errors, we need to focus on what good solutions look like.

Top 5 Reasons that traditional approaches to learning and mentoring fail:

  • Lead with the Abstract
  • Not Grounded in the Listeners experience
  • Passive students – i.e. Those just listening and taking notes, aren’t using all of the brain. They retain knowledge but don’t really understand it.
  • Rewards don’t work
  • High Fructose Corn Syrup

Benefits:

  • Students and Mentees will remember
  • Learn how to correct mistakes
  • Workshop Attendees will stay awake

References:

I promise that sometime in the next month or so I will publish the paper that Linda and I originally promised (threatened), that will include all of the details missing from slide deck. The only caveat no paper will every be as good or help you learn as much as an interactive, example driven presentation.

Download: Slide Deck (pdf)

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

3 Comments

Read More

If you enjoyed this post, subscribe to my RSS Feed