« March 2007 | Main | May 2007 »
April 27, 2007
FRIM: Data Gathering for Retrospectives
I'm always interested in new ways to "Reflect" (from the Learning Circle) since this is often an overlooked aspect of learning. As Diana Larsen mentions in her blog entry about FRequency and IMpact, we often jump right into analysis (Learning). I haven't tried this method yet, but I can see it coming in very handy.
Posted by Mishkin Berteig at 10:52 PM | |
April 25, 2007
The Ladder of Inference Model
Last night I had a great conversation with a friend and co-worker, David Chilcott. He told me about the Ladder of Inference. This model is a way of taking the Agile Axiom that Reality is Perceived and building a model around that axiom. Here is another good link about the Ladder of Inference that provides some insight as to how to use it as a tool in communication.
Posted by Mishkin Berteig at 12:14 PM | |
April 22, 2007
InfoQ Article in Chinese
Quite some time ago, I wrote an article for InfoQ called "What is Agility and Why Should You Care?" That article has been translated into Chinese:
"What is Agility and Why Should You Care? (Chinese)"
Posted by Mishkin Berteig at 10:45 PM | |
April 20, 2007
Leadership
"A leader is a person who assists a group of people become a self-organizing, self-managing and self-sustaining team so that he/she no longer has to be a leader for that group." - Just an idea I had. What do you think?
Posted by Mishkin Berteig at 03:35 AM | |
Lawrence Miller
Back in the early 90s, my father let me watch a series of training videos by Lawrence Miller. At the time, I was in my late teens. I was very excited by the discussion regarding management, helping customers etc. I see now that he is also dealing with organizations, lean and topics of interest to me now! I haven't read any of his books, but I'm pretty sure that they would all be very interesting.
Posted by Mishkin Berteig at 12:01 AM | |
April 19, 2007
Effects of Defects: Grey Scope Creep
Is boosting productivity simple? Yes! Just cut code! One problem here. The gap between code complete and feature done is bigger then it appears. That was my thought as I was looking at statistics.
Reposted [and edited - Mishkin] from www.softwarefrontier.com by Dmitri Zimin(e)
On average, a developer cuts 300 lines per day, some true heroes claim more. This “productivity” comes with the price of 100 defects per 1000 lines of code. Finding defect and fixing it is on average 4 to 16 hours [1] [2]
Do the math: Your star developer produces 500 lines a day. This creates up to 80 hours of extra work to himself, the dev team and their tester buddies. 10 days! I call it “grey scope creep”.
At first, these statistics seems totally off. But you can surely remember such a super-star code monkey? You surely know a few. Now go over all these steps to fix a defect: cutting the build, installing it in QA, testing, finding the bug, writing a bug report, assigning it back to development, reviewing, trying in vain to reproduce… “Works on my machine”, sending it back to QA, and finally, after a couple of round-trips, it’s fixed. Then regression sticks out its ugly head, and the high 16 man-hours per bug looks too good to be true.
So, is boosting productivity simple? Yes! Less bugs in, more bugs out! One problem here. But enough on problems, let’s get positive and move on to how fight grey scope creep.
First, if these superstar developers only care about the joy of cutting code, not shipping the software, they get the boot. Don’t regret it, they produce more work then they get done. It is not about developers developing and testers testing. It is developers and testers working cooperatively to ship software. We've got no space for local optimization.
Second, good software practices are to the rescue. Pair programming, design and code reviews, test driven development, etc… They surely slow down the LOC/day pseudo-performance (less bugs in) and reduce the number of defects. Pair programming by itself brings 15% less bugs, with healthy 15% slow-down of LOC performance [3].
Third, redefine “done”. Fresh features are marked done, and then disappear somewhere in QA to eventually fire back at unknown time with unknown bugs. Grey scope creep. Stop it. Instead, insist on taking less but making it “done” within an iteration. Done reads fully developed, thoroughly tested, debugged, fixed including regression, and accepted by product owner. If this brings development to a deadlock, it’s one of the two. You may be blessed to fail faster and cheaper. After all, if you can’t get “done” just one feature, how would you ever be done with the entire project? Or the team overcomes the crisis and changes the working habits. The shortened feedback loop and fixing bugs as you make it leads to less time per bug fix. The grey scope doesn’t creep beyond the iteration. Problems become obvious early enough to to deal with them.
Finally, until you fix the grey scope creep, your estimations could be off, up to 10 times! Measure well.
So, is boosting productivity simple? Yes! One problem here. Trying to address it may expose the stakeholders to too much truth about the state of the project. Figure out how to deal with this truth. Or wait to my next blog entry... I have some thoughts about this too.
Posted by Dmitri Zimine at 09:42 AM | |
April 15, 2007
Four Methods for Dealing with Interruptions
Recently I've talked with a number of people who have a simple question: what do we do with teams that are constantly interrupted by urgent support requests for their time?
I have seen a few different structures work well for this kind of problem.
1) The part-time allocation to the iteration's work is most common. There are a couple things that need to be done to make this work well in the long term. The main thing is to make the allocation of time inflexible: if you allocate 50% to the iteration and 50% to support, then you should never be flexible about that allocation. This is necessary in order for the team to make a commitment at the start of each iteration.
2) Another common method is the "fluorescent note card" method which requires stakeholder negotiation around the impact of interruptions. With this method, any time a stakeholder comes to the team with a request, the Process Facilitator writes the request on a bright colored note card. The team then does a task breakdown on the card and using their normal process (whatever that is) estimates the work. The requesting stakeholder then has to negotiate with any other stakeholders about what work to remove from the iteration in order to make room for the new work. The trick here is that the team has to be involved because they have already started on some of the work and it might be difficult to dis-entangle things enough. This process works well primarily because it makes the tradeoffs visible. It does not work so well with letting the team make their commitments.
3) A third common method is to form two separate teams: one doing new work, one doing support work. This is simple, effective, and annoying for the people on the team doing the support work! Please don't consider a rotation system since this destroys the process of team development and makes it nearly impossible for the team doing new work to learn their capacity for the purposes of commitment.
4) A less common, but fourth method is to have extremely short iterations. In this method, choose your iteration length to be so short that you can always start work on urgent interruptions before anyone gets impatient! This can be exhausting, but it is one of the best ways to get the team and the organization to understand the large toll that these interruptions take.
Are there other methods that you have seen work?
Posted by Mishkin Berteig at 11:48 PM | |
Agile/Scrum Training in Beijing
This is a "last call" for people to register for the ScrumMaster certification course I am holding in Beijing on June 7th and 8th. At this time, I need only a few more people to be able to confirm the course (it is tentative at this time). If you are interested please save yourself a spot. If you know someone else who might be interested, please send along this link:
http://www.berteigconsulting.com/secure/a.php?h=042
I will be making my final decision on the course on April 22nd.
Thanks! - Mishkin.
Posted by Mishkin Berteig at 09:20 PM | |