Agile Planet

November 18, 2011

Simon Baker

Beware the Coefficient of Fiction

There’s a saying: “If it isn’t official, it hasn’t happened”.RAG reports spring to mind. I’ve seen too many RAG reports that have not reflected reality to respect them as a means to report status. Usually, a project sta...

2011-11-18T13:48:50Z

Simon Baker

The (un)ethics of Big Vendor contracts with cost-driven companies

Consider a company looking to procure external software services. This is a company that manages by objectives and spends time and effort micromanaging costs. In a typical procurement situation, probably a tender for services, their fixation on cost pushe...

2011-11-18T10:58:59Z

Mark Levison

By: Reflections: Co-Training with Mark Levison (CST) July 6-8, 2011 | Agile Guidance via Paul Heidema

[...] more and from Mark Levison: http://agilepainrelief.com/notesfromatooluser Be Sociable, Share! Tweet(function() {var s = document.createElement('SCRIPT'), s1 = [...]

by Reflections: Co-Training with Mark Levison (CST) July 6-8, 2011 | Agile Guidance via Paul Heidema at 2011-11-18T04:04:47Z

November 17, 2011

George Dinwiddie

Tips and Advice: Test Driven Development

Yesterday, Bob Payne published one of our informal Tips and Advice discussions on the Agile Toolkit. Check out our Test Driven Development podcast and let me know what you think.

by George Dinwiddie at 2011-11-17T13:34:59Z

November 16, 2011

George Dinwiddie

Who is…

Yesterday, Yves Hanoulle published his interview of me as part of his Who Is series.  It was a good opportunity for a little introspection about myself and my career.

Red-Green-Refactor Test Driven Development hat

Hat for Test Driven Development

He included a photo of me wearing my Red-Green-Refactor TDD hat. This had may be more famous than I am, having been worn by Uncle Bob Martin in Episode 6 of his CleanCoders videos.

by George Dinwiddie at 2011-11-16T12:34:18Z

November 07, 2011

George Dinwiddie

Sad Statements

I hope this will be done by then.

These are sad and scary words to me.  When I hear them in the context of a software development project, I associate them with a project unlikely to meet expectations.  Further, it’s likely that there is no good indicator of what can be delivered when.  With no hard evidence to tell them what’s possible, and to judge the effects of changes they try, people fall back on a strategy of hope. They no longer feel in control of the situation.

We’ve done our part.

This signals the underlying hopelessness. When you can’t make things come out the way you want, when you can’t even predict how they will come out, one natural response is to give up. Often the cultural expectations don’t allow saying “this project is in trouble.” The person who does so is the person who will attract all the scrutiny. Without the clear data to back up the perception of trouble, why stick your neck out? Others should be noticing the same thing; let them call attention to it. And when things don’t work out as “hoped,” if weve “done our part,” then someone else will get the blame.

You can’t solve a problem that no one wants to see. Instead, we’ve found an acceptable way to fail.

by George Dinwiddie at 2011-11-07T00:37:51Z

November 03, 2011

George Dinwiddie

The Code of Christmas Past

When we write code, we’re often thinking about the short term. We need this code to function correctly so we can deliver within our immediate deadlines. I’ve found it important to also think of the long term. Sooner or later, we might encounter our own code, again.

I spent a chunk of my career where I often worked solo on projects that might get enhanced every year or two. This taught me a lot about the importance of code readability and what sort of things helped me quickly understand and avoid overlooking important considerations. I’ve also worked on a lot of legacy code bases, so I’m well aware of the pain and problems created by code that’s not readable, or is not organized in a helpful manner.

Last week at the AgileDC Conference, someone told me they were working on code I had written ten years ago. My first question was, “Are the unit tests still working?” This code was the first production code I ever wrote test-first, and it taught me a lot doing so. I was glad to hear that they had been maintained. When I was writing them, I couldn’t get anyone else interested in test-first development.

Even more gratifying was hearing that they’d recently used some of my code as an example in a discussion of object-oriented programming. The example they’d used was where I’d wrapped an integer in a class. Why would I do that? Because it wasn’t really an integer. It was a database ID. The integer was just an artifact of the database automatically creating ID values using a sequence. It would make no sense to perform arithmetic on it. And there were IDs for various entities that should not be used interchangeably.

Class diagram for a class wrapping an integer

The integer value was intended to be used only within the Data Access Object that read and wrote the database.

A few years ago, I was asked if I could change an algorithm in some embedded assembly code that I’d written more than ten years prior, and I hadn’t even seen for over ten years. Setting up the development environment wasn’t easy, as much of the hardware was no longer manufactured. The code, however, was not hard to modify. I had implemented the algorithm using state machines and data tables, and had created semi-readable constants for all of the “magic numbers” used.

Code is read much more frequently than it is written. Writing it clearly and expressively pays off when we have to read it next week or next month. Well-written code is also much more likely to be useful for decades into the future. If you write code only for the short term, it’s likely to have only a short life. People will find it necessary to rewrite it rather than maintain it for the long term.

by George Dinwiddie at 2011-11-03T03:01:31Z

November 02, 2011

Simon Baker

Using Spikes

The XP practice of ‘spiking’ has been around for a while but there isn’t a whole lot written about it. Why Spike?The XP site states that the purpose of a spike is “to figure out answers to tough technical or design problems”. Spikes are ...

2011-11-02T13:30:08Z

October 24, 2011

Sammy Larbi

I'm sorry I didn't give you a chance, #each_cons

With a name like each_cons , I thought you were going to iterate through all the permutations of how I could construct a list you operated upon. For example, I thought [ 1 , 2 , 3 , 4 ] . each_cons do | x | # I did not notice the required argument   puts x. inspect end   would output: [[1,2,3,4], []] [[1,2,3], [4]] [[1,2], [3,4]] [[1], [2,3,4]] [[], [1,2,3,4]] So when I needed to find the ...

by Sammy Larbi at 2011-10-24T14:45:58Z

October 17, 2011

Sammy Larbi

Algorithmically recognizing the staff in sheet music

It's a small step, but emcee-3PO can now identify the staves in an image of sheet music for my single test case of "My Darling Clementine." I need to include hundreds more test cases, and I plan to when I implement code to make the tests mark the sheet music with what emcee3po detected so I can visually inspect the accuracy. Ichiro Fujinaga's "Optical Music Recognition using Projections" (PDF) explains the process in detail, but it turns out to be relatively simple. To locate the staves: Do a y-projection on the image. ...

by Sammy Larbi at 2011-10-17T21:20:33Z

October 13, 2011

Mark Levison

Scrum Master Tales – More Interruptions

Prohibitory traffic signPart of an ongoing series called Scrum Master Tales. The series covers ScrumMaster John and his team as they develop an online bookstore.

Last time we read about our team they were suffering from a very high rate of interruptions after the product had gone live: The Story of Production Support.

After another couple of sprints using the one “person off” strategy the production support problem wasn’t completely fixed but the team was starting to spend less time on support. However John started to notice a new problem, even though production support wasn’t the primary cause there were still alot of interruptions, he still noticed that team members were being interrupted (a mix of drop by, phone calls and email).

John spent the next few days just taking notes on the interruptions. Discounting friends dropping by for coffee or smokes and calls on personal phones (presumably family or friends), he could still see that his team members were being bothered 2-3 times a day. Taking the best notes he could without outright spying on people, some of the interruptions were obvious:

  • a couple of people called Martin every time there was a database problem (big or small)
  • team members attended meetings (corporate, HR, …) sometimes more than one
  • Tonia (the world’s best Agile Tester) has become a focus for Agile testing questions with people stopping by her desk 2-3 times a day to ask questions about Agile testing.

To track these issues John didn’t need to spy, he just watched the flow of people in and out of the team space, listened for phone calls and read the email trail that filled his inbox.

Once John noticed the issue he mentioned into a standup and asked people to start tracking what sort of interruptions they had. In the retrospective the team discussed sources of interruptions (again using a timeline as reminder).

Discoveries:

  • Corporate meetings that don’t aid directly in the delivery of software
  • Several team members are the only ones who know their respective areas (Database Architecture, QA), as a result for issues big or small everyone asks them for help.
  • People outside of the development group don’t appreciate the cost of interrupting the team. In particular they don’t understand the costs of context switching (allow 20-30 minutes to recover if working on a complex task).

Analysis

Caveat Emptor: Remember the Lean Principle: “Optimize the Whole”. In this case ensure that the strategies benefit the whole system and not just one team.

The key issue at play is that your brain can sustain 4-5 hrs of focused “Flow” work in a day. The question at hand is how can we help team members utilise that time?

First the team needs to make the cost of the interruptions visible to the organization. Very often these things happen because people think about their own needs: i.e. Martin knows the database and can answer my question quickly. vs. I can spend 15 minutes trying to figure things out for myself before turning to Martin yet again. This assumes the person with the question isn’t on Martin’s team, perhaps not even in the development organization.

Things the team can do:

  • Implement Core Hours – example 9:30 – 3:30 (with a break for lunch). During this time the team will focus on development (includes Test/Documentation/…) work. Interruptions from other development teams are expected but people from outside development are asked to wait. This does risk setting up an us vs. them relationship so it has to be handled well. The key is good communications: explain the problem, give specific example of the effects, tell people how core hours will work and seek their feedback after 2-3 sprints.
  • Email is turned off during core hours. Its best if email is checked ~3 times a day.
  • Pairing to share knowledge i.e. people from other teams should pair with Martin and Tonia to learn more about the specifics of their work.
  • Run lunch and learns to share knowledge that’s known by only key people
  • Reduce committee involvement. For corporate meetings and other events that won’t help the team deliver ask how many people from all of development need to attend.
  • Move meetings outside core hours. Most meetings don’t require the same amount of mental energy as development. Consider moving them after core hours.
  • Consider removing company phones from team members desks. This may just shift the problem to people’s cell phones.
  • Get people to spend at least 15 minutes trying to solve their own problem before asking for help. If nothing else this will deepen a persons knowledge in that area making it less likely they will have to call for help next time.

Perhaps most important make the cost of interruptions visible to the organization. I often use signs at the edge of the team area.

Update: When I say development team I don’t mean coding I mean the people involved to getting the application out the door (Coding, QA, Docs, UX, … – assuming you have separate roles still).

Image Credit: MZacha “Prohibitory Traffic Sign

Next up:
An aside on tracking sprint and release progress, burndowns and interruptions

by Mark Levison at 2011-10-13T16:12:03Z

October 12, 2011

Sammy Larbi

plupload-rails3 available as gem; works on 3.1

plupload-rails3 is ...

by Sammy Larbi at 2011-10-12T19:58:34Z

October 08, 2011

George Dinwiddie

5 Minutes to Process Improvement Success

Most of my recent writing has not yet been published. That, and work on the upcoming AgileDC Conference and Agile India beyond that, have meant relatively little output on my blog. I apologize for that.

I’d like to share with you an interview conducted by Bill Fox for his 5 Minutes to Process Improvement Success project. My interview, “Measure Progress in a Way that’s Visible and Reliable,” is found on page 69 of the PDF.  You’ll also find interesting interviews with Karen Base, Kevin Schaaff, Hillel Glazer, Scott Ambler, Neil Potter, Bob Payne, Mike Bonamassa, Mario Hyland, Jeff Dalton, Paul E. McMahon, Karl Wiegers, Mary Lynn Penn, Ally Gill, Alan Shalloway, and Tom Cagley. And there are more to come in the future.

by George Dinwiddie at 2011-10-08T15:35:27Z

October 06, 2011

Mark Levison

Neuro Agile Quick Links #2

At Agile2011 Kevlin Henney provactively suggested that we don’t learn from mistakes (see: Why we don’t learn from our mistakes, The Optimism Bias), suggesting that we learn more from our successes. This seems to against the core agile principle that we learn from our mistakes (i.e. my motto “Fail Fast” etc). It also seemed to contradict the message in Linda Rising’s keynote that followed Kevlin. This makes me very happy to have seen a pair of articles in the past few days that bridge the gap: How Your Brain Reacts to Mistakes Depends On Your Mindset (a short summary from Science Daily) and Why Do Some People Learn Faster? (a longer item from Jonah Lehrer that ties several ideas together). The upshot both Kevlin and Linda were right. We do learn from our mistakes but not everyone has the mindset to do it.

High Social Status Makes People More Trusting, Study Finds – trust is important in the world of Agile software development and this summary from Science Daily gives some more insights as when trust is conferred.

Men and Women Cooperate Equally for the Common Good, Study Finds – its a well known fact that women are better than men when it comes to cooperation. This item summarizes a meta-study, which does make clear there are still some differences between the sexes. (Also Science Daily)

The Problem With Narcissistic Leaders (Jeremy Dean @ PsyBlog) – talks about the negative effects of Narcissistic leaders – they reduce the flow of information between groups but perhaps most insidiously the group members may think the narcissists were doing a good job. See also Why We Love Narcissists (At First).

Playing games ‘engages whole brain’ – (from the UK Press Association), the short item is provocative and appears to support the use of Agile Games/Simulations in training, coaching and improving engagement in solving problems. Having struggled to read the paper (neither neuroanatomy nor statistics are specialities of mine), I can see how the UK Press drew its conclusion at this stage I would like to see the follow-up research from Timothy Vickery to see where this applies and what benefits we can claim.

This is part of an ongoing series I refer to as Neuro Agile – which is my attempt to find ideas from the world of neuroscience that are applicable to world of software development.

Update Added another link to better represent Kevlin’s point: The Optimism Bias

by Mark Levison at 2011-10-06T19:21:43Z

October 04, 2011

Mark Levison

ScrumMaster Tales – The Story of Production Support

Mini Tripé 11 - Image Credit: Leo Cinezi http://www.sxc.hu/photo/582114When we left John and the team they were just getting the shipping features ready and were waiting to go live with the site. This turns out to be a blessing and a curse. Its a blessing because the business is making money, a curse because with it come support issues.

John spends some of his time and energy just watching the team and their flow everyday. In the first two sprints after the release the team struggles and fails to meet its planning commitments. At first he’s ok and just says its the inevitable post release hiccups (I don’t agree with John on this one, its not inevitable I think it was a first warning sign – ed), but when its clear that its continuing into the 3rd sprint he starts to get worried. John notices that team members are being interrupted often several times a day. Most of the interruptions are support issues.

During the retrospective John chooses a timeline to help the team remember/discover what happened in the past two weeks. Its worse than even John realized, team members spent most of their time on Production Support. After some more discussion they discovered there were three major classes of issue:

  • Issues where a team member just had to help support understand how to help the customer
  • Issues that required a small code change and could be made by most team team members
  • Issues that required the specialized skills of one or two team members

Analysis

The team can do a number of things:

  • Choose one team member per sprint and they become the first point of contact for support. Some issues they can deal with themselves and others they will have to find help. NB this job should rotate so its never just one person.
  • If there are multiple teams, in any one sprint one team takes the support hit. This is the same strategy as the first at scale.
  • Wait until the days end before interrupting another team member for help on a support issue
  • Monitor the production support issues and track their effects on the teams productivity. Example usually in the days that follow handling a support issue the team is able to complete fewer stories. Remember its not just the cost of fixing the issue that needs to be tracked, but additional costs: deployment, multitasking cost,
  • Based on historical needs acknowledge in planning that there is a tax of 20-30% to be paid for support. This is my least favourite solution because it doesn’t help make the situation better it just increases awareness of it.

No matter what we every time a support issue comes up, do a root cause analysis or use A3 Problem solving to identify the real issue and reduce the number times it hits the team in the future. In addition we have to help the organization see the costs of what is happening, the support calls might be what the organization needs at the moment but needs feedback as to the impact.

Update: One of my readers (Sergey Kotlov) pointed out that in some cases the frequent production support issues are of a database/admin support type and suggest that the team has missed an opportunity to provide support with tools to help. He’s absolutely right, in that case the PO might want to prioritize work to create support tools so the development team can stay focused. Thanks to Sergey for his suggestion.

Image Credit:  Mini Tripé 11 – Leo Cinezi http://www.sxc.hu/photo/582114

by Mark Levison at 2011-10-04T19:19:25Z

September 29, 2011

James Shore

Let's Play TDD #144: Cost vs. Benefit

29 Sep 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-29T08:01:00Z

September 27, 2011

James Shore

Let's Play TDD #143: File → Save As...

27 Sep 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-27T08:01:00Z

September 26, 2011

George Dinwiddie

Calling All Coaches and Mentors

If you coach Agile teams, if you mentor your peers in better software development practices and processes, or if you are just learning to do these things, the Agile India Coaching and Mentoring stage needs your help.  Please propose sessions about your work and your experiences.

by George Dinwiddie at 2011-09-26T19:48:01Z

September 22, 2011

James Shore

Let's Play TDD #142: Good Enough

22 Sep 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-22T08:01:00Z

September 20, 2011

James Shore

Let's Play TDD #141: Domain-Specific Language

20 Sep 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

This episode refers to Esko Luontola's video commentary on Episode 132. His commentary is below and the source code is here. You can find his Let's Code series here.

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-20T08:01:00Z

September 18, 2011

George Dinwiddie

Independent Interpretation

Many organizations segregate their programmers and testers in order to achieve independent validation of requirements.  If the system is tested according to an independent interpretation of the requirements than used for implementation, then errors in those interpretations may be detected.

This course of action is obviously prudent when the requirements are handed down to the development organization in the form of a document. It does not, of course, detect errors in the requirements document itself. Nor does it detect errors of interpretation if both the programmers and the testers read the requirements in the same, incorrect way. When there is significant distance between writer and readers, this is distressingly common.

It’s difficult work to write clearly in prose. Publishing industries have developed the roles of editor and proofreader to check documents so that erroneous or unclear segments may be rewritten before they’re seen by potential readers. People who write requirements documents are frequently better versed in the desired functionality than in the process of writing them. And, they frequently don’t have so much help.

It’s also difficult to precisely interpret the writings of others, particularly of people you don’t know. A word may have an obvious and precise meaning in the context of the business, but an obvious and different meaning in the context of software development. In the fields of literature and law, expert interpreters may spend years or centuries honing a consensus interpretation of the written word. In software development, we rarely have time for lengthy discussion of complicated passages. If the writing is ambiguous or contradictory, faithful interpretation of the intent is even less certain.

We often seek clarification of the requirements to back up our reading of the document. Sometimes it’s difficult to get sufficient access to the document authors, and the programmers and testers may turn to each other for what clarification they each offer. I’ve had testers from a different company ask me how my software was supposed to work because they had insufficient access to the requirements document author.

Cross-checking the interpretation of programmers and testers punches holes in the wall of independence, of course. This sad state of affairs is a major source of defects in which the software “works as designed” but not as desired.

We can do better than this!

Instead of the business representative writing the requirements and handing them off as a document, imagine the business representative telling them to a programmer and tester (everyone taking notes as needed to keep things from being forgotten). Imagine the programmer and tester testing their understanding in real time with questions made directly to the business representative while things are still fresh on everyone’s mind. In doing so, they can not only challenge each others interpretation of the requirements, but also the assumptions of the business representative. Together they can hone the requirements to a sharper edge than possible when working separately.

by George Dinwiddie at 2011-09-18T01:25:56Z

September 16, 2011

Mark Levison

Scrum Master Tales–The Story of the Changing Needs

Stories-DickensCaveat – given the way I’m writing this series occasionally things will happen out of order, i.e. I will be reminded of points I wish I had made earlier.

John, Sue and the rest of the team have started another sprint this time they committed to fewer stories and part way through the sprint are well on the way to getting stories completed. This time they committed to 8 stories with sizes ranging from 2 – 8 points. Every couple of days they get a story accepted. Things are going awesomely well.

Story

  • As a Canadian book buyer I want to Amazon to ship my book to Canada so I can get my book home – Story Points: 8
  • As a Canadian book buyer I want to Amazon to calculate the import duty on my books – Story Points: 3
  • As a Canadian book buyer living in Ontario I want Amazon to calculate the local sales tax (HST) – Story Points: 2

Five days into the sprint Sue comes to the team and asks to add a new story. One that the team has previously sized as 5 Story Points: As an American book buyer I would like to use premium shipping so I can get my books sooner. She says its really important because she’s getting a lot of pressure to help get books to American customer’s sooner. John shots back that Scrum team’s make a commitment for the Sprint and once set can’t be changed without cancelling the sprint. Sue continues to press saying this is a really important story.

Analysis

What are the team’s options?

  • They can refuse.
  • If its an occasional event the team might trade out a larger story for smaller story, that hasn’t yet been started. This respects the fact that even though it hasn’t “started” the story effort has gone into analysis/design etc. In addition it recognizes that no switch is free.
  • Small changes to existing stories just happen. Sometimes as we gain a deeper understanding of a story and see it implemented the acceptance criteria or layout change. This is a good moment to remember the ‘N’ in INVEST (**link**). Stories should be negotiable. Small changes should probably just be accommodated. Larger changes maybe in the scope of the original story but in that case we might have to drop another story.
  • Cancel the Sprint – If a radical change in direction is required. Not in this case but perhaps the company has been acquired.
Update:
Clearly in the example the Story isn’t “pressing” in the context I’ve imagined I can’t imagine anything that would be so pressing that the PO couldn’t wait for another sprint. Maybe a good bug.
Also if this happens more than very very rarely we would want to do some root cause analysis and see why the PO’s needs change so frequently. Maybe there is some external pressure that we can’t see (Investors, other stakeholders). If the pressure means that the PO will need to make changes on a regular basis then that is a hint that the team might need shorter sprints.

by Mark Levison at 2011-09-16T01:14:47Z

September 15, 2011

James Shore

Let's Play TDD #140: Cleaning Up the Menu Code

15 Sep 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-15T08:01:00Z

September 13, 2011

James Shore

Let's Play TDD #139: File → Close

13 Sep 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-13T08:01:00Z

September 11, 2011

Willem van den Ende

A puzzled skeptics trip to ALE2011

As a frustrated and puzzled skeptic I went to the Agile Lean Europe conference to work on my frustration and puzzles. As a frustrated and puzzled skeptic I returned. To my delight with different frustrations, puzzles and some highlights.

Regardless of what I say next: creating a pan-european agile/lean event that is not tied to one of the schools of thought, nor any functional silo (looking at you, coachcamps and testing days!) is a major achievement. I tried to pull it off with about twenty other folks a couple of years ago, and failed (early, but nevertheless. It is not something I bake cake for ;) ).

First highlight: I found a community that welcomes skepticism without suffocating it. Thanks, amongst others, to @OlafLewitz and @ojuncu for open discussion on twitter beforehand, and to those who offered help instead of rotten tomatoes after I threatened to put trainers and coaches out of a job in a lightning talk :) . And those who took my call for more coaches combining hands-on work with coaching (too?) seriously. More on that in follow up posts.

Although many of the scheduled talks rehashed things I hoped would have vanished from agile / lean conference agenda’s to make place for new things, I was pleasantly surprised by a number of talks. (See below in talks)

Building a car using a distributed team.

Wikispeed is a collaborative, distributed effort to build a fuel efficient car (one that is also efficient at high speed, unlike some other fuel efficient car). Thorsten Kalnin described how they use whatever works to get there. At this moment that includes for instance aspects of kanban, scrum, using object oriented principles for mechanical engineering and finding storage boxes that can be rented for cheap, while still being suitable to do engineering work.

I’m listening to vinylbaustein’s wikispeed dreams while writing this. Finding new music at a conference, what do you want more ;)
Vinylbaustein – WIKISPEED dream – SGT01 mix by vinylbaustein

The inside wikispeed video is worth watching if you want to see more:

Your baby is ugly

Seeing Stephen Parry in action again, during his talk and afterwards during dinner. Olaf Lewitz has described other aspects of Stephens’ session. What I particularly liked was ‘your baby is ugly’ – get employees to analyze the companies performance as seen through their customers’ and describe that to their peers and managers (also mostly employees, lets’ not forget that). This is probably a lot more effective than outsiders saying that (e.g. Yours truly tweeting about how SAP is going lean but their products prevent their clients from evolving), and I guess it takes a lot of time and patience. Something I would like to try, nevertheless.

A3.

I stayed out of the Claudio Perrone’s A3 presentation after seeing the intro slides from outside which looked so heroic (Big Agile Transition), that I was afraid I would not be able to shut up during the presentation and heckle ehm excite. Turns out the rest of the slide deck is a lot more to my liking, including a pragmatic use of the satir change model somewhere in the middle. So I was wrong. Looking forward to see the video of it.

In the meantime I would recommend reading Toyota Kata by Mike Rother. I took it on the road this week and am pleased by how it does not try to make this kind of open ended coaching look easy, and uses storytelling plus questions to you, the reader, to show how this might work in your practice.

One more for the skeptic

It was only talks. Tip for next years’ organisers: if you want more hands-on sessions make some space for scheduled sessions that last longer than thirty minutes, some sessions that require preparation don’t magically happen in open space. Stephan Eggermont and I enjoy the challenge of seeing what of a three hour session we can meaningfully cram in thirty minutes, but we may be the exception. It seemed most people were watching as opposed to downloading the zip and following along.

I was looking forward to ‘exciters’, Walldorf and Statler from the muppets were given as example, and bar tables were placed in front of the presentations for people to heckle from. I haven’t seen that happen, and didn’t dare to either, preferring the safety of my twitter feed instead ;) . I asked Stephan Eggermont to heckle during my lightning talk, which he did, but I was so focused I didn’t hear him do it…

It seems the open space explanation left out the butterflies. When I described my open space experience to another participant at the end, he stared blankly at me. It also seemed mostly open space veterans where butterflying and bumblebeeing around, as well as applying the law of two feet (sorry, the politically correct wording used in the opening was so complicated I failed to remember it ;) . Shorter PC versions I’ve seen include ‘the law of motion’ or ‘when in doubt, move out’ ).

So I butterflied, mostly, except to host an open space session because someone wanted to pick my brain about session selection processes. The best suggestion in that session came from @LLillian, who stated the obvious thing I’d missed before: besides playing a perfection game, encourage session organizers to Ask for Help, to lower the barrier for new session organisers. Duh. Why didn’t I think of that before! Other than that, it struck me that few of the open space topics were original. It seems we have been struggling with the same problems for a couple of years. Maybe it is rotation of participants, maybe we are asking the wrong questions. Of course, I could have taken responsibility by posing a question as a session. It seems the stuff I’m struggling with right now is in a stage where I don’t know how to formulate the questions yet. It seems grumpy tweets, responses to that and hallway discussions help me move forward :) .

It will probably take a week or so to pinpoint my newfound frustrations and puzzles, at least I feel my time in Berlin was well spent. Especially now the QWAN Learning Community has some more first followers, I got over the scariest two minutes presenting I’ve done in quite a while, and I got useful feedback on the idea from various people. So thanks everybody for making it happen.

by Willem at 2011-09-11T16:21:59Z

September 09, 2011

Sammy Larbi

How to save your ass when tech support tells you the best way to solve your problem is to start over with a new server

If you follow me on twitter , you already know I ran into some trouble compiling Ruby and OpenSSL the other day. Calling it "Some Trouble" might be a bit of an understatement. The next morning, I likened it to this title bout: Not only was Ruby and OpenSSL giving me trouble, in my quest to get it working, I totally messed up everything that depended on OpenSSL . Email with TLS? Gone. SSH? Yep, gone as well. Tech support's first recommendation was to requisition a new server. Of course I wasn't going ...

by Sammy Larbi at 2011-09-09T19:43:40Z

Mark Levison

ScrumMaster Tales – the Story of an Incomplete Sprint

puzzleLast time we met John (ScrumMaster) and the team, they had just discovered that their backlog had many large stories and no-estimates. The team delayed the start of their first sprint, did some Product Backlog Grooming. When we meet them again their first sprint in is in progress.

Story

Coming out of the planning meeting the team committed to five stories totalling 42 Story Points. Their overall Sprint Goal get the customer’s book home:

  • As a book buyer I want to add my book to my shopping cart so that I can purchase it – Story Points: 13
  • As a book buyer I want to tell Amazon where I want my book shipped to so I can get it – Story Points: 8
  • As a book buyer I want to see the price for my books with shipping and tax so I can see whether I’m ok with the price – Story Points: 3
  • As a book buyer I want to choose my payment type (MasterCard, Visa, Amex or Paypal) so that I can pay for my book(s) – Story Points: 3
  • As a book buyer I want to pay for my book(s) so I can get it home – Story Points: 13
  • As a book buyer I want a confirmation message so I can see that the purchase was successful – Story Points: 2

The team (7 team members including John) started work on the first four stories right away (27 Story Points in total). Tonia the team’s on QA specialist spent the first few days with Brad (the BA) clarifying the acceptance criteria for the stories and designing her manual test cases. She also worked with a couple of developers to clarify the details of the stories. By Monday (Day 5 of the Sprint) she had completed all of this work and was hungry for an application to test. In fact she was wondering why she hadn’t seen it as promised on Friday. Lacking an application to test she found other things to do outside the team. It wasn’t until Wednesday (Day 7) that she finally had the first story (“add my book to my shopping cart”) ready for test. Tonia scrambled but it was a big story and took much of the day just to get the environment ready to test. By day’s end she had found a dozen issues and shared them with Ian. “Add my book to my shopping cart” was clearly not ready yet. In the meantime other stories were piling up in front of Tonia and she was unable to keep up with the testing. At the end of the Sprint Sue only accepted two stories as complete “see the price for my books with shipping and tax” and “choose my payment type” for a total of 5 Story Points. Everything else was incomplete.

In the retrospective the team identified a number of things that contributed to the problem:

  • They over-committed
  • They took on large stories with splitting them down more
  • They had too much work in progress

For the next sprint they identified several improvements they could make:

  • Always split stories of size 13 or larger
  • Never have more 3 stories in progress at once (that forces people to collaborate on Stories)
  • Handoff incomplete Stories for early testing. Early feedback on partially complete work will help save team members going down many dead ends.
  • When working on larger stories 5 and 8 swarm them

Analysis

Nearly every time I’ve seen a team take on a story of 13 points or more the team doesn’t succeed in completing it in that Sprint. Usually because stories of that size have alot of hidden complexity and surprises.

I’ve also noticed that limiting the number of stories in progress to less than half the team size i.e.

Team SizeLimit on # of Stories in Progress
52
63
73
84
94

Helps ensure that work is completed before new work is started. Kanban folk achieve the same effect by setting up their Kanban board and setting WIP limits.

Finally when a team is new and is having trouble seeing the effects I create a simple table on a white board:

Story Points by Day

MTWTFMTWTF
Development272727272727271499
QA000000013189

N.B. The QA/Development split isn’t meant to encourage this to happen its just a reflection of what most teams deal with when they first start.

Combined with a Sprint Burndown (in Story Points) it help the team spot problems as they start to happen and diagnose them in the Retrospective.

What tools do you use to help teams see these problems?

by Mark Levison at 2011-09-09T14:45:03Z

September 08, 2011

James Shore

Let's Play TDD #138: New Windows

08 Sep 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-08T08:01:00Z

September 07, 2011

George Dinwiddie

Invest in yourself

I write this post from Loveland Colorado, the current location of Consultants Camp. This is an international gathering of consultants who share information and lessons with each other. It’s part of my practice of self-improvement.

I invest a lot in my own professional development every year. I attend conferences such as this one. I read. I converse with colleagues.

My career has spanned a number of decades, and I expect to continue to do so indefinitely. I gave a talk at XPDay Manhattan in 2007 on Sustainable Career where I explored this topic. To do so, you not only need to continue learning, you need to learn things that have a long half-life. Learning specific technologies may be valuable, but those technologies quickly become obsolete. Be sure to also learn things with lasting value, such as the principles behind specific techniques.

You need for your career to last a lifetime. Invest in yourself.

by George Dinwiddie at 2011-09-07T19:33:20Z

Willem van den Ende

We are uncovering better ways of moving post-its

Ten years after the agile manifesto I believe we’re better of with it, than without it. To me, it served as a rallying cry for those who were developing software to improve themselves by looking at what works in practice.

Remember? “We are uncovering better ways of developing software by doing it and helping others do it.”.

The reason this appealed to me, was that I was working at the time, and had been working before, with good willing, hard working people who advised others on building and delivering software, but they didn’t get their hands dirty (and if they did, their practices looked nothing like what they advocated for clients). With Agile, I believed we had a fighting chance to do better than what came before, prevent methodology wars by finding what unites us and market ‘lightweight methods’ a lot more effectively.

These days, when I travel to an agile or lean related conference (and even to some craftsmanship related events) most participants are full time managers or coaches, occasionally coding at night if they are so inclined. In the early days, if I would run into a fellow coach, it would be someone like me, who worked at all levels, with all stakeholders while also working hands-on with and in teams. These days, if I get cynical, it is, more often than not, someone who helps a team to move post-its better, either through kanban or scrum.

Not that the intentions behind scrum or kanban are bad (‘improving the world of work’ and ‘Evolutionary change for your technology business), it’s just that obsessing over the mechanics, such as the right way to move post-its or the best practice for stand-ups costs less energy than thinking for ourselves about how we work, and what we can improve.

As I’m leaving for ALE2011, which on the surface looks like it’s packed with post-it moving folks, I hope to be proved wrong and be surrounded by complex systems thinking hackers, like  I was at XP2001, just after the agile manifesto had launched. That ALE opens with a massive coding dojo gives me some hope.

Otherwise, it’s just going to be 3M who benefited the most from lean and agile software development ;)

by Willem at 2011-09-07T13:18:22Z

September 06, 2011

James Shore

Let's Play TDD #137: How Many Frames?

06 Sep 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-06T08:01:00Z

September 02, 2011

Sammy Larbi

Dealing With Embarrassing Breaking Changes

Frequent changes and deprecations to technology you rely upon cause dependencies to break if you want to upgrade. In many cases, you'll find yourself hacking through someone else's code to try to fix it, because a new version has yet to be release (and probably never will). That can be a chore. I get embarrassed when something I've recommended falls prey to this cycle. Backwards compatibility is one way to deal with the issue, but in the Rails world, few seem worried about it. It doesn't bother me that code and interface quality is a high priority, but it does cause ...

by Sammy Larbi at 2011-09-02T20:18:23Z

James Shore

Let's Play TDD #136: Accelerators

02 Sep 2011 James Shore/Blog/Lets-Play

It's the one-year anniversary of Let's Play TDD! In celebration, new episodes are going up every day this week.

The source code for today's episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-02T08:01:00Z

September 01, 2011

James Shore

Let's Play TDD #135: File → New

01 Sep 2011 James Shore/Blog/Lets-Play

It's the one-year anniversary of Let's Play TDD! In celebration, new episodes are going up every day this week.

The source code for today's episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-09-01T08:01:00Z

August 31, 2011

George Dinwiddie

On Failure, Success, and Learning

When I was a kid, I decided to invent a new kind of battery. I had a pretty good idea of what was required, having cut open my share of batteries and even built them with a lemon, copper, and zinc. It’s just a matter of two metals (or one metal plus carbon) and a corrosive liquid. How hard could it be to create the battery of the future?

I mentioned my aspirations to my father, who was a chemistry professor. “What do you know about valence?” he asked.

“What’s ‘valence’?”

He proceeded to explain about electron clouds and the tendency of atoms to fill or empty their outer ring of electrons.

“So the valence of oxygen is 2.”

“Yes, except when it’s 1 or 4 or 6 or some other value. It’s not always simple.”

I’ve been thinking about that conversation since the end of the Agile 2011 Conference. Kevlin Henney gave a great keynote talk about, among other things, learning about code by reading successful code. “We’re not wired up to learn from failure.

Yes, that’s absolutely right.

Then Linda Rising gave her keynote (which I unfortunately missed, having to leave for the airport) where where exhorted us to learn from failure. “Try again. Fail again. Fail better! – Samuel Beckett

Yes, that’s true, too. How can I agree with two seemingly contradictory points?

That’s what made me think about my plans to invent the next-generation battery. Had I continued with those plans, I could have tried 10,000 combinations and been no nearer to success than when I started.

Yet Thomas Edison did invent a successful light bulb. After many failures, he was reported to say, “I have not failed 10,000 times. I have successfully found 10,000 ways that will not work.” If that was all he knew, then he’d have been little better off than I was with my battery. In fact, he’d learned more than he admitted.

During the course of those 10,000 experiments, he built up a model of what was needed and how various materials did and did not fit that model and supply those needs. If we’re paying attention and are very persistent, we can learn from most series of failures as long as each attempt varies from the others.
It’s just not very efficient that way.

We can turn a series of failures into a string of successes quite simply. Instead of expecting each attempt to produce a working light bulb or battery or whatever it is we want, expect each attempt to be an experiment that will teach us something and refine our model. A successful experiment is one that teaches, whether or not it confirms our expectations.

Looking at it that way, we’ll want to design better experiments to maximize the learning rather than trying to minimize the number of trials. This is the heart of “Fail better!”

by George Dinwiddie at 2011-08-31T11:06:07Z

James Shore

Let's Play TDD #134: Persistence!

31 Aug 2011 James Shore/Blog/Lets-Play

It's the one-year anniversary of Let's Play TDD! In celebration, new episodes are going up every day this week.

The source code for today's episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-08-31T08:01:00Z

August 30, 2011

James Shore

Let's Play TDD #133: Towards an Agile Architecture

30 Aug 2011 James Shore/Blog/Lets-Play

It's the one-year anniversary of Let's Play TDD! In celebration, new episodes are going up every day this week.

The source code for today's episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-08-30T08:01:00Z

August 29, 2011

James Shore

Let's Play TDD #132: Fresh Eyes on the Domain

29 Aug 2011 James Shore/Blog/Lets-Play

It's the one-year anniversary of Let's Play TDD! In celebration, new episodes are going up every day this week.

The source code for today's episode is available here. Visit the Let's Play archive for more episodes!

Esko Luontola has posted a video response to this episode. Find his response and my commentary in Episode 141.

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-08-29T08:01:00Z

August 25, 2011

James Shore

Let's Play TDD #131: JComponent vs. JPanel

25 Aug 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-08-25T08:01:00Z

August 24, 2011

Mark Levison

Books for newly minted Scrum Masters

imageYou’ve just finished your Scrum Master training and to start exploring some issues we didn’t have time to cover? I spent the afternoon putting together a list of 29 books that I think you will find interesting. As part of the process I decided to experiment with doing the list as a mind map.

Let me know if this was helpful or if there was a key book I missed. In addition give some ideas of how you might have presented this.

by Mark Levison at 2011-08-24T23:31:54Z

James Shore

Let's Play TDD #130: The Great Negative Color Debacle

24 Aug 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-08-24T08:01:00Z

August 22, 2011

George Dinwiddie

Hire a Coach, Not a Crutch

More and more, I see advertisements and hear people asking for a Coach to come for a period of time and help their organization on a full-time basis. They seem to assume that it’s necessary to Coach the team 5 days a week, every week. This makes little sense to me.

Teams need time to acclimate to new knowledge. They need to try it on their own, making decisions without immediate help. Otherwise they come to depend on the coach making the decisions, and they don’t learn how to make them, themselves. I’ve seen this happen when I’ve been working too steadily with one team.

It’s also important to limit the presentation of new information to the rate at which it can be absorbed. Time the team spends practicing without the presence of the coach is an important part of this absorption. Without such “soak time,” the team will get lost in the details, trying to climb the proficiency ladder without learning to practice the simple things fluently.

If you try to go faster than you can, you’ll only end up going slower.

by George Dinwiddie at 2011-08-22T13:56:30Z

August 19, 2011

Sammy Larbi

Pipe music through a Markov Model to generate new, similar music

emcee-3PO takes a text file of music, runs it through a Markov Model, and generates new music to be played with Archaeopteryx . It's an idea I've had for a while, which _why day gave me a good excuse to start. There's not much there yet -- the first sentence above tells you exactly what it does -- but I hope to add some features to it as time allows: Read from sheet music Use different instruments instead of simply playing the notes as written / make it symphonic Choose probabilities in some smart way to ...

by Sammy Larbi at 2011-08-19T22:46:33Z

August 18, 2011

James Shore

Let's Play TDD #129: Root Cause Analysis

18 Aug 2011 James Shore/Blog/Lets-Play

There's no source code for this episode, but the previous episode's code is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-08-18T08:01:00Z

August 16, 2011

George Dinwiddie

Home, again, from Agile 2011

It’s been a wonderful, busy week in Salt Lake City at the Agile 2011 Conference. It was great to see so many friends and to make new ones. I had an incredible number of fascinating conversations.

This weekend I was saddened, though not surprised, by the number of tweets with complaints about the conference, often tweeted by people who didn’t go. To paraphrase Yogi Berra

Nobody goes to the Agile Conference anymore. It’s too crowded.

It’s true that the Agile Conference doesn’t have a tight, narrow focus. It casts a wide net and is as inclusive as possible. This means that, no matter what your interest, it doesn’t concentrate on that. This means that it’s almost certain to have more interesting sessions than you can possibly attend. On top of that, there are many interesting conversations and side-sessions in Open Jam and in the hallways that are often worth as much or more than the sessions. It’s an embarrassment of riches.

I no longer worry about the things that I’m missing. Instead, I concentrate on the fact that my time there is bringing me value. I can’t optimize the value I receive, but I can use the “Law of Mobility” to get up and go somewhere else if I’m not getting enough value. This year, I found I rarely had to do that. Even when I wanted a bit of peace and quiet, I got sucked into valuable conversations. Even walking down the hall, I got sucked into Jim Shore and Arlo Belshee’s “Stages of Practice: the Agile Tech Tree.”

It was a conference of connecting ideas for me.  The Agile Tech Tree session tied right into the levels of proficiency from Willem Larsen’s “Fluency over Proficiency: Accelerating Agile Learning and ‘Hunting Fluency’.” Barbara Fredrickson’s keynote, ” Why Care about Positive Emotions?” contained many key points that dovetailed with my workshop on ” Team Swarming–Why and How.” (Those in my session know there were no slides, but I’ll be uploading the flipcharts we generated in the workshop. I’ve uploaded the flipcharts, as well as the slides I didn’t use.)

Yes, I missed many, many sessions that I would like to have seen. Sometimes I missed sessions not because of the conference design, but because of the limitations of my own body.

To be sure, there are things that could be improved about the conference. That’s always true. Every year, the current organizers hold a retrospective to notice things they want to change, or continue, in the next year. As Linda Rising says, “We are all a work in process.” It’s futile to ever expect optimization of a system composed of people, though. And this conference is an extremely distributed work by many volunteers, some of whom are new to the process. There are a wide variety of goals among those who work to put on the conference. Far from being disappointed in its imperfections, I’m amazed at how it soars.

But now the conference is over and I’m back at home. There are many things I want to pursue while the ideas and passion are fresh. There are two ideas, especially, that I’d like to collaborate with others who have passion in the same area.

  • Applying the ideas and techniques from Willem Larsen’s Language Hunting to learning and training Agile concepts and techniques.
  • Exploring team swarming and collaborative team formation.

If you have passion and energy in these areas, please contact me, and let’s see where we can go with it. And if you want to stay in touch less energetically, sign up for my occasional email newsletter.

by George Dinwiddie at 2011-08-16T23:59:26Z

August 15, 2011

Simon Baker

Some thoughts on collaboration

“Alone we can do so little; together we can do so much.” - Helen KellerOver the years and in a number of different roles, I’ve participated in and been responsible for facilitating collaboration. And some other things that were meant to ...

2011-08-15T14:41:46Z

August 11, 2011

Sammy Larbi

WTFs by programming language repository on github

I was curious to see how many WTFs are in programmers' code and compare it across languages, so I wrote a script to figure it out using github as the source data. I couldn't figure out a way to do it using github's API , so I had to screen scrape the search instead . Therefore, as the markup on that page changes, it will break the script. But, you can fork it and fix it later if you'd like. Another caveat is that I used the search string 'a' to determine the total number of repositories for a language. If ...

by Sammy Larbi at 2011-08-11T15:57:54Z

August 04, 2011

James Shore

Ask Me Anything on Reddit

04 Aug 2011 James Shore/Blog

For the rest of the day today (Thursday, August 4th), I'm doing an AMA on Reddit. Come ask me anything!

Update: All done! Thanks to dfjones and keturn for participating.

Comments

2011-08-04T08:02:00Z

James Shore

August 11th at Agile 2011: "Agile Tech Tree" Workshop

04 Aug 2011 James Shore/Calendar

I'm helping Arlo Belshee out with his session on Agile engineering practices at Agile 2011. It's called "Stages of Practice: the Agile Tech Tree." I'm not entirely sure what Arlo has planned, but it's sure to be interesting and thought-provoking.

The Agile 2011 schedule entry is here. We'll be in the Murano room from 9:00 to 10:30 on Thursday. Here's the blurb:

There are many stages of practice for each practice. These are the details that get lost in most discussions. What does it mean to practice Continuous Integration, TDD, or Pairing? If you use a CI server, are you doing CI? That depends. The Civiliation games have a "Tech Tree" that show the hundreds of technologies available. They are broken into branches (sea exploration, flight, etc), with dependencies between the branches. We will build a similar tech tree for agile practices, showing how the agile practices interleave and how they change as you develop each branch further.

Comments

2011-08-04T08:01:00Z

August 11th at Agile 2011: "Slackers and Debtors" Hands-On Session

04 Aug 2011 James Shore/Calendar

I'm doing a neat hands-on activity at Agile 2011 called "Slackers and Debtors: Meet Commitments, Reduce Debt, and Improve Performance." It's a fun activity that illustrates how iteration velocity, technical debt, and iteration slack interact. Diana Larsen and I have used it in our Art of Agile Planning course for quite a while and it's always a hit.

The Agile 2011 schedule entry is here. I'll be in the Imperial Ballroom A from 3:30 to 5:00 on Thursday. Here's the blurb:

Does your team have trouble finishing its stories every iteration? Is your "done done" actually a "maybe maybe?" Are you constantly removing stories from your plan? If so, this session will help. We take a close look at the relationship between technical debt, velocity, and iteration slack. We teach you how to use slack to achieve a stable iteration velocity, increase team performance, and get your stories "done done" every time.

Comments

2011-08-04T08:01:00Z

August 03, 2011

James Shore

Rabu Schedule Now Available for Download

03 Aug 2011 James Shore/Blog/Rabu

A few months ago, I announced Rabu, a project focused on creating wonderful relationships between Agile teams and their customers. Today I'm proud to announce that our first tool, Rabu Schedule, is now available.

Rabu Schedule helps you delight your customers by telling them what will be done and when. It's interactive, so they can try out "what-if" scenarios and explore the schedule consequences of including or excluding various features. And as a command-line tool configured with a text file, it's easy to fit into your existing build automation.

I'm pretty excited about what we've achieved with Rabu Schedule, and this is only the beginning. Check it out and let me know what you think.

Comments

2011-08-03T08:00:00Z

August 02, 2011

James Shore

Let's Play TDD #128: 2^7

02 Aug 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-08-02T08:01:00Z

August 01, 2011

Sammy Larbi

Combatting merge fatigue in revision control rookies

When you first introduce someone to source control, things often go smoothly until the first time they have to merge conflicting changes. Then they wonder, What's the point of this? I thought it was supposed to be easy but it's a PITA. Two responses on how to combat this immediately come to mind. The first thing that can help in this situation is to ensure they aren't having to merge useless files. I'm thinking of files here like the CSS generated from SASS: they change frequently but the changes don't affect them one way or the other. (In this ...

by Sammy Larbi at 2011-08-01T14:12:44Z

July 28, 2011

George Dinwiddie

Specialized Skills

Whether we’re talking about revolutionary new web services, IT systems to automate internal procedures, or products to sell in boxes, there are many different sorts of things that need to be done. We need to envision the product, decide what’s required to be done, design it, build it, make sure it works, and put it into production where we can reap the benefits. Except in the smallest of circumstances, doing all of these things requires the work of multiple people. And, given that we need multiple people, and that we need a variety of skills, it’s natural that some people specialize in some thing and others specialize in different things.

But we can take that specialization too far. And if we over-specialize, then we do these different things in isolation. It’s like having a small box of crayons. Stamp with 6-color Crayon Box One person takes the red crayon, others orange, yellow, green, blue, and violet. With that, we try to create a glorious full-color work of art. It’s no surprise that’s hard to do.

Colors in the real world flow from one named color to another, without a discernible boundary. It’s a continuous spectrum credit: XKCD used under Creative Commons license to which we’ve given names at certain approximate points. You just can’t draw the world as we see it using only six crayons.

The typical corporate response is to add more crayons. credit: BenSpark used under Creative Commons license And more people to hold those crayons. And more delays caused by passing things from one person to another. And… we still don’t get the picture we want. The more people we have, and especially the more specialists, the harder it is to get a pleasing cohesive picture.

We Painting Palette don’t need to eliminate specialization, though. Just blur the boundaries a little. We can get the full-color rendition we want with our limited palette if we blend the colors where they meet.

Rather than pass the work from one type of the work to the next, let the people doing those different types of work work together. They might even swap colors with each other from time to time. Odds are, they’ll do a much better job at producing the picture you want.

by George Dinwiddie at 2011-07-28T21:51:24Z

James Shore

Let's Play TDD #127: Yearly Spending Field

28 Jul 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-07-28T08:01:00Z

July 27, 2011

George Dinwiddie

A Virtue of Imprecise Measurements

I’ve talked about The Importance of Precise Estimates. In that post, I said,

My advice is to

  • measure your progress
  • watch the trends
  • project the trends tentatively into the future

and relax.  It’ll work out the best it can.  False precision won’t make it any better.

Now I just read The Virtues of the Imprecisely Measured Self by Alex Knapp at Forbes. He tells the tale of a study in the journal Psychological Science April 2011 that indicates that precision, whether false or not, inhibits success.  Alex summarizes,

Precision can actually be the enemy of performance goals. To be sure, feedback is definitely a positive thing. But it appears that if you want to keep yourself motivated, it’s best to get a more generalized, imprecise feedback that lets you know you’re heading in the right direction, rather than the precise coordinates of where you are on the path.

It’s something to think about.

 

by George Dinwiddie at 2011-07-27T15:29:36Z

July 26, 2011

Sammy Larbi

Responding to the OPTIONS HTTP method request in Rails: Getting around the Same Origin Policy

I'm working on a website analytics tool, and in pursuit of that goal, I wanted to POST some data from a series of websites to the one that's doing the tracking. If you've tried to do that before, you've run afoul of the same origin policy , as I did, so you'll need to specify how your application handles Cross-Origin Resource Sharing . I won't go into all the details about why that is the case - for that you can read the Wikipedia links above. Instead, I'm going to show a short example of how I handled this in ...

by Sammy Larbi at 2011-07-26T19:51:22Z

James Shore

Let's Play TDD #126: Following Patterns

26 Jul 2011 James Shore/Blog/Lets-Play

There's no source code for this episode, but the previous episode's code is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-07-26T08:01:00Z

July 25, 2011

George Dinwiddie

Process Metrics

My good friend Jack Ganssle commented over at EETimes (also available on the TechOnline India site, with different comments) about my recent post on process standards.  In it, Jack cautions against relying on “a strong feeling that ‘things are better.’” He recommends using measurements to bring it back to the realm of engineering.

Bob Pease, analog engineer at National Semiconductor and writer at EDN Magazine, used to say, “when something seems funny, measure the amount of funny.” That’s easier done in the engineering domain than the people domain, of course.

These two simple guidelines will help:

1. Measure the things you really care about. Too many people collect numbers that are based on guesses or on indefinable units. If you’re measuring productivity, figure out a way to measure delivered, working features, not “story points” or other estimates. Jack gave an example where, to increase the number of circuit boards being produced, the technicians were not bothering to repair the boards that didn’t work. They were tossing them aside, creating a pile of waste inventory. In Jack’s example, the productivity measurement only measured part of what was desired.

2. Use measurements to illuminate, not as a goal. As Michael Bolton says, good metrics allow you to ask better questions. They don’t answer them. The productivity numbers mentioned above didn’t say how productive the workers were being, because it didn’t show the wasted inventory.

Measuring things is a great way to sharpen the observations. It’s still an observation, though. Sometimes you can observe things that you can’t measure. In that case of a “strong feeling of ‘things are better,’” you may not be able to measure how much better. But you can still ask the data question, “What have you seen or heard that makes you think things are better?”

Observations without measurements are still valuable.


In the course of writing this post, I’ve just discovered that Bob Pease died last month in an automobile accident. The world has lost a great analog engineer, and a man who eloquently cared about engineering.

by George Dinwiddie at 2011-07-25T18:05:31Z

July 21, 2011

James Shore

Let's Play TDD #125: The Cost Basis Field

21 Jul 2011 James Shore/Blog/Lets-Play

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

2011-07-21T08:01:00Z