Self Inflicted Agile Injuries

December 20, 2009 in Agile, Tools by Mark Levison

image Offshoring is frequently promoted as a way to produce great products for far less money. So many software development companies boast about sending large amounts of their work to India or China to reduce costs. Unfortunately in doing so they’re often reluctant to pay the price to create and maintain high performance distributed teams.

Agile works on the basis of a few simple principles:

  • Short Feedback loops – which leads to iterations, TDD, …
  • Radical Transparency – which leads to daily standup, demo/review, …
  • Face to Face Communications – which leads to high trust, group problem solving, …
  • Value – which leads to eliminating waste
  • Continuous Improvement – which leads to retrospective, adoption of engineering practices.

Thinking back on every project that I’ve ever worked on (Agile or not) the quality of communications was a good predictor of the success. So when we run distributed teams there has to be a focus on making the communications work.

At best the typical approach to this problem is to buy web cams, fancy video conferencing software and conduct our meetings sitting in front of them. But that misses the point – these devices improve the quality of communications but not enough. They don’t build trust. To really build trust you have to meet face to face for at least a week. Unfortunately trust is weakened through the course of the year, so it has to be renewed. At a minimum team members need to visit each other twice a year.

So if you really want to get a high performing team – don’t underestimate the real costs, budget for travel – a minimum of twice a year to build and maintain trust. Don’t short change your distributed teams.

Random Notes on Staying A Little Bit Organized

December 11, 2009 in Tools by Mark Levison

image Almost exactly three years ago I was trying to use David Allen’s "Getting Things Done" (GTD) system and I wasn’t seeing the benefits he promised. In the end I just found that it helped me thrash. I suspect the problem was more my focus than his system – but at end of the day his approach just didn’t resonate with me.

Today my system is a little closer to a hybrid of Mark Forester’s AutoFocus and Francesco Cirillo’s Pomodoro Technique. I still use MLO as my task manager but on a more granular level than I used to. Instead of slaving over MLO constantly now I use to help generate my list for the day. I use MLO to keep track of a large list of tasks. Mostly I just use the outline to remind of thinks I want to tackle. Daily I glance at the TODO view to make sure that there isn’t anything that is date sensitive that I’ve lost track of. Once it comes to committing to tasks for a day I often use Index cards using MLO, email and anything else as inputs. At the end of a day (sometimes two) I take anything that remains in the card and put into MLO. Then I tear up the card that’s probably the most fun part.

Other habits

  • I sweep my tabs in firefox every few days and move stuff to reading lists in MLO.
  • Once/Twice a week I go offline and go through my email.
  • Once a week I take some time to reflect – what is going well; needs improvement; what need do I have the energy to improve; what one thing can I do next week to improve it. Aka a retrospective. This is the hardest one to maintain – because you’re tempted to skip it and get more "work" done. Yet its the most important because it drives real improvement.

I use the Pomodoro Technique for:

  • a reminder to stay on task
  • a way of doing rough estimation every morning

Also on a two monitor setup under Win7 I dock MLO on the far left and leave it in outline mode where I can always see other things I want to do.

Other tools I use: ClipMate Clipboard Extender – because it allows me handle more than one item in the clipboard and to clean (i.e. remove html etc).

Tool Vendors Reply to My Agile Challenge

November 19, 2009 in Agile, Tools by Mark Levison

image Last week I challenged Agile Tool Vendors and the post got a little bit of attention, I got 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 of our stories. We didn't start out that way, however 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 then 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 commenters 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 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, however 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 becuase 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 one of active developers, 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 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, anyone else I might have missed.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

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.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

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.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Code Smells -> Refactoring -> Unit Tests

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

Striped Skunk - Mephitis mephitis Two weeks ago now 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 walk cover  an introduction to Technical Debt, SOLID Principles, The Sea of Complexity, Basic Code Smells, Refactoring and Unit Testing Basics, Good Practices, Bad Practices. As usual the slides are 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) – the plan was that peopleSea of Complexity would make small improvements five minutes at a time. The goal was to help people integrate what we had covered in the seminar already 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.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Agile 2009 Monday Conference Sessions that catch my attention

August 20, 2009 in Agile, Agile 2009, Software Development, Tools by Mark Levison

Last year just before Agile2008 I wrote a series of posts about my the sessions I was planning on attending. Last year was used to help coordinate a diverse group of IBM’ers, this year the audience is smaller: me.

Monday Morning 

9:00 – 11:00:  will likely be open jam time for me. Come find me there and lets have a conversation.

11:00 – 12:30

Kanban adoption at Software Engineering Professionals (SEP) Chris Shinkle (45 minutes) – “In 2004, SEP tried adopting Agile practices. However, Agile failed to have the desired lasting impact across the entire organization. Things changed in 2007, when SEP implemented Kanban for the first time.”

The Agile Playground Tobias Mayer (90 minutes) – “Agility in Action… This session will introduce five interactive games that a facilitator can add to their toolkit for team and management training. The games all illustrate the principles and dynamics that support Agility. The rationale for this session is that people learn best by embodying the learning, rather than just receiving knowledge at a head level. All participants will be immersed in the games; there are no observers. At the end of the session the participants will have a set of games they can introduce into their own organization to enhance their own Agile adoption process.” From my own recent experience: Learning: the Best Approaches for Your Brain – I can say that games are a vey useful way to integrate knowledge.

Using the Agile Testing Quadrants to Plan Your Testing Efforts Janet Gregory (90 minutes) – “Different testing approaches are needed because quality has many aspects besides functional requirements, such as making sure the code is reliable and secure. How do you know you’ve done the kinds of testing and quality processes are necessary for your product, especially on an agile project?”

My choice: Tobias “Agile Playground” Caveat Tobias said he wants at 16-24 for this workshop, please don’t overwhelm him based on my recommendation.

Monday Afternoon

14:00 – 15:30

Help already too many amazing options. First a bunch of experience reports:

Enterprise Agile Transformation: The Two Year Wall Chuck Maples; Weaponized Scrum Michael Marchi; Accidental Adoption – The Story of Scrum at Amazon.com Alan Atlas; The Amazing Team Race – A Team-Based Agile Adoption Gabino Roche, Jr., Belkis Vasquez; The Covert Agilist Ken Howard; Descending from the Architect's Ivory Tower Andrew Rendell – I’m interested in all of these but they have some stiff competition:

In the end its coming down to three options:

When it just *has* to work: Agile Development in Safety-Critical Environments Brian Shoemaker, Nancy Van Schooenderwoert

What Does an Agile Coach Do? Liz Sedley, Rachel Davies – They just written the book on subject.

Creating Agile Simulations and Games for Coaches and Consultants Elisabeth Hendrickson, Chris Sims (3 hours) – This one is on the Manifesting Stage for which I was a reviewer and I championed the presentation. I love the idea of learning how to create games. I’m really hoping that Elisabeth and Chris distill their knowledge into an InfoQ article.

My choice: I’m torn between Rachel and Liz – What Does an Agile Coach Do? – I’ve got to work this a bit myself and Creating Agile Simulations and Games.

16:00 – 17:30 I may be meeting with Linda in this time slot so I will play this one by ear.

Team Start-up: one of the first Agile Adoption activities Lyssa Adkins (90 minutes): “Starting up an Agile team is one of the first things you might be asked to do when a company wants to “go Agile.” What do you need to know before starting up a team? In the start-up, how much do teams need to know about Agile before they “go”? What do they need to know about each other…what the project is all about…who they will become as a team? These and other questions are answered as we walk through good ways to start-up Agile teams.”

Giving and receiving effective feedback Elizabeth Keogh (45 minutes) – “Find out why we give personal feedback, how to provide effective feedback, what makes feedback ineffective and how to deal with poorly phrased feedback. Learning what makes feedback effective helps you to seek your own feedback and improve, whilst being able to support the people around you.” echoes of “Giving an Taking Design Criticism with Rebecca Wirfs-Brock

10 Temptations of an Agile Coach (new or experienced) Stevie Borne (45 minutes): “Regardless of your coaching experience, there are a wide variety of temptations you can fall into that affect the quality of your coaching”

Effective code reviews in agile teams Wojciech Seliga, Slawomir Ginter – I was tempted by this one but as I read the description it feels a bit like a vendor talk. “The session includes a demo on how Atlassian Crucible integrated with leading IDEs via Atlassian IDE Connector facilitates the whole process”  Not interested. To be clear I like Atlassian and their tools, but it feels like the talk has less value without their tools $$$. See the exchange in the comments below.

My Choice: Team Start-up: one of the first Agile Adoption activities Lyssa Adkins

If you enjoyed this post, subscribe now to get free updates.

Urlseek.vmn.net or the Evil that is Hidden in Toolbars

March 31, 2009 in Other, Tools by Mark Levison

A few weeks ago I need to capture the output of a program in the form of a PDF. A few minutes googling led me to PDF Creator (hosted at SourceForge). The application itself is great however when you install it a toolbar is bundled with it pdfforge. You don’t get an option its simply installed on your behalf – as ‘benefit’. The worst parts of the license agreement are below:

Functional/Acceptance Test Tools for Web Apps

February 10, 2009 in Agile, Tools by Mark Levison

I used to be rich client guy, but my current client is building web apps and so all of a sudden I'm a web app guy. Now I wish I’d paid more attention in the past. For my penance I promise to document whatever I learn on the forthcoming Agile Tools Functional Test Wiki (i.e. the wiki that we discussed last year at the AA-FTT meeting before A2008).

My client is building an ASP .NET application and we're trying to decide how to test it. The issues I have to deal with:

  • The two QA people have no coding experience so any tool that requires significant coding will require more development support.
  • The application will be run in IE on the IIS webserver. No other combinations need be tested.
  • The application is really a document creation and management system. Once the documents have been created and approved they're submitted to an outside system.

Unit Testing in JavaScript

November 25, 2008 in Software Development, TDD, Tools by Mark Levison

Last week a colleague asked for my help finding better unit test tools for Java Script. He’s done some digging on the state of the art with JavaScript unit tests and finds the whole lot wanting. His discoveries: