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...
[...] more and from Mark Levison: http://agilepainrelief.com/notesfromatooluser Be Sociable, Share! Tweet(function() {var s = document.createElement('SCRIPT'), s1 = [...]
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.
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.
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.
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.
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.
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.
Part 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:
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:
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:
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
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.
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
When 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:
The team can do a number of things:
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
| 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.
| 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.
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.
| 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.
| 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.
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.
Caveat – 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.
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.
What are the team’s options?
| 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.
| 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.
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)
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:
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.
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.
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.
Last 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.
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:
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:
For the next sprint they identified several improvements they could make:
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 Size | Limit on # of Stories in Progress |
| 5 | 2 |
| 6 | 3 |
| 7 | 3 |
| 8 | 4 |
| 9 | 4 |
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
| M | T | W | T | F | M | T | W | T | F | |
| Development | 27 | 27 | 27 | 27 | 27 | 27 | 27 | 14 | 9 | 9 |
| QA | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 13 | 18 | 9 |
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?
| 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.
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.
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
| 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.
| 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.
| 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.
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!”
| 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.
| 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.
| 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.
| 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.
You’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.
| 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.
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.
| 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.
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.
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.
| 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.
| 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.
| 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.
| 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.
| 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.
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. 
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 
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. 
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 
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.
| 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.
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.
| 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.
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.
| 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.