Thursday, March 27, 2008

Western Manufacturing - No Toyota Way ... I Assume

I love real stories so I have to share this one with you.

I ordered a module sofa few weeks back and yesterday I finally got it. After I got rid of the packaging I noticed that the pieces were wrong (or that the sofa would be more modern than expected ;) ).



I wonder what would happen if the manufacturer would use one-piece-flow instead of mass production including inventories. At some point of the flow someone would go "hmm, something is probably wrong here ... either the order is wrong or our flow is broken". What happened here (most probably) was that some guy got the first piece of sofa and then some other guy got the second one and yet another guy (or two?) packaged it all. No communication happened in between so end result is X weeks of wasted production time (+ rework), unsatisfied customer and no improvement to manufacturers processes (lack of kaizen, maybe).

Anyway I am happy with the quality of materials and wishing to get the sofa soon.

Thursday, March 6, 2008

Common Scrum Pitfalls - self-organizing teams taken to extreme

This time I am introducing yet another pitfall that is probably the most "managerial" so far: Self-Organizing Teams Taken to Extreme. I have seen it happening in some Scrum implementations so far so probably it is a "common" pitfall - leave a comment if you have experience about similar problem :)

Anyway, it is very common that software company is having a organization structure following the Conway's Law. I have been part of these companies and seen them trying to implement Scrum. Here's what happens according to my experience:

  1. One team is chosen to be a pilot team for Scrum, this team is a "architectural layer" in the product, usually something like "core" or "platform" team (as they are usually most experienced engineers in the house)
  2. Team tries to implement Scrum, they wonder why their velocity is not getting stable (even the Book says that it should after few sprints).
  3. The team realizes that the velocity is not getting stable cause they are not in full control - they are impeded a lot by other teams (like database team that is underlying in their architecture, or client team which is on top of them).
  4. They raise the issues to the organization as they feel that fixing all the dependencies is out of their hands and should be handled by the organization instead. Usually a issue is that other teams are doing waterfall and do not have enough information (as their project is in "requirement gathering phase") to support the one and only Scrum team.
  5. The organization follows the Book and wonders "what happened to the self-organizing team". The organization rejects to lead and facilitate and tells the team to "go and figure it out". Cross-functionality is not approved as the original goal was to do "pilot first" to see if Scrum works. (Yeah yeah, they are breaking one of the rules of Scrum: cross-functional teams... but hey, they started from Conway's Law, what do you expect)
  6. One of the following happens:
    1. Team turns to anti-Scrum, they do not like it as it just brings all the problems to them and makes them endless problem-solving task force
    2. Organization drops Scrum - "It does not work for us"
    3. Team starts hating organization - "Organization does not support us"
    4. ..
So how to avoid this pitfall? Simple, when you are piloting or trying out Scrum, do it with cross-functional (truly) team. If you are not able to do that, try it with traditional team but pay attention that this is an issue that you will face. If you do not face it, then somebody is hiding something.

One more note, as a manager do not ask the team to go and figure everything out - they may do it, but you will not have transparency anymore as the team does everything under the hood. Impediment should be raised when team faces problems that are created by organizational boundaries. I have seen teams applying "Go and See" (Toyota Way) and fixing everything ... and over a time totally lost their focus as they do not know anymore what is their responsibility and thus not raising anymore impediments. This may or may not be real life example:

Development team was asked to develop a piece of software and "put it in production". The team maintaining the production system was not involved and they were "too busy" to support the development team so the development team (as result of self-organizing) bought their own hardware, setup "production like" environment and started operating that as "production environment". All this, without the "production system team" knowing anything about it.

Imagine what would be the result of doing this with several development teams - you would have as many "production systems" as you have development teams. Ouch.

Anyway, pay attention to your Scrummers ... till next time.

Tuesday, March 4, 2008

Exercising TDD with a Scrum team

Quite recently I was in charge of TDD exercise for a Scrum team at my customer. Some team members had quite extensive experience about TDD, some didn't have any experience at all. I find the setting pretty interesting and eventually the exercise turned out to be more about team building than about TDD.

Every developer has their view about development cycle (coding, compiling, testing etc) and people tend to stick their own way - even when told to try something different. Here is my setup for the exercise:

Goal

Team to learn apply TDD

Duration

2 days

Preparations


  • Reserve a laptop with empty Eclipse project, JUnit configured
  • Reserve a meeting room for the days
  • Team available for the days
  • Material for exercise

Execution


  • Marko will give the exercise and answer any questions about the problem at hand (10 minutes)
  • 2 developers will pair at the laptop, rest of the developers will review the implementation all the time
  • We will check up the status every hour together, we can change the pairs if team is feeling so

Rules


  • Implementation pair will all the time say out loud what they are about to do and then do it, THINK OUT LOUD
  • Do The Simplest Thing That Could Possibly Work
  • Everything MUST be implemented test-first
  • Remember You Aint Gonna Need It
  • No more than 10 minutes design allowed (whiteboard)
  • Reviewers can only ask question "Why are you implementing it like that?" or similar, reviewers cannot tell what the implementing pair must do, decisions are done at the laptop


Changing pairs early on really helped as less experienced TDDers saw the more experienced TDDers in action. Team felt exhausted after the first day and there were some questions in the air about productivity of the approach compared to other approaches.

Second day was a bit different. Tests were slowing developers down and design issues became obvious. Parts that were not refactored early on started bugging developers so atleast one of the goals were achieved: team noticing that refactoring is a must. Another interesting finding for the team was that the pragmatic approach of "not thinking too much of a head in the implementation itself" requires great discipline in planning the tests in first place. Soon team started questioning themselves: "So what should I test exactly and why" before coding anything at all.

Sometimes team found themselves stuck on algorithm design and we had to call timeout every now and then. I think it is very important to have the facilitator telling the team that "now the time is up, lets try to test first, code and then see if the design is good - if not, then we atleast know a bit more about the problem".

After the second day we had some working software and every team member had tried to do TDD. Some members had questions still about the productivity but everyone agreed that TDD with merciless refactoring can lead to good designs (once you also do "refactoring in the large" at whiteboard). However, doing good test cases is hard for beginners as they probably are not too much familiar with mocking nor thinking test-first.

Interesting exercise - I as a coach learned also quite a bit how to improve guidance and handle different people during the exercise - we are in people business after all.

Are you interested to learn more or even have a TDD exercise for your developers/team? Do not hesitate to contact me if you are :)