« January 2006 | Main | March 2006 »
February 27, 2006
Organization Pitfall: Specialization and Cost Cutting
In a discussion with another coach earlier today, I described what I have observed is a common path that organizations take. A path that leads to stagnation and business failure.
The coach I was speaking to was my father, Garry Berteig. Among other things, he uses agile in his classrooms for class projects. He also has a great deal of experience with business and organizational administration.
Garry and I were talking about learning, energy and teams. We started to talk about the implications of agile teams for organizational cultures. At one of the organizations Garry has worked, the department he was working in suffered from substantial log-jams due to lack of resources to get specific types of work done.
Here is the common organizational pitfall: Specialization and Cost-Cutting.
1. The Organization Grows
Most businesses and other organizations start with an idea, a need or a person with an itch to do something different. With any small measure of success, the organization starts to grow. If it grows large enough, the people involved become specialists.
2. People Become Specialists
When a business grows large enough there is enough work to be done that it becomes natural for the business to hire specialists: people who are experts at a small part of the overall work of the business. This is allowed by the business having greater cash flow to hire more people. This also allows people to focus more and more on their favorite tasks since there will often be someone else who is better at the not-so-favorite tasks.
3. Specializations Become Canonized
As the organization continues to grow and as people become comfortable in their areas of specialization, there is a self-protective instinct that causes these specializations to become canonized in the organization's bureaucracy. Career paths, pay scales, management chains, centers of excellence, checks and balances, tracability, defined processes, handoffs, approvals, councils. It becomes difficult to step in and do someone else's job without stepping on toes or getting reprimanded.
4. Cost-Cutting Layoffs
The large organization with clearly defined roles and procedures becomes slow and inefficient. Inefficiency leads to higher expenses, lower profit margins and eventually even losses. The natural reaction of management is to try to reduce costs. Since people tend to be the most expensive part of most organizations, the natural place to look is to "do more with less" and lay off those who aren't really contributing that much to the bottom line. Multiple rounds of layoffs can occur until eventually, you are left with...
5. ...Fully Utilized Experts
Now the organization is operating at a somewhat more efficient pace by virtue of everyone being fully utilized at their particular role. People are busy 100% or more of regular working hours working on multiple projects or tasks or work streams. This is of course not terribly fun, but everyone keeps with it for fear of their jobs. Unfortunately it can't last long.
6. The Experts Leave/Get Sick
So when someone drops the ball in a fully-utilized cost-cut organization it is usually because they are sick of the environment either literally or otherwise. Anyone who is really an expert will likely find greener pastures and move on permanently. Anyone who is just barely holding on will eventually become exhausted and get sick.
7. Log-jam!
The work for the now-departed expert starts to pile up. There is no flex left in the system: no one can step in who isn't "authorized" and all the authorized people are already at 120% capacity. The system breaks down.
This patterns of organizational behavior is something I have personally observed and heard anecdotally from a number of other people. The end result is always the same: the organization ossifies into bureaucracy that may have seemed useful with the original large organization size, but has become constrictive with the post-layoff smaller size. (Actually, the bureaucracy was constrictive of the larger organization too.) The cause of this? A fundamental mis-understanding of people and organizations.
People are Creators, not resources that mechanistically perform work. Trust your people to find creative ways to do things. Only punish individuals for ethical lapses; don't punish the organization, nor punish people for honest mistakes. Instead, encourage experimentation, learning, individual initiative, creativity, role-breaking, role-playing and cross-training. Check out this brief discussion on generalizing specialists for a little more information.
Posted by Mishkin Berteig at 11:38 AM | |
February 24, 2006
Privacy for Self-Organizing Teams
Why are observers to the team's daily status meeting not allowed to participate?
The daily Scrum is a private meeting for the team members to report status to everyone else on the team. In many respects this is very similar to the regular private status meetings an employee has with their boss. It is rude and inappropriate for people to come into this manager/employee meeting. It is even ruder if a third party came to this private meeting and started making all sorts of suggestions or demands of the manager or employee. The privacy of this meeting is required to build trust between the manager and the employee and for both parties to be able to speak freely without embarassment... The daily Scrum should be considered exactly the same way with the one exception that the Team has graciously allowed observers to also attend. This is why observers are not allowed to speak during the daily Scrum.
Posted by Mishkin Berteig at 12:22 AM | |
February 23, 2006
Interation Retrospective Patterns
William Wake has posted a fantastic overview of patterns used in Iteration Retrospectives. I've added this (and a few other things) to the Agile Advice Recommended Materials page.
Posted by Mishkin Berteig at 06:51 PM | |
February 22, 2006
Agile Work Uses Lean Thinking - Whitepaper Published
Berteig Consulting Inc. has published a whitepaper about some of the relationships between Lean and Agile. The paper is based on three prior entries here on Agile Advice relating to Queuing Theory, Empirical Process Control and Self-Organizing Teams.
For more in-depth reading, I highly recommend the following three books:
This gives a great introduction to Lean thinking applied to software and specifically agile software development.
2. Agile Project Management with Scrum by Ken Schwaber
This books provides some excellent background on empirical process control and how it relates to agile project management.
3. The Goal by Eliyahu Goldratt
A business novel chronicling the experiences of a manufacturing plant manager learning about the Theory of Constraints (closely related to Lean).
Posted by Mishkin Berteig at 01:13 PM | |
February 20, 2006
Minor Site Updates
I have updated the category names to be a bit more descriptive and to allow for entry headers to be styled by category. This announcement is an example of that! I have also added an indicator for the number of entries under each category on the category listing on the right side of this page. Hope these minor updates make the site just a wee bit easier to use!
Posted by Mishkin Berteig at 06:19 PM | |
Improvisation for Agile Facilitators
Once in a while I will announce events, classes, etc. that I think might be of particular interest to readers of Agile Advice. This one is for people in the Seattle area and comes to me through Tobias Meyer.
Improvisation for Facilitators is a one-day workshop offering core improvisation skills to Agile facilitators and coaches. See the full entry for more details.
Trainer: Matt Smith
Location: Seattle, Washington (venue to be announced)
Date: Tuesday 21 March 2006
Cost: $180.00 per person
Matt Smith is an actor, improv artist and corporate trainer based in Seattle, WA. Matt has explored Agile principles and values with Kert Peterson, and has taken the Certified Scrum Master (CSM) course with Ken Schwaber. This full-day workshop promises to be an engaging and energetic experience, providing facilitators and coaches with new tools and techniques to take into the Agile workplace.
For full details of this course, and enrollment information, visit http://agilethinking.net/improv01.html
Posted by Mishkin Berteig at 04:01 PM | |
February 19, 2006
Three Concepts for Value Stream Mapping
One of the first tools to use when looking at process improvements for any type of work is a value stream map. This tool can usually be used to find substantial and immediate improvements to process efficiency even before considering any Agile Work practices. There are only a few basic concepts to understand before jumping in...
Value Stream Mapping Basic Concept One: Touch Time and Cycle Time
Touch time is the amount of time people actually spend working on a task: building, thinking, breaking, writing etc. but excluding the time they break for coffee, writing emails, waiting for answers to questions etc. Cycle time is the overall time people are working on a task from the moment they take responsibility for that task to the moment they hand off their results and no longer have responsibility.
Value Stream Mapping Basic Concept Two: Value Added and Non Value Added
Value added tasks are those that actually add value to the end result. The opposite, non value added, is also known as muda or waste.
Value Stream Mapping Basic Concept Three: Be Brutal, Be Conservative
Be brutal and conservative when deciding the touch time vs. cycle time for an activity or when trying to decide if an activity is value added or not. Typically an organization starts out with about 80% of all of their processes being waste of various sorts. Look at your value stream map and try to classify about 80% of it as non value added or cycle time overhead.
Value Stream Mapping Process Step Template
Here is a nicely formatted template you can use for tracking your tasks in a value stream map in three formats:
OpenOffice.org
Value Stream Map Process Step Template
Microsoft Excel
Value Stream Map Process Step Template
Adobe PDF
Value Stream Map Process Step Template
Posted by Mishkin Berteig at 08:56 PM | |
February 17, 2006
Timeboxing: A Critical Agile Work Practice
When you think of the show "Saturday Night Live", you probably think of things like "funny" or "stars". You probably don't think that this show epitomizes the idea of timeboxing.
A timebox is a fixed amount of hours or days in which to accomplish something. Iterations are timeboxes. When you say to yourself on a trip: "let's see how far I can go in 8 hours of driving", you are giving yourself a timebox. When you write an exam in school, you might have a three hour timebox. For complex work, timeboxing is a way of limiting the amount of time on something in order to prevent excessive effort or spending. As a weekly show, Saturday Night Live does this to a "T" (Thanks to Alex Sirota of Newpath Consulting for pointing this blurb out to me!):
To go from blank page to a live, 90-minute telecast every week, the process begins with a Monday afternoon meeting in Michaels' office, where writers and performers meet the week's guest host. Ideas are batted around, and the material that seems funniest is developed at writers' keyboards over the next few days. On Tuesday and Wednesday, writers refine ideas, often with little or no sleep, and as the host grows accustomed to the anarchy his/her opinions and ideas are given more consideration. By Wednesday afternoon's meeting, the writers may have as many as fifty sketches, perhaps 40 more than will actually air. Most will be rejected by Michaels or the host, and the few that remain may be rewritten. On Thursday, some skits go through a dry rehearsal, and by Friday all the skits are usually prepared, with sets and stage instructions.Saturdays begin with a run-through that may be as long as two and a half hours, after which Michaels and the show's writers make "semi-final cuts." At 8:00 PM, there is a dress rehearsal in front of a live audience, and this show may be as long as an hour and fifty minutes, leaving up to twenty minutes of "final cuts", which are decided largely on the basis of what the audience seems to find funny. Then, at 11:30 Eastern Time -- live from New York, it's Saturday Night.
(http://www.nndb.com/people/621/000024549/)
For the people involved in creating Saturday Night Live, there is a great deal riding on getting the show done on time. They have a slot and if for some reason they should fail to get ready in time, they would have a serious problem on their hands. This pressure is one of the main factors for timeboxing to work.
In other types of work, it may be necessary to artificially create the pressure to meet the timebox deadline. You can schedule demos, make public commitments or set in motion other work that will fail if you fail to meet your timebox.
It is also critical that your timebox be set to a good size: too small and you won't be able to get anything done, and too large and there will be no pressure to work until you are nearing your deadline. This is closely related to the horizon of predictability.
Posted by Mishkin Berteig at 01:18 AM | |
February 15, 2006
Something a Little Different: 19 Leadership Capabilities
This list of nineteen leadership capabilities, hosted on the web site of a private school in Ontario, Canada, is inspiring and in many ways closely related to the work one must do in an Agile context. The list is written in the language of a moral or ethical framework. The whole list is interesting food for thought so I have reproduced it here as well with a few additional comments.
1. Evaluating one's own strengths and weaknesses without involving ego.2. Transcending one's lower passions by focusing on higher purposes and capabilities.
3. Managing one's affairs and responsibilities with rectitude of conduct based on moral and ethical principles.
4. Learning from systematic reflection upon action within a consistent framework.
5. Perceiving and interpreting the significance of current events and trends in light of an appropriate historical perspective.
6. Thinking systematically and strategically in search for solutions.
7. Forming a common vision of a desirable future based on shared values and principles, and articulating this in a way that inspires us to work towards its realization.
8. Imbuing one's actions and thoughts with love.
9. Encouraging others and bringing happiness in their hearts.
10. Taking initiative in a creative and a disciplined way.
11. Sustaining effort, perservering, and overcoming obstacles.
12. Participating effectively in consultation.
13. Building unity in diversity.
14. Committing oneself to empowering educational activities as a student and as a teacher.
15. Recognizing relationships of domination and contributing to their transformation into relationships based on interconnectedness, reciprocity, and co-operation.
16. Contributing to the establishment of justice.
17. Serving in societal institutions so as to facilitate the expression of the talents of others that are affected by these institutions.
18. Being a responsible and loving family member as a child, spouse, or parent.
19. Cultivating and creating a sense of beauty in every endeavour.
Only one of these (#14.) is phrased awkwardly for us as participants in agile efforts since it refers specifically to the educational context these are written for. Other than that one, and with a little thought that one as well, these are all appropriate to us. We may be uncomfortable with the specific language from time to time, but we should be certain to take the time to consider how these apply... assume positive intent and look for the wisdom and truth in each item.
Number 4 is particularly apropos to our work:
Learning from systematic reflection upon action within a consistent framework.
In many ways, this is what we do with iterative delivery and adaptive planning. It is double-loop learning.
Posted by Mishkin Berteig at 01:01 PM | |
February 14, 2006
Daily Status Meeting Disfunction
There are many ways that the daily status meeting for self-organizing teams can be done incorrectly. One of the most common, particularly early in a team's adoption of Agile, is that people report to the Process Facilitator. Why is this bad?
The daily status meeting is meant to be an opportunity for the team members to report to the team on their progress and obstacles. If the team members are reporting to the Process Facilitator (or the Product Owner, or the project manager or the executive who just happens to join the meeting) then those people are going to change what they report and how they feel about the meeting. It will no longer be as open, nor as useful to the other team members.
Although this might seem like a subtle point, it is actually quite critical to the overall effectiveness of the team. A team which is seeking approval from leadership or management will not be nearly as focused on success as the appearance of success. There will be a tendency to report work done even if it isn't really, to minimize obstacles and impediments, and to look for assignment of work from the manager/Process Facilitator/team lead.
In order to overcome this disfunction, the Process Facilitator may have to make some changes to the meeting: make it closed to observers, start the meeting every day by encouraging people to report to their teammates, move the meeting to be around the task board for the iteration. It may even be necessary for the Process Facilitator to do odd things like standing behind the person who is currently reporting so that that person does not look at the Process Facilitator.
More details about the Daily Scrum from the Scrum methodology.
Posted by Mishkin Berteig at 05:35 PM | |
February 06, 2006
Something a little different on Work-Life Balance
This is one of my favourite works - at the time, I was both working and studying the fine arts, a true juggling act. My boss was a believer in Balance - he sponsored my second show, and he bought this picture. Happily, he let me buy it back when they moved to a new space, after I'd moved to another city. Now, more than ever, I need its gentle reminder.
The juggler keeps a balance between work, play, obligation and passion.
If you'd like to use this image, to remind yourself or others to strive for a good balance, feel free to use it under the terms of this Creative Commons License. Enjoy :-)
See the full image of The Juggler (collage with appropriated images, Deborah Hartmann, 1995).
Free for commercial use with attribution. Ask me about other uses.
Please note: 
Posted by Deborah Hartmann at 05:38 PM | | | TrackBack
February 03, 2006
What Management Wants
The recent discussion on the ScrumDevelopment list about the waterfall method & management control has finally pushed me, a lurker, to post my $0.02: I know what management wants... management wants transparency.
Management constantly struggles to figure out what the heck their company is actually DOING all the time, while also trying to figure out what the competition is doing, what customers want but can't articulate, whether or not they have the right organization and management structure to effectively execute, etc. They have to predict the future direction of our customers, and figure out how to steer the corporation so that it is best positioned to deliver value to our customers both today and in the future.
It's hard to get to where you want to go if you don't know where you are at. That's why they want transparency.
Or at least, that's what my Management Team wants. I know this because I've asked them. And when they can't articulate what it is that they want, I study them. I study their line of questioning. I study their decision making style.
This is what my Managers think (all the time):
Should we be developing this application at all? Can we buy or license a solution instead? Are we in the right business? Are there other ways to squeeze more out of our value chain? Competitor XYZ is repositioning itself -- what new threats and what new advantages are there of this shift?
Folks, what I'm trying to say is that your Management Team is simply another customer. People that meet customer needs are a more successful that people that don't.
Did you ever have a customer try to dictate Design Details to you? Of course. Did you accept what the customer said, or did you dig a little deeper and determine their true, hidden requirements, that they weren't able to articulate?
Treat "Management" the same way. Do they demand weekly schedule updates? Did you ever ask them why? Have you sat down with your Management Customer to find out what their needs are, and how you can best fulfill them?
Sure, my Management Team suffers from Dashboard-of-the-Month Syndrome, where they keep changing the format and content of the "1 page project snapshot" evey 4 weeks. I live with it, just like I live with the customer that we've all had that keeps changing their minds about what they want. It takes me just 5 minutes to fill out my dashboard, regardless of the format, because my manager's already know what's going on with my project.
We're Agile, right? So doesn't that mean we're all about delivering value in the face of uncertain requirements? ASK YOUR MANAGER WHAT HE REALLY WANTS. I don't have problems with my Management Team, because they always KNOW WHAT THEY WANT TO KNOW about my project. They don't know this through the Dashboards, I don't delay important updates until the next Stage-Gate meeting, or wait until the next Monthly Review to request additional resources. I make sure I know what is important to them and deliver exactly that.
Because of this, I've earned their trust, and they rarely micromanage. I never deliver what was promised, instead, I deliver what they need. Sound familiar?
When I've come across a pointy-haired middle manager that REALLY wants to control, again, I treat them just like any other customer. I observe them to determine what their real needs are.
Do they need to be in control, or do they need to APPEAR to be in control? If its appearance, then I can go ahead and get the key decisions agreed upon ahead of time, and run it through the middle manager for official approval, with the appropriate deference to the Alpha Male Manager.
Do they just want to be informed of bad news 24 hours before upper management, because they've been burned by the grapevine before and looked stupid when upper management knew more than they did? If so, then absolutely make sure they never look stupid because of you or your team.
Do they think that they are the Savior, and therefore I need to find a crisis that they can save us from? (Golly gee, there's this one vendor that we're just having a lot of trouble with, and I hate to ask with how busy you are and all, but I know that with your experience...)
Please don't take this as a cynical view of human behavior; I've managed to successfully work with some real jerks just by finding out what made them act like jerks, and finding ways to address their legitimate concerns and insecurities.
Watch. Listen. Then deliver value.
Pat Baird
pat_baird@hotmail.com
Posted by Guest at 12:42 PM | |
February 01, 2006
Two Sister Conferences
I've applied to run two discovery workshops at Agile 2006 (I'll make a complete announcement if/when I am confirmed as a presenter), and there are going to be a great number of excellent speakers and topics at Waterfall 2006. I hope to see you there!
Posted by Mishkin Berteig at 12:28 PM | |