Tag Archives: Ideas

Unpacking the Fifth Principle of the Agile Manifesto

Learn more about transforming people, process and culture with the Real Agility Program

The Agile Manifesto was signed and made public in 2001. It begins with short, pithy statements regarding what should be the priorities of software developers, followed by Twelve Principles. In this article I want to call attention to the fifth principle in the Agile Manifesto, which is:

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”


Although it appears to be a very simple statement, I suggest that it is jam-packed with profitable guidance, and is essential to, and at the heart of, real Agility. Human qualities must be considered.


The first part of the principle urges us to build projects around motivated individuals.  What does this imply?

The idea of “building a project” makes it a process, not necessarily a fait accompli. It can change and be altered as one works toward it. There may be a structural roadmap, but many details and aspects can change in the “building.”

The second part of the statement describes motivated individuals. The verb “motivate” is an action word, meaning to actuate, propel, move or incite. Thus, in this line, is the “project” the thing which will “move or incite” those being asked to carry it out?

Or do we understand this to imply that the individuals are already “motivated” in themselves, which is an emotional condition of individuals? Is this motivation already there prior to starting a project?

The topic of motivation is rich. How does motivation occur? Is it the culture and environment of the company, lived and exemplified by it’s leaders, which motivates? Or is motivation an intrinsic quality of the individual? It may be both. (Daniel Pink, author of “Drive,” uses science to demonstrate that the best motivators are autonomy, mastery and purposeful-ness – ideas which are inherent in the Agile Manifesto.)

In any case, the line itself suggests that the project may be a) interesting to pertinent (perhaps already motivated) individuals, b) do-able by those same individuals, and c) contains enough challenges to test the mastery and creativity of the individuals. In other words, it’s going to be a project that the individuals in your company care about for more than one reason.


The second line from the fifth Principle has two distinct parts to it. The first part, “Give them the environment and support they need” puts a great deal of responsibility on whoever is assigning the project. Let’s look at the idea of environment first.

In a simple way, we can understand environment as the physical place which influences a person or a group. It can be any space or room; it can refer to the lighting, the colours, the furniture, the vegetation, the walls, whether water or coffee is available – physical elements which will certainly affect the actions of people and teams. For example, creating face-to-face collaboration environments is also part of the Agile Manifesto.

But we must remember that environment also entails the non-physical ie, the intellectual, emotional, or even the spiritual. Is the environment friendly or not? Cheerful or not? Encouraging or not? Affirming or not? We can think of many non-physical attributes that make up an environment.


These attributes allude to the second part of what’s to be given by an owner or manager: “…and support they need.” This idea of support pertains not just to helping someone out with tools and responding to needs, but that the environment is supportive in every way – physically, intellectually, emotionally and spiritually. This may be a more holistic way of considering this Agile principle.

The last part of the statement is of great importance as well: and trust them to get the job done.

If you as product owner, or manager have created motivation, environment and support, then the last crucial requirement of trust becomes easier to fulfill. There is nothing more off-putting than being micromanaged, supervised or controlled with excessive attention to small details. Trust means you have confidence in the capacity of your team and its individual members. It also implies that they will communicate with transparency and honesty with you, and you with them, about the project.


The principles of Agile do not exist in a vacuum, because, of course, other principles such as the following, are relevant to this discussion:

The best architectures, requirements, and designs emerge from self-organizing teams.”

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”

This fifth principle has application far beyond IT projects. I wanted to reflect on it because it speaks to human qualities, which must be recognized as a key factor in happy work places, and in any high-performance team.

Valerie Senyk is a Customer Service agent and Agile Team Developer with BERTEIG.

For more information please go to http://www.worldmindware.com/AgileTeamDevelopmentWorkshopStage1

Also read about BERTEIG’s RealAgility Program: http://www.berteig.com/real-agility-enterprise-agility/

Please share!

How Kanban Saved Agile

Learn more about transforming people, process and culture with the Real Agility Program

In reality, Kanban isn’t actually saving Agile nor is it intended to, nor is any thoughtful and responsible Kanban practitioner motivated by this agenda. What I’m really trying to convey is how human thinking about the business of professional services (including software development) has evolved since “Agile” as many of us know it was conceived around 20 or so years ago. The manifesto is the collective statement of a group of software development thought leaders that captured some of their ideas at the time about how the software industry needed to improve. Essentially, it was about the iterative and incremental delivery of high-quality software products. For 2001, this was pretty heady stuff. You could even say that it spawned a movement.

Since the publication of the manifesto in 2001, a lot of other people have had a lot of other good ideas about how the business of delivering professional services can improve. This has been well documented in well known sources too numerous to mention for the scope of this article.

Substantial contributions to the discourse have been generated by and through the LeanKanban community. The aim of Kanban is to foster environments in which knowledge workers can thrive and create innovative, valuable and viable solutions for improving the world. Kanban has three agendas: survivability (primarily but not exclusively for the business executives), service-orientation (primarily but not exclusively for managers) and sustainability (primarily but not exclusively for knowledge workers). Kanban provides pragmatic, actionable, evidence-based guidance for improving along these three agendas.

Evolutionary Theory is one of the key conceptual underpinnings of the Kanban Method, most notably the dynamic of punctuated equilibrium. Evolution is natural, perpetual and fundamental to life. Long periods of equilibrium are punctuated by relatively short periods of “transformation”—apparent total and irreversible change. An extinction event is a kind of punctuation, so too is the rapid explosion of new forms. Evolutionary theory is not only a scientifically proven body of knowledge for understanding the nature of life. It can be also applied to the way we think about ideas, methods and movements.

For example, science has more or less established that the extinction of the dinosaurs, triggered by a meteor impact and subsequent dramatic atmospheric and climate change, was in fact a key punctuation point in the evolution of birds. In other words, dinosaurs didn’t become extinct, rather they evolved into birds. That is, something along the lines of the small dinosaurs with large feathers hanging around after Armageddon learned to fly over generations in order to escape predators, find food and raise their young. Dinosaurs evolved into birds. Birds saved the dinosaurs.

There has been a lot of social media chatter and buzz lately about how Agile is dead. It is a movement that has run its course, or so the narrative goes. After all, 20 years is more or less the established pattern for the rise and fall of management fads. But too much emphasis on the rise and fall of fads can blind us to larger, broader (deeper) over-arching trends.

The agile movement historically has been about high-performing teams. More recently, market demand has lead to the profusion of “scaling” approaches and frameworks. Scaling emerged out of the reality of systemic interdependence in which most Agile teams find themselves. Most agile teams are responsible for aspects of workflows—stages of value creation—as contributors to the delivery of a service or multiple services. Agile teams capable of independently taking requests directly from and delivering directly to customers are extremely rare. For the rest, classical Agile or Scrum is not enough. The feathers just aren’t big enough. Agile teams attempting to function independently (pure Scrum) in an interdependent environment are vulnerable to the antibodies of the system, especially when such interdependencies are merely denounced as impediments to agility.

Some organizations find themselves in a state of evolutionary punctuation (the proverbial sky is falling) that can trigger rapid adaptations and the emergence of local conditions in which independent service delivery teams can thrive. Most large, established organizations seem to be more or less in a state of equilibrium. Whether real or imagined, this is what change agents have to work with. However, more often than not, the typical Agile change agent seems adamant that the sky is always falling and that everyone accepting that the sky is falling is the first step to real and meaningful change. This is not an attitude held by Agile change agents alone. This is a standard feature of traditional 20th Century change management methods, the key selling point for change management consulting.

Naturally, most self-identifying “Agilists” see themselves as change agents. Many of them find themselves in the position of change management consultants. But the motivation for change can quickly become misaligned: Change needs to happen in order for Agile to work. If you are passionate about Agile, you will seek to bring about the environmental changes that will allow for Agile to thrive. We don’t need to follow this path too far until Agile becomes an end in itself. It is understandable then that for some, Agile appears to be a dead end, or just dead.

But if there is a larger, over-arching historical process playing out, what might that be? Perhaps it has something to do with the evolution of human organization. Perhaps we are living in a period of punctuation.

For my working definition of Kanban, please refer to my previous article 14 Things Every Agilist Should Know About Kanban (this contains links to the Kanban body of knowledge, including Essential Kanban Condensed by David J. Anderson and Andy Carmichael).

For my working definition of Agile, please refer to The Manifesto for Agile Software Development.



Please share!

Are You Getting What You Need From Conferences?

Learn more about transforming people, process and culture with the Real Agility Program

(Originally posted in June 2015 – Updated October 2016)

Photo Credit: BERTEIG’s Valerie Senyk facilitated a group session on “What Do We Mean by Transformation?” in Orlando 2016.

Professional Development opportunities are everywhere and they are easy to find at any price-point on any topic at any location. The hard part is deciding how to spend your time.

It is important to think about why you attend conferences. Most importantly, why do you choose some conferences over others? Do you want to learn from peers in your field? Do you want exposure to the latest industry trends? Are you looking for a new job? Or do you just want to be blown away by great people?

I attended the Agile Coach Camp Canada last weekend in Cornwall, Ontario, and that incredible experience has caused me to reflect on the variety of conferences I have enjoyed in recent years…and why I choose some over others.

Like any great product, successful conferences have clear and focused goals which create specific opportunities for their participants. Conference organizers choose location, venue, date, duration, registration cost, format, theme, etc. The best conference organizers are courageous and willing to make difficult decisions in order to compose their events with utmost respect to the collective vision and goals of the attendees, sponsors, and founders. The organizers of Agile Coach Camp Canada, for example, are dedicated to creating an event in which the agile coaching community can “share in an energizing and supportive environment”. That’s it! A clear and compelling vision. This clarity of vision guides decisions like whether to host the event in a metropolis (which may result in larger numbers and more sponsorship opportunities) or away from large cities (think overnight “camp”) — this is one formative decision of many that make Agile Coach Camp Canada so intense and unique year after year.

Some background: This was the 6th annual Agile Coach Camp Canada and the 2nd time that I have attended; the event generally starts on Friday evening and includes supper followed by lightning talks, Saturday uses Open Space Technology to produce an agenda followed by supper and socializing (late into the night!), then Sunday morning wraps-up with retrospection then everybody leaves in early afternoon; the cost per person is between $300-$500 for the entire weekend including meals, travel, hotel room; the event is often held in small-ish towns like Guelph or Cornwall which are a few hours from a major airport. Having been there twice — both times just blown away by the community, their expertise, their emotional intelligence, their openness — I understand very clearly the responsibility of conference organizers and I have gained new respect for the difficult decisions they must make.

Upon reflection, I know that I attend the Agile Coach Camp Canada because (a) I learn a lot and (b) I have bonded deeply with my colleagues. Those are the two reasons that I will return next year and the next. I do not attend that event with an expectation to develop new business, or attract new leads, or stay on top of industry trends — instead, I will look to other conferences for those opportunities.

What/where/when is your next professional excursion? Do you know what you want to get out of it? Here’s a tip: choose one objective from the list below and find a conference that delivers exactly that!

  • Business development: Find new or reconnect with existing business contacts.
  • Professional development: Find or explore opportunities for career enhancement.
  • Learning: Listen/watch/share with others who practice in your areas of interest.
  • Community building: Connect and communicate with people with interests or qualities that you appreciate.
  • Market exposure: Evangelize a product or service for a captive audience.
  • Other?

Life is short…make it amazing!

Please share!

The Rules of Scrum: Your Product Owner can veto the inclusion of an idea on the Product Backlog

Learn more about transforming people, process and culture with the Real Agility Program

The Product Owner is responsible for ensuring that the Product Backlog Items reflect and contribute to the vision of the product being built by the Scrum Team. Therefore, the Product Owner needs the authority to reject any suggestions for features, functionality or fit and finish that do not move the product towards that vision. This authority must be based on both the depth of knowledge of the Product Owner as well as formal responsibility granted by the organization. A Product Owner that does not have this authority to veto may nevertheless be able to accomplish the same thing by putting any unwelcome ideas at the very end of the Product Backlog based on authority to order the Product Backlog. The lack of this authority to veto can lead to a product with no integrity of vision, an erosion of the Product Owner’s authority to order the Product Backlog, and ultimately an erosion of the critical separation of powers between the Product Owner and the rest of the Scrum Team (the Product Owner with authority over “what to build” and the rest of the team with authority over “how to build it”).

To learn more about Product Owners, visit the Scrum Team Assessment.

Please share!

Professionalism and Agility

Learn more about transforming people, process and culture with the Real Agility Program

Recently, I have been reading Outliers by Malcolm Gladwell. Fascinating reading. In this book, Mr. Gladwell chronicles some of the backgrounds of top professionals in artistic, sport and business endeavors. He tried to determine why these individuals/groups have accomplished so much in their lives and why they are in the top of their profession. Tiger Woods, Bill Gates and the Beatles are a few of the many professionals he examines. There should be no doubt in your mind that Tiger Woods is the top golfer, Bill Gates is a very successful entrepreneur, and the Beatles are a prolific band.

Please forgive me Mr. Galdwell if I summarize and distill your findings into a few short sentences. The answer is 10,000 hours. Each of these individuals or groups put 10,000 hours into their chosen profession before they arrived at the top. They viewed their professions differently, were passionate about what they did and behaved differently when learning their profession. I am not suggesting you need to work for 10,000 hours before you are successful. I am suggesting if you adopt the same methods they do, you will increase your chance of success.

As I observed these top professionals, I began to see similarities in a number of areas. They seem to share a comfort in their ability to grow and develop. I am not sure they set out to be the top but they certainly thought they would overcome what life threw at them and they trusted their own capacity to excel. I have found that giving yourself a steady message of what is possible helps you deal better with life and to overcome all the negatives around us. As an example, I seldom read the newspaper or watch the news, for this barrage of negative messages affects my outlook of what is possible. It seems to me that these top professionals insulate themselves from negative messages as well.

Next, they have incredible self discipline skills. They practice their profession with passion. They don’t believe in luck as much as they believe in hard work. This is where the 10,000 hours come into their development. They are constantly practicing to improve and master their profession. The top professionals did not achieve their position through luck, they attained the position through hard work.

To summarize, their methods are to be positive about your ability to cope with the future, give yourself positive messages, be disciplined about mastering your profession and be prepared to work hard to achieve the position of the professional.

There is a quote I like that was told to me by a businessperson from Jamaica. When asked his view of life, he said “I refuse to be held hostage by circumstances!” The top professionals choose their future and are agile as they cope with what life offers.

It seems to me another reason why these individuals are so successful is that they were very agile in their approach to life. They created their future rather than follow others. Through their own personal agility they made the right decisions to gain a top position in their chosen profession.

So the question I have been wrestling with is this: If they can be the top, then why not me? What is holding me back? Well, if you have ever spent time with me, or read any of my books, you would know the answer. The only thing holding me back is me. Can I get better? Yes, I can. Can I work harder? Yes, I can. Can I be more successful? Yes, I can. Can I be more agile in my approach to life and its challenges? Absolutely yes!

So how about you? In these troubled economic times, we have an opportunity to re-invent ourselves. The best way to survive and thrive from our current situation is to build the future we desire. Rather than expending a lot of energy worrying about your current situation, you should be taking that energy and using it to take charge of your future and build a new reality. Approach whatever life throws at you with agility. I believe success is a choice. Make good choices and everything is possible.

Please share!

Measuring Process Improvements – Cycle Time?

Learn more about transforming people, process and culture with the Real Agility Program

One of the challenges with agile methods is to get a clear perspective on how to measure process improvements. I recently had a brief discussion with a C-level executive at a small organization about this. His concern was that cycle time was meaningless because it depended so much upon the size of the work package. So how do we use cycle time as a meaningful measurement? What else can we use to measure process improvement?

Let’s look at the difference in measuring cycle time in an agile vs. non-agile environment. Then we’ll get to other measurements.

Cycle Time , Waterfall and Agile

First, let’s define cycle time. From iSixSigma we have:

Cycle time is the total time from the beginning to the end of your process, as defined by you and your customer. Cycle time includes process time, during which a unit is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action.

This definition is important because it gives us a clue about the potential difference between a waterfall vs. agile method of delivering value. Let’s imagine the typical process used in a waterfall environment. The following are the high-level steps:

  1. Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled. This is when we start the clock on cycle time.
  2. The fulfillment organization (IT, Product Development, R&D) puts the request in a queue, backlog or requirements management system.
  3. Along with other requests, the fulfillment organization schedules the work on the request, usually by creating a project to fulfill it and other related requests. The project is estimated at a high level, the current status of in-flight projects is noted, and the new project is prioritized relative to other projects.
  4. At some point, based on the schedule and the reality of the work on other projects, the project containing our customer’s request is started. Here, “started” means that detailed requirements are gathered.
  5. After sufficient requirements are gathered, a detailed technical analysis is done including architecture, high-level design, risk analysis, etc.
  6. Development begins. (Note: many people mistakenly start measuring cycle time here.)
  7. Developers and testers work to validate the results of development and fix any problems discovered.
  8. Final acceptance testing is done.
  9. The results of the project are deployed to users, sold to the client, or in some other way passed back to the original requestor. This is when we stop the clock on cycle time.

So from the start of the customer request formally submitted to the time that the fulfillment of that request is made is our true cycle time. There are a few important things to note here. First, there is a queue of work based on requests made but not yet scheduled. There is another queue for work scheduled but not yet started. We know that if we can reduce the size of these queues, we can improve cycle time in a general sense. Second, we know that most organizations of any significant size will have different queues based on the urgency of the request. For example, a high severity bug discovered in the production system of a company’s largest client will be treated differently than a wish list item for a small not-yet-client. These two requests won’t even go in the same queue: the high priority problem will be quickly escalated to a support or development team that can work on it immediately. Third, it is tempting for the development group to measure their local cycle time. This is a Really Bad Idea since it leads to sub-optimizing behaviors. For example, it is easy for the development team to improve their cycle time by sacrificing quality… but this just causes the QA cycle time to increase, and probably the overall cycle time (true cycle time) is affected more than the local improvement in the development group’s cycle time.

Now let’s look at the steps that occur in an ideal agile environment:

  1. As before, the Customer / User / Stakeholder sees a need, validates it and submits a request to have that need fulfilled.
  2. That request is immediately placed in a ready state for the next iteration (cycle, sprint) of a delivery team. Elapsed time: maximum one month.
  3. Team completes the request including all work to actually deliver/deploy and work is delivered to the stakeholder at the end of the iteration. Elapsed time: maximum two months.

So the ideal method of doing agile has a maximum cycle time of two months to deliver from the time a request is made… how many teams are doing this? Not many.

The ideal is extremely difficult to accomplish. Getting to that state requires that the development organization catches up to the business side so that there are zero pending requests at the start of each iteration. It also requires that the business side users and stakeholders are able to articulate their requests so that they are small, and appropriately detailed for the team doing the work.

A realistic agile implementation actually is a lot more messy. Depending on the type of request, the cycle time for a piece of work can vary widely. Some low priority items may take years even in an agile environment. A low priority request is made and approved but then never quite makes it into a project… and then once in a project never quite makes it to the top of the team’s product backlog. This is interesting to look at sometimes, but it points out another important aspect of measuring cycle time: mostly we care about average cycle time (or some other statistically interesting aggregate measure).

The predominant factor in most organizations’ cycle time is the number and size of the queues they use as work is processed. In most organizations there are several queues and most of them contain large numbers of requests or bits of work in process. Queues represent huge amounts of waste. It is easy to see that queue size and cycle time are closely related: the more items in a queue, the longer the cycle time.

This leads to a simple conclusion: regardless of lifecycle approach, reducing the size of an organization’s queues is one of the easiest ways to reduce cycle time. What are some common queues? There are often queues of projects, queues of enhancement requests, queues of defects to be fixed, queues of features, queues of tasks, queues of email (large inboxes), queues of approval requests, queues of production database changes. The number of queues increases the more an organization is oriented around functional groups, and the number of queues decreases the more an organization arranges work to be handled by cross-functional teams.

Cycle Time and Work Package Size

This is where queueing theory and agile methods intersect really well. Cycle time is related to the load on your system, in particular your units of work processing. In most organizations, teams are created to handle work. The more work given to a team simultaneously, the higher their utilization level. Many organizations like high utilization levels because it gives them a guarantee that people are doing valuable work all the time that they are paid to work. This is a completely false benefit and in fact is extremely destructive to overall productivity. From queueing theory we know that the cycle time for a piece of work increases exponentially to the utilization level. We see this whenever we over-load a server… but for some reason we fail to see this when we overload a person or a team or an organization even though it still happens.

Cycle time is also related to the variability in the size of the work packages. Low variability means that the exponential factor related to load is low, and high variability means that the exponential factor is high. In other words, if you have a highway that only allows motorbikes, you can have a very high load without getting bad traffic jams. On the other hand, if you have a highway that allows anything on it, you get traffic jams even with low levels of load. This is why HOV or commuter lanes and the left lane in multi-lane highways don’t typically allow transport trucks and buses. This result from queueing theory is not intuitively obvious so it is even harder for us to apply to software development.

But apply these two ideas, load and work size variability, we must if we wish to create a high performance development organization. The simplest way to do this is to have a single team work on a single project at a time and use iterations to ensure that the work being done is always exactly the same size – the size of the iteration.

Improving Cycle Time

It is possible to have very short iterations and still have a long cycle time. Many organizations make a few common mistakes with agile that cause this. If the work done inside each iteration is restricted to pure development work and everything else is done outside the iterations, then cycle time likely stays long. A common example of this is having the QA folks remain separate from the development team and do their work after a development team releases their work.

There is really only one way to avoid this: have a comprehensive definition of “done” that is met by the team every single iteration. This ensures that all work from idea to release for a given customer request is done inside a single iteration. A side effect of this is that all the pieces of work need to be small. It also gets rid of all the queues except one: the queue of ideas approved for delivery. With a single queue to manage, it becomes easy to measure cycle time, and therefore easy to improve it.

Improving cycle time can now be done in a few ways:

  1. Put a cap on the number of items in the work queue. Since cycle time is directly related to the size of the queues in a system, this is a sure way of putting a maximum on cycle time.
  2. Go through all existing requests and throw as many away as possible. This can be tough to do, but if you are able to do a cost benefit analysis, you will typically find that older items in the queue are no longer worth while.
  3. Provide more stringent gating functions for allowing requests onto the queue. The few items added, the faster the size of the queue is reduced.
  4. And of course, increase the performance of your team(s) so that they go through items on the queue more quickly.

Productivity and Cycle Time

Once you have control of cycle time, it is possible to make reasonable measurements of productivity and two more metrics become extremely important (not that they weren’t important before, but they are easier to work with now). The first is Return on Investment (ROI) and the second is customer satisfaction.

ROI is in its simplest form a measure of how much benefit there is to doing something as compared to the cost of doing it. It takes into account the importance of time and timing, the importance of other options you may have, and of course, hopefully takes into account the business reality of your work. It also takes into account costs.

In software development, the primary cost is the cost of the staff doing the work, and the time factor is your cycle time (Ah! that’s where we use it). If you have a consistent team working on iterations that are always the same size and if you have little or no work being done outside of the iterations, it is very easy to calculate ROI in a useful way. Simply measure how much value a given iteration worth of work will generate and divide by the cost of the team for an iterations (and if the team is not yet doing work as it comes in, take into account the time value of money since the work might not be done for several iterations). Now, productivity is simply a measure of the Return for each Team-Iteration. Dollars/iteration. Simple. If the team’s productivity goes down, you can ask some really simple questions:

  • Did the expected return of the work go down? If so, is there more valuable work the team should be doing? This becomes an opportunity for product improvement.
  • If not, what caused the team to get less done? Was the work harder than expected? Was there a skill gap? Was there an organizational obstacle that was revealed? Was someone sick? This becomes an opportunity for process and team improvement.

Customer satisfaction can be measured in many ways. If you have already started using agile practices, there is a good chance that your customers will already be more satisfied than they were before. This will show up informally through word-of-mouth. However, it is good to have a more systematic way of measuring customer satisfaction. One of the simplest and most commonly used methods of measuring customer satisfaction is the Net Promoter Score. From WikiPedia:

Companies obtain their Net Promoter Score by asking customers a single question (usually, “How likely is it that you would recommend us to a friend or colleague?”). Based on their responses, customers can be categorized into one of three groups: Promoters, Passives, and Detractors. In the net promoter framework, Promoters are viewed as valuable assets that drive profitable growth because of their repeat/increased purchases, longevity and referrals, while Detractors are seen as liabilities that destroy profitable growth because of their complaints, reduced purchases/defection and negative word-of-mouth. Companies calculate their Net Promoter Score by subtracting their % Detractors from their % Promoters.

The Net Promoter Score is closely linked to quality including the hard-to-measure parts of quality like responsiveness, ease of use, and fitness for purpose.

Cycle time also affects customer satisfaction. The faster you can respond to requests by customer, users or other stakeholders, the more likely they are to be satisfied. This happens for two reasons: fast response time means that solutions are more likely to still be useful and correct when actually delivered, and it also gives more opportunities for feedback.

In fact, if we look at these three measures, cycle time, ROI and customer satisfaction, we see that they form a mutually supporting and cross-checking system of ensuring productivity and effectiveness. Measuring anything else muddies the waters and can cause sub-optimal behaviors. The real challenge for most teams is realizing that all their local measures of performance and effectiveness may actually be causing harm (unintentionally) because they draw the team’s attention away from the three organizationally important measures.

Cycle time is the measure that is most closely related to process improvements, but ROI and customer satisfaction should also be used to ensure that process improvements don’t accidentally harm the organization.

Please share!

Dynamic Strategic Planning

Learn more about transforming people, process and culture with the Real Agility Program

I ran across this idea of Dynamic Strategic Planning [pdf] a couple nights ago at a meeting where a friend and I were talking about agile applied to non-technology work. He told me about Richard de Neufville who had come up with this concept of making strategic plans that were adaptable. It involves the use of Real Options, negotiation and other aspects of planning. I don’t know anything more than what is written in the paper I have linked to… do any of you have experience with Dynamic Strategic Planning that you could tell us about? Are there any good books about this that you would recommend?

Please share!

Truthfulness in Agile

Learn more about transforming people, process and culture with the Real Agility Program

I believe in Agile. To the best of my knowledge and based on my experience, Agile methods are the best way for teams, organizations and communities to get stuff done. Doesn’t mean it’s easy though! The biggest challenge of Agile is in the need for truthfulness.

Continue reading Truthfulness in Agile

Please share!

Stuck? Try Extreme Obstacle Removal!

Learn more about transforming people, process and culture with the Real Agility Program

What happens when you are iterating away, your team is totally groking agile, delivering great results every couple of weeks, and then unexpectedly, suddenly and firmly everyone is stuck!? An obstacle has come along that forces a full stop. A barrier has been placed in the path. What do you do?

Continue reading Stuck? Try Extreme Obstacle Removal!

Please share!

Time is Not Negotiable

Learn more about transforming people, process and culture with the Real Agility Program

The Project Management Institute refers to three variables that can be negotiated or constrained for a given project: scope, resources and schedule. Schedule is an interesting “variable” in that we have no choice about how time flows. We can control how much scope to ask for, we can control how much money to put towards the work, but we cannot actually “buy” more time than, say, our competitors. This has important implications which deeply challenge the PMI’s PMBoK model of project management.

Continue reading Time is Not Negotiable

Please share!

Agile is Not Communism

Learn more about transforming people, process and culture with the Real Agility Program

Last week I taught an introductory course on Agile Work. Normally this is pretty easy stuff. However, I was teaching this course in Bucharest, Romania (cool), and I have come across a substantial, strong and vigorous objection to agile (also cool, but challenging too). Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either. I’m looking for help on this!

Continue reading Agile is Not Communism

Please share!

Never Spread Your Facilitator Butter too Thin

Learn more about transforming people, process and culture with the Real Agility Program

I like butter, and when I eat a piece of freshly baked bread, a good hunk of butter thickly spread is an essential ingredient. I don’t skimp on the butter. Using the butter for one piece of bread and spreading it across two or three slices saves cost, but at what price!? Why, the price is my enjoyment.

So how does this relate to Process Facilitators?

Continue reading Never Spread Your Facilitator Butter too Thin

Please share!

The Inner Ring

Learn more about transforming people, process and culture with the Real Agility Program

Here’s a slightly off-topic, but nevertheless excellent read: “The Inner Ring” by C S Lewis. This is a talk given by C S Lewis to what seems to be a group of university students. In it, he describes the notion of the inner ring and the desire to be “in”. It is amazing how much our culture in North America and our corporate culture is driven by this desire. I’ll leave it to you to decide if this is good or bad.

Please share!

Technical Debt

Learn more about transforming people, process and culture with the Real Agility Program

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…

Continue reading Technical Debt

Please share!