« November 2006 | Main | January 2007 »
December 31, 2006
Sustainable Pace
I'm learning by example - bad example - my own!
I have been running myself ragged over the last few months. I rarely get more than seven hours sleep, and it is usually more like five or six hours. I'm keeping busy with writing, coaching, training, new product development, business development and other work. I'm trying to maintain a decent semblance of a family life. And I have administrative duties with my religous community.
All of this going on is not sustainable.
Luckily, it is now a couple hours into January 1st, 2007 and I have the opportunity to partake of the traditional New Year's Resolution.
So here goes:
I resolve to timebox my personal effort on work related activities to no more than 50 hours/week starting July 1st. I will do this by using Agile Work methods to organize my work, by removing obstacles, by automating repetitive tasks, by finding team mates, and by focusing my efforts on a clear business vision and objective.
You would think that I'd already be doing all this... and in some ways I am. But these efforts need to be consistent, systematic and wholehearted, rather than something I do as the exception. My current state of affairs is more chaos and crisis than I would like. And considering my admonitions to my clients to be truthful, I better be truthful myself about my own current state.
Just as a point of reference, I expect that I spend close to eighty hours per week on work currently.
I'll keep everyone up-to-date on how it's going. After a good sleep tonight, I'll do an iteration planning meeting. I might not bare all, but I'll certainly provide some concrete examples of the sorts of things that I am doing and trying.
By the way... I feel compelled to point out that I actually celebrate "new year" in March according to the calendar of the Baha'i Faith, of which I am a member. However, living in the West, I still feel the power of some of the cultural traditions, and in particular the changing of the year is one that for some reason resonates with me. I think it's the beauty of highly significant digits in the date changing. Anyway... good night and I hope everyone has a wonderful, challenging, joyous 2007!
Posted by Mishkin Berteig at 11:10 PM | |
December 27, 2006
Reminder: Discount for Agile Courses
The holiday season here in North America is a pretty slow time. Sorry for the lack of interesting entries! I want to remind people that there is a 10% discount if you register or save a spot in one of the classes offered by Berteig Consulting Inc. The trick is, the discount is only available for another five days! Save yourself a spot even if you don't pay now: Agile Training and Workshops.
Posted by Mishkin Berteig at 03:20 PM | |
December 24, 2006
Agile Training in India
I am planning a training course on Agile Project Management / ScrumMaster Certification in Chennai (Madras), India early in the new year (hopefully the second half of February). At this point, dates are tentative, but I would love to hear from readers who would be interested. As well, if you know others who would also be interested, please let me know. I will be firming up numbers and dates early in January as well as making the final go/no-go decision at that time. Please contact me either by email (mishkin@berteigconsulting.com) or by phone +1 905 841 1196 if you are interested.
Some details about the course: it will be a 3 day course rather than the usual 2-days that is taken by the ScrumMaster Certification. I have not yet finalized a price but it will likely be a small amount lower than my regular ScrumMaster course price (which is CA$1200.00). There is the opportunity for me to run an in-house private class while I am there if your organization can send enough people (contact me for details).
I hope that I can meet some of my readers in the new year!
Posted by Mishkin Berteig at 04:37 AM | |
December 22, 2006
Link: Agile Methods as a Replacement for Fossil Fuels
Agile Methods as a Replacement for Fossil Fuels - great post about old vs. new ways of managing knowledge workers.
Posted by Mishkin Berteig at 03:27 PM | |
Technical Debt
Last night I was thinking more about the analogy of technical debt. In this analogy, design and quality flaws in a team's work become a "debt" that must eventually be paid back. This analogy is fantastic because it can be taken just a little bit further to understand just how bad defects are...
Debt is sometimes useful. Financial debt can be used for risk reduction, investment, and emergencies. But it can also cause problems. Too much debt becomes hard to manage. If debt maintenance costs more than revenue (minus other expenses), then you're going down!
Technical debt is a little different than financial debt.
Suppose I went into a boardroom full of high-power executives for some large company. (Never mind how I got there.) And I pitched this fabulous idea: I'll give them a bunch of money for them to use for operations, expansion, whatever. All they have to agree to is that I choose the interest rate when I ask for repayment... trust me!
I would be thrown out of that room so fast!
That is what we do when we encourage teams to take on technical debt.
There is no way to know the interest rate on a defect. Part of the cost of a defect is obvious: how much time and materials will it take to repair the immediate problem. (Although even that is often hard to measure.) But there are also lots of non-obvious and probably non-measurable costs. How much effort will it take to get to the root cause of the defect so that it doesn't occur a second time? How much will it affect our "goodwill" and thus reduce further and repeat sales? How much will the existence of one defect hide the existence of other defects (with their own costs)? How much will the defect demoralize the team and increase staff turnover or reduce productivity? How much of an opportunity will the defect create for competitors? How much will the defect increase maintenance and support costs?
In other words, every time someone asks a team to let quality slide, they are asking the team (and the organization) to take on debt with an unknown interest rate. Which is lunacy.
Read more about this:
Voluntary Technical Debt - James Shore talks about a situation where a conscious decision to take on technical debt led to positive results.
Technical Debt: The Threshold of Acceptable Pain - Steve Bate talks about skill and sensitivity to technical debt. Here's a great quote from this article:
What if someone has a very high threshold of pain? I’d expect to see lots of crud (technical debt) in their code.... The high threshold developer doesn’t mind spending weeks on new features that would otherwise require days or hours with clean code. And they don’t mind staying at work all night fixing bugs before a major release or spending countless hours babysitting the production system after it’s been released. It doesn’t seem to bother them to spend significant time away from family and friends or to have limited time or other interests and hobbies. ...they sometimes experience pleasure at being the “hero” who saved the company from the bugs they created.
An Incremental Technique to Pay Off Testing Technical Debt - Johanna Rothman talks about technical debt and describes a simple risk-oriented approach to reducing it.
Posted by Mishkin Berteig at 08:23 AM | |
December 18, 2006
Lean, Agile and Capitalism - Just a Thought
It occurred to me to ask: If the "invisible hand" in the free markets of capitalism is making for efficient markets, efficient work... then why is there some much room for improvement when we start using non-competitive, collaborative techniques such as lean and agile?
And if these collaborative techniques work on a small scale to improve efficiency, does this mean that we could do this across organizations as a "replacement" for capitalism somehow?
In agile methods, we "assume positive intent" on the part of individuals. What if we could do this across organizations? I'm not living in a dream world yet, but I think I have an inkling of what it might look like: Toyota and its collaborative, leaned-out supply chain.
Posted by Mishkin Berteig at 06:39 PM | |
Goal Setting
Andrey V Khavryuchenko has written an interesting article on goal setting called Well Formed Outcome. Andrey describes the six criteria for setting an achievable goal. Interestingly, these are similar in some respects to the conditions necessary for testability.
Posted by Mishkin Berteig at 11:04 AM | |
Calling for Reviewers
I have finished a first draft of a short book (60 pages) to be published online on the topic of Agile Work. It is all about applying agile methods to non-software environments. I am looking for two or three people who would be willing to review the draft. If you are interested, you need to be able to commit the time for this week to read it and provide feedback. You should also have tried applying agile methods in a non-software environment (anything will do). Please email me at mishkin at berteig consulting dot com if you are interested in doing this.
Posted by Mishkin Berteig at 12:29 AM | |
December 13, 2006
8 Team Room Tips
Here are eight tips for making a great team room.
Light, Air, Nature
An appropriate amount of natural light, air circulation and live plants are excellent ways to make a space suitable for human occupation. The lack of these things can subtly but surely slow down and demoralize a team.
Layout
People need to be able to face each other and work beside each other. They also need a semi-private space to have discussions or make phone calls. The walls of the space need to have large areas that can be used for whiteboards.
Ergonomics
It's just not worth it to have a high-performance team hampered by a poor workstation setup. Good chairs, tables at an appropriate height, and the flexibility to allow individual ergonomic needs to be accommodated all help.
Privacy
Every member of the team needs to be able to get away for short amounts of time. Some organizations provide separate mini conference rooms or “hoteling” spaces. Others allow staff to keep a private cubicle away from the team room.
Personalization
The area of space that a person occupies needs to be flexible and personalized. People need pictures, toys, plants, and other incidentals to help them make a space their own.
Visibility to Outsiders
Other people in the organization need to be able to walk by to see and hear what is going on with the Agile Work team. Open doors, windows or a “bullpen” formation of cubicles all allow this.
Convenience
The space must be located so that washrooms, coffee, printers and other common services are easily accessible. It should not be set off and isolated far away from everything else.
Noise
The team will be noisy. Make sure that other people outside the team room are far enough away or isolated in some way from the noise. It can be hard to balance this with convenience and visibility.
Posted by Mishkin Berteig at 07:37 PM | |
Yahoo! Group for Agile Work
I'm starting an email group to discuss the ideas of Agile Work. I think that there are enough differences in practice, emphasis and theory from the other agile methods, that it is probably reasonable to start some more discussion about Agile Work as a separate thing.
In particular, I am interested in promoting the application of these ideas far beyond the bounds of just software development. How does this method apply to families? Communities? Organizations? Artistic and creative work? Research? Experimentation? Rote work? Where is it being practiced? What problems do people have applying it? What theoretical considerations are you puzzling over? Do you think its a load of crap or the answer to all our problems? Please join this group so that this can become a discussion instead of just a platform for me to write at you.
Agile Work is for people, not robots.
Posted by Mishkin Berteig at 03:26 AM | |
December 12, 2006
Reminder: Discount on Agile Training and Certification
Take advantage of the 10% discount on agile training and certification courses offered by Berteig Consulting Inc. to Agile Advice readers. This discount is only available until Dec. 31st! If you don't know 100% if you can attend, consider using the "Save a Spot" feature to register while you firm up your schedule or get approval for the training.
Posted by Mishkin Berteig at 10:13 AM | |
Glossary of Agile Terminology
There are quite a number of agile methods that are being used around the world in many different types of environments. This glossary provides a quick-reference translation between the various terms used in these methods. I have also included terms that may come from other non-agile disciplines that are strongly related.
If you are using terminology in an agile environment that is different from the terms listed here, please add your comment and I will update this list. In particular, I am looking for people with practical experience with DSDM and FDD to contribute their expertise.
Glossary of Equivalent and Related Agile Terms
Self-Organizing Team: Chickens and Pigs (Scrum), Whole Team (Extreme Programming), Cross-Functional Team (business management), Real Team (The Wisdom of Teams).
Deliver Frequently: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).
Plan to Learn: Inspect and Adapt (Scrum), Kaizen (Lean), Double-Loop Learning (Organizational Learning), Adaptive Planning (generic).
Communicate Powerfully: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).
Test Everything: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).
Process Facilitator: ScrumMaster (Scrum), Coach, Lean Six-Sigma Black-Belt, Agile Project Manager
Queue Master: Customer (Extreme Programming), Customer Proxy, Product Owner (Scrum), Business Analyst, Product Manager
Work Queue: Product Backlog (Scrum), Stories (Extreme Programming), Business Requirements, To-Do List, Project list + Tickler (Getting Things Done)
Task List: Sprint Backlog (Scrum), Work Breakdown, Components, Tasks, Context lists + Next Actions (Getting Things Done)
Test-Driven Work: Test-Driven Design/Development, Test-First Development (Extreme Programming)
Retrospective: Reflection Meeting, Post-Mortem, Debrief, Weekly Review (Getting Things Done)
Team Status Meeting: Daily Scrum (Scrum), Daily Stand-up (Extreme Programming), Daily Reviews (Getting Things Done)
Record of Obstacles: Meta-Backlog (Scrum), Open Loops (Getting Things Done)
Work Period: Day (Scrum, Extreme Programming).
Measure Value: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).
Clear the Path: Removing Obstacles (Scrum), Stopping the Line (Lean), Collect to have "mind like water" (Getting Things Done).
Agile Methods and Other Disciplines Included
Scrum
Extreme Programming (XP)
Lean Software Development
Where I Need More Help!
The following disciplines need better representation in this glossary. Please help out!
* Project Management Institute's Project Management Body of Knowledge (PMBoK)
* Dynamic Systems Development Method (DSDM)
* Crystal Clear
* Rational Unified Process (RUP)
* Lean Manufacturing
* Personal Software Process (PSP)
* CMMI
* Feature Driven Development (FDD)
* Getting Things Done (book)
* Others?
Posted by Mishkin Berteig at 08:20 AM | |
December 11, 2006
Question from a Reader
A reader has asked:
I was wondering if you have any white papers or best practices on how to implement the agile methodology in a “product” company where we do more implementation of our product , not really new development. We have some development phases where we customize our product but we don’t necessarily do ‘pure software development” like Greenfield projects….
Here are my thoughts...
The concepts of Agile Work apply to many types of work, not just pure software development. I have experience working on a number of different project types using Agile Work including implementations, software upgrades, infrastructure changes, and system decommissioning. The basic ideas are always the same: set a goal based on specific valuable results, use iterations to deliver small bits of value in short time periods, and allow the team the freedom to do the problem-solving.
For product implementations, just like new software development, the most common approach is to deliver small numbers of features per iteration based on the product being integrated into the existing systems.
Here are some lessons learned from three infrastructure related projects that I worked on.
Do any readers want to share specific examples?
Posted by Mishkin Berteig at 06:38 PM | |
December 07, 2006
Peformance Goals - The Wisdom of Teams
As I continue my enthralled read through "The Wisdom of Teams: Creating the High-Performance Organization
The Performance Goal
This concept and practice is an essential condition for a team to become a high performance team. The Performance Goal is a specific, measurable, challenging goal that is given to and/or adopted by the team. It is a statement or description of a goal that answers "why?" and "what?" questions, but specifically avoids answering "how?". It is not a description of activities, it is a statement of desired results. The team is left with the full authority to answer "how?" and implement it.
This concept is essential for setting the initial boundaries of self-organization. By defining "what" and "why", the team is left free to be creative about the solution. The Performance Goal is also essential to building team accountability (as opposed to individual or externalized accountability). Every action, plan, mistake and success are oriented around the Performance Goal.
From the book:
The hunger for performance is far more important to team success than team-building exercises, special incentives, or team leaders with ideal profiles. In fact, teams often form around such challenges without any help or support from management. Conversely, potential teams without such challenges usually fail to become teams.
I would also like to point out a great blog entry I found that shows some of the other side of dealing with teams and present some cautionary words about the potential pitfalls of working in teams.
In an Agile Work environment, the starting point for a performance goal is simply the delivery of valuable work at the end of their very first iteration. This is often a substantial challenge to a team and an organization. For some teams that have worked for a long time in a "waterfall" or phase-based project environment, it can be almost unthinkable that valuable results could be delivered in one tenth or one twentieth of the "normal" amount of time.
However, simply delivering value at the end of each iteration is probably not going to sustain the development of a high performance team for very long. Rather, the overall objective or goal of the project has to be important and compelling. Much work these days is _not_ important and compelling. In fact, many people become cynical about work because they are stuck doing a high proportion of work that is bureaucratic or due to chaotic circumstances.
As a reminder, the books "Good to Great
I frequently work with organizations where a team has been formed up, told to use agile methods, and then also told how to do their work. Really great examples of this are things like: "we want you to self-organize, but you have to build this huge system using J2EE." The the problem with this is simply that it may in fact be ten times less expensive to build the system with Ruby. However, someone has decided (possibly for defensible reasons) that J2EE is the technology platform that must be used. In this circumstance, someone external to the team has stepped over the boundary of "why" and "what" and also included some "how" in the team's goals. The team is not even allowed to consider the possibility that something might work just as well and be much less expensive. Not only that, but the stakeholders haven't even really stated "why" the system is being built and so the team can't evaluate technology choices. There is no standard around which to self-organize. I admit that I am using a simplistic example here, but the pattern is something that I have seen over and over again.
Posted by Mishkin Berteig at 11:44 PM | |
December 05, 2006
Dysfunctional Scrum Video
This is painful to watch... but all of these things happen. Presenting: the dysfunctional daily scrum video. Here are some related links:
Daily Status Meeting Dysfunction
Is There a Single "Most Important" Agile Work Practice?
More on Daily Status for Self-Organizing Teams
Privacy for Self-Organizing Teams
Good Intro to the 3 Questions in the Daily Team Status Meeting
Facilitation Skills Handbook [pdf]
Posted by Mishkin Berteig at 09:47 PM | |