The Culture Game – Book Review

Dan Mezick has written an intriguing new book: The Culture Game: Tools for the Agile ManagerTCG-flat-medium-300x229.jpg

The Culture Game is a book to give Agile Leaders[1] a tool to help change the culture of their companies. It is intended to help organizations that aren’t ready to adopt something as radical as Scrum or that want help in speeding up the cultural change that Scrum requires.

Taking a leaf out of Dan’s book – the review will be written using the Perfection Game. The Perfection Game is one the Core Protocols that Dan mentions in Part 2 of the book. In the Perfection Game – you give a numeric rating and state what you like and what it would take to make it perfect.

I rate the book 8 out of 10. Read More…

Be Sociable, Share!
Comments { 2 }

ScrumMaster Tales–Stop Digging New Holes

First Law of Holes is Stop Digging

Scrum Team digging a hole

The first law of holes is “When you’re in one stop digging”. In the last sprint the team discovered that they’re in a hole – in this case they had dug themselves into technical debt.

We join the team this week in their Sprint Planning session, they start by rechecking their Retrospective action items:

  • Respect the “Definition of Done” – write Unit Tests (their complete “Definition of Done): Checked In, Peer Reviewed, Unit Tested, Manually Tested)
  • Temporarily add Unit Test column to their story board
  • Install Sonar (a platform to help visualize Code Quality) to help improve awareness of Code Quality and Technical Debt
  • Spend 20% of their time in the next couple of Sprints to tackle Technical Debt Issues (Ed note: From experience this seems a bit low for team that have accumulated a fair amount of technical debt, but the team will have to learn on their own)

They start by discounting their historical velocity (currently at ~20 Story points) by 20% to account for paying down the Technical Debt (16 Story Points). Then they recheck the “Definition of Done” for each story they’re about to commit to. At this stage Product Owner Sue pipes up to protest that all this focus on technical debt doesn’t help her get features out the door. She’s concerned the CEO will banging on her door soon. Doug explains that if the team doesn’t start to tackle the technical debt now the delivery of new features will slow down even more, while the bug count rises. He explains that the next 3-4 sprints will be rough the situation needs to stabilised (Ed: He’s optimistic) . ScrumMaster John reminds Sue that she is responsible for the product that the team delivers. In turn the team is responsible for deciding how much they can deliver and for ensuring its quality. Sue raises the flag of surrender but says she is really concerned and wants to revisit this two sprints from now. Read More…

Be Sociable, Share!
Comments { 2 }

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.

Be Sociable, Share!
Comments { 9 }

Relationships Made Easy

For several years I’ve been trying I’ve been trying to find a Neuro-Linguistic Programming (NLP) book that provided a simple and clear explanation of what it is and how it works. With “Relationships Made Easy for the Business Professional” – Dr David Fraser scores well on the first and not as well on the second.

The book’s strength comes from David’s practical business background which he uses to ground his writing and examples. The book fails when its attempting to explain how NLP works.

David describes a 12 step process to help

  1. Attention to others
  2. Attitude
  3. Self-control
  4. Wavelength
  5. Filters
  6. Connection
  7. Values
  8. Language
  9. Self-awareness
  10. Attention to yourself
  11. Balance
  12. Love Read More…
Be Sociable, Share!
Comments { 2 }

Guest Post: Jurgen Appelo “The Fear of Uncertainty”

This article is an adaptation from a text out of the book “Management 3.0: Leading Agile Developers, Developing Agile Leaders,” by Jurgen Appelo. The book will be published by Addison-Wesley, in Mike Cohn’s Signature Series, and will be available in book stores near the end of 2010.

My partner and I once went to Cuba, where we unexpectedly visited a famous tobacco plantation. This happened because we had picked up a young hiker who turned out to be one of the workers at the plantation. But we had done so reluctantly, and a bit scared, because travelers are regularly warned not to take any hikers for a ride. Two years earlier, one of my best friends was robbed of all her personal belongings after picking up hikers in Cuba. It shows that, as a traveler, you have to be able to deal with uncertainty. Picking up hikers can get you either robbed or rewarded. How can you tell the difference in advance?

In Complexity: A Guided Tour , Melanie Mitchell explains that two important factors contribute to the crucial role of uncertainty in complex systems [Mitchell 2009:20]. The first is Heisenberg’s Uncertainty Principle[1]. It states that certain physical properties of elementary particles, like position and momentum, cannot be known at the same time. The more precisely one knows a particle’s position, the less precisely one knows its momentum, and vice versa. The Uncertainty Principle shows there’s a pattern of uncertainty woven into the fabric of reality. This would only have been a mildly interesting statistical oddity, if it weren’t for the second factor: the Butterfly Effect.

The Butterfly Effect[2], usually attributed to Edward Lorenz, is a metaphor for the sensitivity of a system to (uncertainty in its) initial conditions. It is said that the flapping of a butterfly’s wings in China could, theoretically, cause a thunderstorm in the United States. I’ve noticed that the metaphor is cited in many books on chaos and complexity theory. And sometimes the butterfly is in China, sometimes in India, sometimes in Brazil. But, strangely enough, the thunderstorms always end up in the United States. It made me wonder if chaos theorists have uncovered a global network of terrorist butterflies trying to aim thunderstorms at the U.S. (During our vacation in Cuba we actually got to experience a hurricane passing over the island. And I could verify that it was indeed heading for Florida. From its trajectory I estimated the butterfly to have been located on the Dutch island of Aruba.)

We must accept that our business landscape in the 21st century is as uncertain as it is complex. And it’s not getting any easier. However, uncertainty may be natural, but for many people it’s not welcome. It is certainty and safety what they hope to see in their future. And attempts at achieving certainty can lead to decision paralysis [Heath 2007:34-37]. We don’t know what to decide, because we are not certain of the outcome. Do we implement a scalable architecture now or later? Should we use Html/JQuery or Silverlight for our front-end development? Shall we pick up the hiker or not? Will we end up at a cigar factory, or at a police station?

When people are finally brave enough to make a decision they often favor risk avoidance over opportunity seeking. They look at uncertainty as something that is more likely to have a negative outcome than a positive one. (Or they estimate the cost of potential problems to be greater than the benefit of positive outcomes.) A good example is the often cited “threat” of non-native species being transported by humans from one ecosystem to another. Many environmentalists are actively trying to address this “threat.” But research has shown that only in a few percent of the cases non-native species had a significant and bad effect on existing ecosystems [Davis 2009:26]. In most other cases, the effects of “alien” species on native ecosystems were neutral, or even positive. (It is interesting to note that the honeybee is the official symbol of several states in the U.S., but it is a non-native species because it was introduced in North America from Europe in the 1600s. Perhaps the bees got there with a thunderstorm.)

Uncertainty is found in the tiniest parts of reality, and the sensitivity of complex systems to uncertainty can have far-reaching consequences. Fear of this uncertainty is common, understandable, and sometimes even necessary. But we should not allow it to turn into fear of change itself.


[1]http://en.wikipedia.org/wiki/Uncertainty_principle

[2] http://en.wikipedia.org/wiki/Butterfly_effect

References

  • Davis, Mark. “Living with aliens” NewScientist. 26 September 2009
  • Heath, Chip and Dan Heath. Made to Stick. New York: Random House, 2007.
  • Mitchell, Melanie. Complexity. City: Oxford U Pr, N Y, 2009.
Be Sociable, Share!
Comments Off

Quick Agile Links

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

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

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

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

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

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

Be Sociable, Share!
Comments Off

Learning Best Approaches for your Brain Slide Deck

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

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

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

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

Benefits:

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

References:

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

Download: Slide Deck (pdf)

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

Be Sociable, Share!
Comments { 3 }

Coaching Workshop

IMG_0299-3

Yesterday (Monday), Liz Sedley and Rachel Davies ran a coaching workshop “What Does an Agile Coach Do?” that helped me spot several things I just never think to pay attention to. From Richard Hackman’s book Leading Teams: Setting the Stage for Great Performances (which they highly recommend), they provided a number of observations. First, we should recognize that there is distinction between a Leader and a Coach. A Leader is part of the team whereas a Coach shouldn’t be part of the team and must set the stage for the day they leave.

Hackman identifies three types of coaching intervention and three opportunities to use those interventions effectively.

Types:

  • Educational – improve the teams understanding/knowledge
  • Consultative – improve the teams process/actions
  • Motivational – improve the teams effort

And then three opportunities to use these interventions most effectively:

  • Beginning – Motivational
  • Middle – Consultative
  • End – Educational

Like Paul King, I found this counterintuitive at first until they suggested that we think of this as the iteration and not the release level. At the start of the iteration, we provide the team with the motivational push to help them get the most done. In the middle of the iteration, we can provide guidance and offer suggestions to improve the flow and progress. At the end of the iteration, we reflect and find ways of learning from what happened. Each table was given a number of problem scenarios, and we were asked what would we do. After describing what we would do, we were asked to classify each intervention as Educational, Consultative, Motivational, or some other label. Again, like Paul, it quickly became obvious that I do very little in the way of motivational intervention. In addition, I spend a lot of my Educational efforts at moments when the team is less receptive, resulting in their being less effective.

In addition, I discovered a few other interesting things:

  • Breathe, Pause, Wait—don’t act in the heat of the moment. Instead, relax and assess what tool will suit your needs best.
  • Ask questions and understand not just the what but also the why as to how the situation ended up the way it did in the first place. Intervene only when you understand the whole situation, especially the history.

Finally, Liz Sedley told me to not ask why many people will take “why” as an attack and go on the defensive. Instead ask “how” and “what” questions. The exception, of course, is doing root cause analysis (i.e., 5 why’s), and in that case you should explain what you’re doing.

Along with Richard’s book, I’ve also received several recommendations for books on Systems Thinking: Bas Vodde and Craig Larman’s book Scaling Lean & Agile Development, which apparently contains a good chapter on Systems Thinking, and Peter Senge’s The Fifth Discipline: The Art & Practice of The Learning Organization. I’ve often heard of this book but never knew that the Fifth Discipline was Systems Thinking (thanks Declan).

Other blog posts I’ve spotted from Monday include: Giving and Receiving Effective Feedback (my writing on InfoQ), Paul King’s Counter-intuitive Agile Coaching Tips (also from this workshop), Masti, Co-Creator, Pair vs. Review, Agile Games – Agile 2009, Day 1 , FitNesse vs. Robot Framework – Agile Testing Tools , and A conversation with Neal Ford.

Be Sociable, Share!
Comments { 1 }

Discovery De-Mystified

In "The Myth of Discovery" Ted Neward complains that the software industry is unwilling to look beyond its bounds for new ideas and innovation. What surprises me is how little evidence he offers. In column against the software industry he cites only: Jeff Palermo's essay on "The Myth of Self-Organizing Teams" (an item I mostly agree with).

Oddly Ted offers evidence from the Agile community suggesting we do borrow ideas – citing Mary and Tom Poppendieck and their refinement of Lean ideas for software development. In this case his problem is that development managers/project leads aren't yet given the opportunity to say a product won't ship because the quality isn't there. Well I understand where he's coming from, but it seems like a mis-understanding of Lean/Agile principals which focus on building the quality in – not refusing to ship because the quality isn't there.

In any case I think that more people than Ted acknowledges, do their research outside of the software industry. Some examples:

Read More…

Be Sociable, Share!
Comments Off

Best Agile Books 2007 Development/Code Related

The third and final my Best Agile Books the 2007 Edition series. (Part II was Background Material). There will be even fewer notes than there were in yesterday's. It really has been a long week.

Development/Code Related 

Working Effectively with Legacy Code by Michael Feathers – Do you have legacy code? Does your code include areas that are untested and tightly coupled? Yes? Then you have legacy code. Michael focuses on the problem of teasing apart legacy

Refactoring: Improving the Design of Existing Code by Martin Fowler et al – One of the original Agile related books. It defines the concept of refactoring (personal bugbear – refactorings are small changes that don't affect the behavior of the code), explains how to practice it and catalogs over 70 refactorings. 

Test Driven Development by Kent Beck – The original TDD book. Clean, bug free, simple code. That is the promise of TDD. Its that simple nothing more to say. BTW the examples are in C# so some of the details won't apply to Java/Ruby/Python coders.

Late Breaking news: J.B. Rainsberger introduced me to: Test Driven: TDD and Acceptance TDD for Java Developers by Lasse Koskela. I'm only about 120 pages in, but so far am very impressed. Its even caused me to change a few of my habits – specifically which test I choose to write first.

Another Late Breaking item – Robin Dymond gave this one a very strong recommendation: xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. I've not read this yet – but Gerard covers Test Smells and Refactoring. In other words how to spot trouble your test code and repair the damage.

Refactoring to Patterns by Joshua Kerievsky. Have mess, want to bring some order to it.

Head First Design Patterns by Elisabeth Freeman (et al). I struggled through the Original GOF Design Patterns book twelve years ago now. Thankfully Elisabeth and co. wrote a funny, irreverent and so you don't have to.

What are your favorite Agile Books? 

Coming up posts on: Iteration Length (another lesson learned that I didn't think of in my original post) and Pair Programming vs. Code Reviews a rebuttal.

Be Sociable, Share!
Comments { 2 }
Page 1 of 212