Home

Pflogging

the never-ending quest for pragmatic solutions, useful plans, flawless execution, and designs that endure
Home Areas of interest Paradigm shifts Agile techniques

User login

  • Create new account
  • Request new password

A number of key features are only available to registered users. They include:

  • Access to the full content of top-rated material (only teasers are available to anonymous users after the material has been posted for 45 days)
  • The ability to search site content
  • The ability to access reviews of books relevant to site material
  • The ability to access key quotes relevant to site material
  • The ability to access content from partner sites
  • The ability to rate material
  • The ability to post comments
  • The ability to post new information and propose it for publication
  • The ability to request email notification when selected content is added or updated

Implementing change - an owner's manual

  • View
  • links
Submitted by Bryan Pflug on Sun, 11/04/2007 - 04:49
  • Agile techniques
  • Lean practices

Man Carrying ClockThe largest and most successful efforts to apply lean within engineering environments have occurred within the software engineering field. Within these projects, the most common approach has been to leverage the introduction of lean practices through adoption of compatible agile techniques. There is an understandable tension in this arena to strike the right balance between flexibility and discipline.

It is important to recognize that adoption of such new approaches, like any innovation, will take time, focus, and regular evangelism in order for any such change to stick. More importantly, there are critical project 'human factors' to consider when chosing to pursue lean techniques for a group. Any such effort should include:

  • writing and communicating a high-level plan; without it, you cannot diagnose what's working and what's not. It can be as simple as this, which was used at Yahoo.
  • recognizing that engineers want to do engineering, not process work; to them, the product matters more than the process
  • acknowledging that engineers are likely already very proud of the job they are doing, and that they will know far more about what they do than you can ever hope to. Asking them to change their ways just for you or your initiative is not something that is likely to be successful, especially if you try to shove the ideas down their throat. You must develop a relationship with the people, and understand them and their own challenges, fears, and passions, before expecting them to care much about what you're trying to do.
  • understanding the workload imposed upon the engineering team to learn and adopt the new ideas being promoted
  • accepting that extra effort (and even possibly extra rewards) may be useful (or even necessary) to help grease the path for early adopters, and the extra pain they likely will encounter
  • supporting the team through any roadblocks they encounter, in any way you can

While there is no silver bullet or magic formula for success, a project's characteristics (especially its personnel, dynamism, culture, size, and criticality) should influence how to strike the balance between agility and discipline. Additionally, in practice, it is always easier and better to build your method up than it is to tailor it down. Finally, one must keep in mind that people, communications, timing, and expectations management will always be more important to overall success than methodologies alone.

0
Your rating: None
‹ Managing quality, deliveries, and priorities up
  • Login or register to post comments