Home

Hello, I’m Veronica

The sky is not completely dark at night. Were the sky absolutely dark, one would not be able to see the silhouette of an object against the sky.

  • ,

    Agile Aligned Organization

    I was having a conversation with a client last week about things to consider when moving to an agile development organization.  Here’s some notes from the conversation:

    • Create product and customer focus: Design around products and processes necessary to fulfill current and future customer/market requirements.
    • Enable agile development: As product development is transitioned to an agile approach, the organization must be structured to support the new teams and create product focused team effectiveness, not task efficiency.
    • Create local ownership: Development teams should have ownership of and accountability for the entire development process. Team members should have visibility into the full processes and responsibility for products (not just tasks) and be encouraged and empowered to make improvements. The distance between issue emergence and resolution should be minimized.
    • Ensure organizational standards: Despite being autonomous, teams must conform to standards that optimize organizations overall effectiveness and ensure specialty skills are maintained and enhanced across teams.
    • Optimize project release management: Development management, the PMO organization and charter system must recognize how agile teams function and plan, prioritize and release work to those teams in a compatible manner that maximizes throughput while minimizing the time to create new functionality. Additionally, measurements should focus on ensuring the development process is working efficiently and effectively to deliver customer-valued results.

    This constitutes a pretty good list of guiding principles and goals. Hard work is still needed to apply these to their organization.  Even with the same objectives, every company will need to design their own details, staff new roles and plan and execute their transition. Depending on the organization’s size, this can take a couple months to multiple years to fully implement.


  • ,

    Learn from Successes and Failures

    Brad Feld has a great post up today titled “What do you Suck At?  I love the exercise he describes that asks participants to talk about what they suck at.

    I was recently listening to a podcast from the Standford Entrepreneurial Thought Leaders Seminar by Tina Seeling.  She has an assignment in one of her classes for students to write a failure resume.  While typical resumes focus on successes, she suggests that we learn more by understanding our failures.

    Why? To me, failures and shortcomings define your learning. Great failures and great successes are closely related. By focusing on failures, you find new ways to approach old problems and ensure you grow, compensate, and become more successful.  Brad says it well: “The meta-message was that we all suck at some things; understanding them and being able to articulate them is the first step to addressing (or managing) them.” They also keep us humble.

    So, what do you suck at?

    PS: If you don’t subscribe to the ETL seminars, which are freely available on the Stanford site or on iTunes, I highly recommend them.


  • , ,

    People Laws (part 2) 7th, 8th, and 9th Laws

    The seventh law of agile physics:

    Good people in a bad system will generate poor results and a bad morale.  Responsibility without authority is counterproductive and demoralizing.

    This gets to the heart of leadership.  I would argue that the systems leaders put into place have more impact on people than any other thing they do. They empower or restrict their abilities to get things done.  Systems, along with the vision created, are the tools people use to deliver desired outcomes and ultimately achieve beyond the expected possibilities.

    Among the systems that have the most impact are the processes, the value systems, and the measurement and incentive systems implemented.

    We’ve discussed in some depth how agile processes enable people to achieve better results. We might even from this conclude that agile makes great leaders. I would at least postulate that agile empowers people to do more though better process.  I have also discussed how focus on the right values can further promote exceptional performance.

    To show the impact of poorly designed measurement and incentive systems, Deming used an red bead experiment. Participants were asked to scoop beads without looking from a bin of mixed red and white beads. Red beads were measured as defects. The participant with the fewest defects was named “employee of the month” and those with high defect rates were demoted or counseled. When repeated, those counseled usually improved, showing how management was “successful.” The top performers almost always performed more poorly, showing they were “slacking” after their recognition. Obviously, the “employees” were only demonstrating natural variability and had little ability to impact the results. The resulting drain on performance and morale is easy to extrapolate.

    Subtle nuances of incentive systems can have broad unintended consequences. The real life examples of incentive measurements that imitate the red bead experiment are many. Due dates for on-time performance can have little consideration for capacity; production may be reduced due to raw materials shortages; profitability for a project may be predetermined by sales or existing contracts; time demands may not allow for focus on performance improvement initiatives; needed resources may not be allocated; and many more.

    The eighth law of agile physics:

    People are different.

    While obvious, often the impacts of this law are not fully considered. Individuals have different talents, interests and motivations. Changing even one person on a development team can drastically impact output rates, as well as the team’s interaction and other dynamics.  If the team is not “recalibrated” for the change, expectations may not be met. This includes not just adjusting capacity, but ensuring other systems continue to be relevant. People between teams and organizations will also vary significantly. It makes little sense to force a system into place that does not match the individuals that work within it.

    The ninth law of agile physics:

    There is a champion for every cause, at least for awhile.

    We seem to be in an age where powerful advocates can drum up support for any new management concept. In the past, we’ve seen development impacted by waterfall, spiral, RUP, CMMi, TQM, BPR, Outsourcing and a host of other improvement ideas all with strong advocates – some with mixed results. Recently, we’ve seen acceptance for agile with a lot of demonstrated success from strong advocates.  We’ve also seen agile implemented as a justification for “no process” or “no testing.” Lately, “Agile 2.0” or the next generation of agile have been postulated. Advocates can be powerful change agents; they also can make unsound ideas seem attractive or implement them poorly. Balanced, appropriate, and incremental change usually wins out.

    Thus, my call for fundamental principles or “laws” as the foundation for building change and creating champions that can promote worthy causes and approaches that last.

    Credit: This post is developed from Wallace Hopp’s and Mark Spearman’s great book Factory Physics, Foundations of Manufacturing Management, Mcgraw-Hill/Irwin, 1996, chapter 12. 

    LiveJournal Tags: ,,

  • ,

    People Laws (part 1) 6th Law = Optimize the System

    “…when you cannot express it in numbers, your knowledge is of a meager and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in thought advanced to the stage of science, whatever the matter may be.”
    – Lord Kelvin

    “There is nothing new to be discovered in physics now. All that remains is more and more precise measurement.”
    – Lord Kelvin

    As I try to describe the laws of agile physics, I often feel that we – any of us – are barely beginning to postulate any true science.  However, I believe Lord Kelvin was wrong in both his quotes. I see value in expressing even those laws that are not quantifiable.  I’ve even tried to express laws that are based on math with simple statements of meaning. The important thing about laws or principles is that when violated there are consequences and costs. You don’t get full value without following them.

    In that spirit, I propose a some human element laws of agile physics in the next few posts.  These are not mathematical in basis and can only be quantified and optimized by trial and error, but they are no less important when ensuring agile processes are properly structured. They work together with value statements to direct successful agile development.

    The sixth law of agile physics:

    Optimize the entire system from the top down for maximum impact. Or the corollary, optimization happens only up to the lowest level of active management.

    It is important to understand that development happens at four or more levels in most organizations:

    • strategy/organization level – What competencies and products, what customer segments, what resources and funding, which opportunities exploited, what threats addressed, what broad timelines
    • product/group level – what architecture, what quality, what sales and support, what products
    • release/project level – which team, what features, what deliverables, what plan
    • individual/functional level – what tasks, what tools, what methods, what interactions

    While agile works at any of these levels, it is best applies from the top down. It does little good to cut in half the time to develop a widget, if it still takes multiple years to get it funded. There are few benefits in developing great features if sales cannot sell them or implementation takes longer.  It does little good to make development more productive if testing suffers or the wrong tasks get done faster.

    Agile’s benefits only rise to the lowest level of support.  A systems view from the top is needed to reap its full benefits.

    This means that agile practices need to be at least understood by executive level sponsors.  At best, it means they believe in and actively support them and use them to run the business at the highest levels. Agile practices should be used in Strategic Planning, Governance and Budgeting, Project Management Offices, and on Executive Teams.  Lacking a comprehensive approach, using the principles and applying the laws can only optimize part of the overall system.


  • ,

    5th Law = Variability Costs

    To follow up on the fourth law, I add as reinforcement the fifth law of agile quality Despair physics:

    If you cannot pay for variability reduction, you will pay in one or more of the following ways:

    1. Long iteration times and high story points in progress
    2. Wasted capacity or need for more resources
    3. Slower burn down rates

    Of course, the other option is to accept poor quality, which has an entirely different set of costs.  Either way,  the variably in a development process has real costs if not addressed.

    This means that if you don’t use variation remediation techniques like those introduced in the forth law discussion, you will pay the consequences in one or more of the ways listed.  Knowing you have a quality problem, you may:

    • Accept that it takes longer to produce the product
    • Increase available resources to address inspection and rework needs
    • Accept that less gets completed in each iteration

    So, what is the cost of quality? Many will argue that if you want a quality process, you will pay more. This may be true if the alternative is accepting a low quality product (a Yugo.)  But, at the same quality levels, you will either pay early to reduce variability and build in quality or pay later through one or more of the fifth law impacts.

    Given the second law of development physics, likely, the pay later route ultimately costs more. Or, to quote Deming, “Cutting costs without improvement of quality is futile.”

    Credit: I continue to be in debt to Wallace Hopp’s and Mark Spearman’s great book Factory Physics, Foundations of Manufacturing Management, Mcgraw-Hill/Irwin, 1996. If you want to explore the math of these forth and fifth laws, see chapter 9, specifically 9.4.2 Analytic Insight.


About Me

The sky is not completely dark at night. Were the sky absolutely dark, one would not be able to see the silhouette of an object against the sky.

Follow Me On

Subscribe To My Newsletter

Subscribe for new travel stories and exclusive content.