patkua@work

The intersection of technology and leadership

Category: Lean (Page 2 of 3)

Thoughts On Øredev

November 17, 2010 / / 0 Comments

Last week Sweden’s Malmö hosted Øredev for the sixth time. I believe it attracted more than 1400 people, all with varying backgrounds and interests. Unsurprisingly, the majority of attendees turned out to be Swedish and Danish people (with Malmö very well connected to Denmark via their famous Baltic Ocean crossing train).

The Cultural Experiences
Being held in Sweden, the organising committee did well to treat us to some cultural delights including the Swedish sauna-Baltic Ocean run followed up by a delicious traditional fish meal). One of the organising members even welcomed us into their home for drinks before the speakers’ dinner where Glögg continued to keep the cold at bay. The difference of soaking raisins and almonds really surprised me. Malmö’s deputy mayor then welcomed us at their majestic townhall where all the speakers unanimously marvelled at the decadent surroundings. The meal stayed true to the region with first, a regional speciality, black soup (and yes, like black pudding, it has a very special ingredient) before following that up with a hearty roast goose meal and a spiced apple pudding for dessert.

Logistics and Organisation
The organisers impressed me with how smoothly the entire conference ran. Malmö’s Slagthuset (slaughterhouse) hosted the conference for the first time and although not all the spaces turned out ideal (with small walkways between some major rooms), I think it contributed to the friendliness and openness I discovered.

The organisers also did a fabulous job responding to attendee’s needs. For example, on Monday they moved a number of tutorials to warmer rooms after realising the strong draughts let in by workmen who still needed to complete their work. Another example is when they quickly disabled the authentication on the wi-fi when it proved to be another barrier to being connected. Unfortunately the wi-fi turned out to be a little bit flakier throughout the conference.

I also really enjoyed the evening entertainment that flowed into the venue rather than the “move to another location and lose people” approach several other conferences do. This helped to keep the conversation flowing (and we all love our flow!).

Topics
Øredev offered a huge variety of interesting topics with tracks covering mainstream languages such as Java/.Net, NoSQL, Agile & Lean, Collaboration, Patterns, Smart Phones and Architecture with lots of really interesting topics. I’d keep an eye out for their website and trawl the twitterverse (#oredev) for the interesting discussions.

The keynote presenters also turned out really well.

Dr Jeffrey Norris presented what he thought as agile values leading to mission critical success at NASA (Vision, Risk and Commitment) demonstrating through a “wow” 3D demonstration using the ARToolKit. He used the stories of famous inventors, particularly the rise of Graham Alexander Bell to emphasis these elements very effectively.

I saw John Seddon a few months ago and although I’d heard him present pretty much the same talk, appreciated his message was an important one that more people really needed to hear. I think there is great value in spreading his emphasis on holistic system thinking even further in the work that we do. Entertaining and very British, Seddon completed his keynote without leaning on any slides and to a very positive reaction from the audience.

I missed Henrik Kniberg‘s keynote so can’t really comment.

The final keynote came from Atari Corporation geek legend Nolan Bushnell envisaging what the next key software projects would be in the future. I think everyone enjoyed the talk simply because it was Nolan though I think wasn’t as executed as professionally as it could have been.

People to meet
One of the really great parts of Øredev was all the people around you. As one person put it, you could be talking to a person and then suddenly realise that they created X (where X = language, framework, tool, etc) or someone who wrote a lot of the blog entries that you’ve been reading. I think that the conference does a wonderful job of creating a really relaxed atmosphere for people to converse and the speakers are all really approachable and involved in all of the sessions as well.

I have to admit I also really appreciated the opportunities to connect to a number of fellow ThoughtWorks colleagues (both past and present) who I’d either not got a chance to meet, or hadn’t seen for a very long time. This is one of the consequences of working for a global consultancy – you get to communicate and build relationships for a distance yet rarely get to meet people face to face.

iPad observations
One huge point worth noting was the large role that the iPad played during this developer conference. Obviously, being fairly geeky I hadn’t expected so many of them yet it proved to be one of the best devices for capturing notes & particularly useful for reading and contributing tweets. Laptops lose out on both portability and, on average, a very so-so battery life.

Reading tweets to view session using the native iPad twitter client also worked really well without having to use the keyboard or mouse – this is where gestures and multi touch really shined.

My session
Chris Hedgate, organiser for the track on collaboration invited me to speak. Titled, “Tightening the Feedback Loop“, I spoke about how to give and receive more effective interpersonal feedback. I had some great tweets in response and some great feedback on the presentation (meta!) I’m encouraged that more people will be better equipped in their professional and personal life after attending.

Conclusion
I highly recommend presenting and/or attending Oredev. You’ll meet a whole heap of really interesting people and, no doubt, come away with at least an idea or two.

Kaikaku or Kaizen

February 13, 2010 / / 3 Comments

I hear about two major approaches to introducing agile methods to organisations. Kaikaku (known in lean circles as radical change) is the brute force method of pushing all the change you want upon the organisation. You recognise this when basically the “normal” way of working is flipped on its head and a whole swarm of new practices are introduced.

Kaizen (known in lean circles as continuous improvement) is the softer, gentler approach to change, tweaking one bit here, and one bit there. Think of this as a way of introducing a single practice a time.

Now that we are clear about what is what, comes the interesting question of what is better?

You seem to be faced with two choices. A radical change that seems like a high chance of failure, but could also be a huge success, or smaller incremental change to do this.

In order to answer this question when I join a new team or organisation I like to consider how much their environment supports them in what they want to do. Those with supporting, nurturing or safe environments I would probably head towards Kaikaku, using education and building trust with senior stakeholders to establish longer term safety. You can increase safety and reduce the likelihood of failure if you can bring in a high proportion of the culture you’re looking for. I’ve seen this succeed really well when you have at least 50% of a team with lots of agile experience, something you tend to have when you hire someone like ThoughtWorks.

Work with less than 50% experience mixed support, and you start to decrease safety. At this point, I would start to look towards kaizen methods of improvement. Of course there are many levels at which you might apply kaizen and kaikaku, but consider safety levels when doing so.

You can’t measure everything effectively

January 6, 2010 / / 8 Comments

Definitely agree with this from the 10 Things I Wish Lean Practitioners Wouldn’t Say in 2010 (via the Lean Blog):

7. “If you can’t measure it, you can’t manage it.”

I don’t believe that statement. I think this phrase should be avoided and it certainly shouldn’t be attributed to Dr. W. Edwards Deming, as it often is mistakenly. Dr. Deming never said this and he, in fact, meant quite the opposite. Some of the most important factors in a system are very difficult, even impossible, to measure. That doesn’t mean you can’t try to manage them. John Hunter, friend and fellow blogger, has the definitive take definitive blog take on this here…

Don’t get me wrong. Metrics are important but they aren’t always most important.

Consequences of Hiding Information

October 5, 2009 / / 2 Comments

Last week reminded me how hard communication is to get right. Last week reminded me of how important it is to be visible with information as early as possible. Last week reminded me of what happens with the people involved don’t have access to information early.

Successful teams applying agile principles quickly involve those impacted by the situation, equipping them with as much information as early as possible. These teams call upon agile practices such as daily stand up meetings, retrospectives, and frequent showcases to achieve this. Better and earlier access to information helps all parties involved come up with more options. More options creates more opportunities to have better conversations, and more opportunities to collaborate to meet everyone’s needs, and ultimately end up with a solution that everyone is more likely to feel committed to.

Compare this to those teams who hoard information, selecting and filtering the information others hear. Filtering and transforming information limits the number of options, often adding additional stress because the team now how to come up with the perfect option. Even with contributions from others, the pool of options will often be tainted by solutions not entirely appropriate or relevant. More importantly, if the people affected by a decision aren’t involved, they will end up less committed to the solution and often, cause more problems because of resentment.

No one likes to be handed decisions. That’s why the Agile Manifesto emphasises “Individuals and Interactions”, and a key principle of Lean Thinking is “Respect for People”.

The moral? Remember to involve the appropriate people in the decision making process as early as possible. Even if you suspect there is only going to be one solution, be transparent with the information you do have in the hope you may end up with more options, or at least, the outcome is no surprise.

XTC Turns 10

August 12, 2009 / / 0 Comments

I’m fortunate enough to have recently started back on a project in London* this week. One of the many things that I’ve missed working in London has been access to the variety of communities that you have access to that no other city in the world (even New York City) could ever match. One of the longest running and, and without doubt most influential, on the agile community in the UK is the eXtreme Tuesday Club who celebrated their 10th year of running weekly meet ups in London.

I always find the people there great to talk to and interestingly enough this week there were significantly many more agile coaches than I’ve seen in one place for a while. I hope to be able attend these sorts of gatherings much more frequently now that I’m back in London and would highly recommend this one to any one who happens to be in town on a Tuesday.

XP2009 Day 2

June 3, 2009 / / 0 Comments

Thoughts about the second day
Ivar Jacobson gave an equally uninspiring keynote, talking about “What they don’t teach you about software at school: Be Smart!” In it, he focuses on the fact that it’s not only enough to try to “Be Agile”, but you need to “Be Smart”. Unfortunately many of the items that he talked about didn’t really seem to be any different from “Being Agile” and that he had obviously targeted the wrong audience.

I’m glad the conference ran with an open space session, this year introduced by Willem Van Den Ende and Lasse Koskela. I suggested a topic titled, “The Kanban, Lean, Agile Divide” and I felt we had the best quality discussions during this open space. I wanted to answer a number of questions including:

  • Did people know about the Kanban Community?
  • How active were people in that community?
  • Did people perceive a divide?
  • And if so, why?

Out of around the 12 people participating, probably only two or three hadn’t heard about the community, and only one or two people were active in participating (in the mailing list portions). We had lots of discussion as to what people considered as Kanban as well.

kanban

First page of notes from the open space session

We noted down the mailing list, available on Yahoo Groups: Kanban-Dev and several “published” resources including the paper, Kanban Vs Scrum, and the book, Scrumban.

When asked about what Kanban was the participants, here’s what we recorded:

  • Elements of one piece flow (particularly limits to WIP or Work In Progress). Translated into practical terms, it meant focusing on one story at a time (as a team or as a pair)
  • Kanban was an alternative scheduling technique
  • Unprescriptive, or less prescriptive (relying on other practices to help out)
  • Constantly evolving
  • “Good for maintenance”
  • Most people considered Kanban a “Practice more than a methodology”, though there was general agreement that some people are trying to turn it into more than that
  • Focused on delivering “Minimal Marketable Features”
  • Quote from Tom Poppendieck, “Scheduling and Workflow are orthogonal”. We expanded upon this for a bit and a more concrete example is you can use different scheduling techniques such as Kanban or Timeboxes with the same workflow such as a simple, “To Do, In Progress, Done” workflow.

I recorded that some people were still doing sprint/iteration planning whilst using Kanban though I don’t remember if we got into the details.

I also recorded two concerns, such as knowing, “When do we get stuff done?” and a very “Loose Terminology” leading to lots of confusion, particularly the overloaded associate with Kanban (as a practice) and Kanban (as a methodology).

When asking the question, “Is there a kanban divide?” some answers included, there is maybe a divide in a community sense, and when probing further, when interpreting Kanban as a practice, not a methodology there wasn’t however there was definitely a sense when treating Kanban as a methodology and not as the practice with a feeling that some people in the community wanted to make money.

kanban2

Last page of notes from the open space session

We asked why the community divide and understandably, there was no real community around to openly discuss Kanban (as a practice) and felt similar to those that had been around during the XP early days. There didn’t seem to be any general list for “agile practices” with extremeprogramming and scrum-dev mailing lists. It’s also not the first time practices have had their own list, like the pairprogramming or the test-driven-development lists. We did note down that there were several potential ones the community could have joined including lean-agile, lean-dev instead of creating their own kanban-dev.

In the afternoon, I went along to the panel on Lean Software Development although I seemed to come away with the same questions and less answers. One of my questions about budgeting was answered by the next morning’s keynote, while another focusing around the lack of discussion around practices seemed to be dismissed by Mary Poppendieck as, “I don’t believe in practices”, maybe best surmised as, “I don’t know” (which I would have also been happy to take).

The evening was an impromptu beach BBQ held by the awesome folks at Agical. Whilst a small company, I’m glad to see them still as passionate and having grown year upon year with more enthusiasm about a huge variety of topics. The BBQ was amazing and I know that everyone had a great time.

More to come…

XP2009 Day 1

June 1, 2009 / / 0 Comments

General impressions about the conference
I really enjoyed this year’s conference with the combination of a remote island in Italy and the small numbers (100+) giving many great opportunities for chatting with our experienced practitioners, and a handful of academics about lots of different topics. I found it refreshing that there seemed to be significantly more experienced practitioners and thus, I found it extremely nice to be able to chat about similar experiences rather than simply unidirectional advice I find when present with a higher proportion of beginners.

conferencepool

Who wouldn’t want to gather around this place for some great conversations?

The quality of sesions was better than the last two conferences, once again focused less on the introductory nature and more focused on specific aspects. Of course, I had recommendations about how to improve, particularly the organisational aspects, of the conference and I’ve at least had an opportunity to give that feedback having shared a return train with one of the organisers for next year’s conference.

Thoughts about the first day
The first part of this day was a keynote delivered by lean evangelist, Mary Poppendieck. Titled, “The Cultural Assumptions behind Agile Software Development”, Mary proposed that there are several (American-style) cultural assumptions behind many of the agile practices that make it all the more difficult to implement. She referenced heavily the work discussed by Geert Hofsted in his book, Cultural Dimensions.

I didn’t find the keynote particularly inspiring, nor particularly challenging. Country-based cultural dimensions are just one of the factors that permeate the way that people behave. As an agile consultant, you end up fighting corporate culture, and the systems that encourage and maintain that corporate culture and I see country-based cultural dimensions yet another contributing systemic effect. This does not mean that just because a country has a high degree of individualism, working in pairs or working collaboratively in a team will be impossible (perhaps just all the more difficult). As much as I enjoy hearing Mary speak, I also found her presentation a little bit too heavy in the whole powerpoint presentation with far too much text and outdated clipart.

I also ran my workshop in the morning, titled “Climbing the Dreyfus Ladder of Agile Practices” and want to thank all the experienced people that attended as it resulted in some really rich discussions. We managed to discuss seven different agile practices in detail, brainstormed a large set of behaviours for each, classifying them and classifying them into the different levels described the the Dreyfus Model of Skills Acquisition. The results from the workshop can be found here (photos to be updated).

In the afternoon, I helped out Emily Bache’s coding dojo, focused on Test Driven Development. We saw four different pairs tackling four different coding problems using different tools and languages. I learned about the tool JDave (it’s still a little bit too verbose for my liking), and saw different styles in the way that people executed the code kata. For me, I was hoping to demonstrate more on the pair programming side of test driven development as a pair, and I had a lot of fun even though I felt a little bit out of my depth with the tools. Thanks to Danilo for complementing my lack of experience with tools like Cucumber. 🙂

More to come…

Experimentation and Learning lead to Ford’s production line insight

March 22, 2009 / / 1 Comment

I find it slightly ironic how the learning and experimenting philosophy so heavily emphasised in the lean world ultimately produced, what is considered the opposite approach inspired by the Ford production line.

“…when Henry Ford and his team developed the production line, they didn’t just sit down and deductively theorize about it on paper. nor did they merely try random experiments. Instead, they used a bit of both. … Armed with a set of deductive hypotheses, Ford began experimenting with different configurations of his plant between 1908 and 1912. After four years of tinkering, in 1913 he struck on the key insight that the car itself should move along the production line rather than the workers…” – From Chapter 12 of the Origins of Wealth by Eric D Beinhocker.

Practicing Root Cause Analysis: An example for programmers

January 28, 2009 / / 1 Comment

Adding complexity in code is easy. Removing it often takes a little bit more effort. Using root cause analysis, we can sometimes remove this unneeded complexity. Here’s an example my pair and I went through today.

Me: Why is this test breaking?
Pair: Because we have to specify a different value than that one.

Me: Why do we have to a specify a different value than that one?
Pair: Because we have different values in this configuration file for tests.

Me: Why do we have different values in the configuration file for tests?
Pair: So that we can bind services to a different name?

Me: Why do we want to bind services to a different name? (since we have a contract with our clients that never change)
Pair: I’m not so sure… Let’s ask our BA.

Me (to the BA): Why do we want to bind services to a different name?
BA: I don’t know. (Thinks about it for a while…) I don’t think we would.

Now knowing that we wouldn’t ever deploy our application with a different configuration, we got to delete a whole lot of code, and an unnecessarily complicated configuration file. Awesome!

Estimates degrade over time

January 15, 2009 / / 7 Comments

Project management is a funny thing. It seems like once something is converted into a number, the number is often all that matters to traditional schools of project management. Plans get created, promises get made, yet little diligence goes into ensuring the number is based on sound thinking, and that the basis for that number remains correct. Maybe that also explains the state of the current banking industry, though that’s another post entirely.

Most people fail to understand that estimates have a half life, and often a very short one. Even results produced with agile estimation techniques, have an expiry date that is often ignored. Magic numbers (aka, the estimates) have an expiry date because in order for them to be even slightly reasonable, they need assumptions to be made, and it is often these assumptions that expire. Gantt charts are awful at highlighting what those assumptions are, let alone tracking when they fail to be met.

burntnumbers
Image of burnt numbers provided by Dead Scene under the Creative Commons licence

A recommended practice for agile estimation is to get the people who are going to do the work, to estimate. Put these estimates on a shelf to ripen for a year and, presto, you have a new team to which, the original estimates no longer apply. Even given the same team, set to work on something else only to return to the system, will have lost some flow, forgotten some things and need more time than if they just continued to work on the same system. Environments often change, and the underlying needs for the business change even more frequently.

What can we do about it? I refer to Lean Software Development’s principle of the Last Responsible Moment, to not only make decisions, but when collecting (and keeping) estimates. Collect estimates now if it helps you make a better decision, discarding the estimates if you choose not to immediately implement the project. You set yourself up for failure if you choose to estimate now, knowing that the project is to be shelved for “only three” months and keeping those numbers as if they are in any way relevant. If you don’t need to make a decision now, work out when you need to make the decision and defer collecting estimates until just before then.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑