Over the last year or so I’ve spent quite a bit of time working with puppet and one of the things that we had to decide when installing packages was whether or not to specify a particular version.

On the first project I worked on we didn’t bother and just let the package manager chose the most recent version.

Therefore if we were installing nginx the puppet code would read like this:

package { 'nginx':
  ensure  => 'present',
}

We can see which version that would install by checking the version table for the package:

$ apt-cache policy nginx
nginx:
  Installed: (none)
  Candidate: 1:1.2.6-1~43~precise1
  Version table:
     1:1.2.6-1~43~precise1 0
        500 http://ppa.launchpad.net/brightbox/ruby-ng/ubuntu/ precise/main amd64 Packages
     1.4.0-1~precise 0
        500 http://nginx.org/packages/ubuntu/ precise/nginx amd64 Packages
     1.1.19-1ubuntu0.1 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise-updates/universe amd64 Packages
     1.1.19-1 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages

In this case if we don’t specify a version the Brightbox ’1:1.2.6-1~43~precise1′ version will be installed.

Running dpkg with the ‘compare-versions’ flag shows us that this version is considered higher than the nginx.org one:

$ dpkg --compare-versions '1:1.2.6-1~43~precise1' gt '1.4.0-1~precise' ; echo $?
0

From what I understand you can pin versions higher up the list by associating a higher number with them but given that all these versions are set to ’500′ I’m not sure how it decides on the order!

The problem with not specifying a version is that when a new version becomes available the next time puppet runs it will automatically upgrade the version for us.

Most of the time this isn’t a problem but there were a couple of occasions when a version got bumped and something elsewhere stopped working and it took us quite a while to work out what had changed.

The alternative approach is to pin the package installation to a specific version. So if we want the recent 1.4.0 version installed we’d have the following code:

package { 'nginx':
  ensure  => '1.4.0-1~precise',
}

The nice thing about this approach is that we always know which version is going to be installed.

The problem we now introduce is that when an updated version is added to the repository the old one is typically removed which means a puppet run on a new machine will fail because it can’t find the version.

After working with puppet for a few months it becomes quite easy to see when this is the reason for the failure but it creates the perception that ‘puppet is always failing’ for newer people which isn’t so good.

I think on balance I prefer to have the versions explicitly defined because I find it easier to work out what’s going on that way but I’m sure there’s an equally strong argument for just picking the latest version.

Today and tomorrow, for that limited time, we have a special promotion on this course. CSM + Workshop in Atlanta, May 6-8.

10% off, if you are a member of a local group. Agile, PMI or SPIN.

Details are here or here.

Next weekend the sponsor AngleHack and two student groups at UCLA are throwing a huge hackathon. LAHacks will bring together students and alumni from Southern California’s premier technical schools in hopes of fostering a more cohesive start-up community. It seems that So Cal is struggling to create the same kind of start-up magic that Boston, New York City, and the San Francisco Bay area have achieved. Hackathons are becoming more popular and are a Scrum Pattern for good reason. First, they bring people together in a creative and voluntary environment. This encourages people to bond over activities of their choice, helping team members to form stable relationships, which can lead to better team performance and collaboration.
Second, they produce interesting results.  Facebook has been throwing hackathons since 2007. These all-night coding sessions have produced many valuable features for the social media giant including the Like Button, Timeline and Chat.
Third, if used strategically, Hackathons can slow development down a bit, allowing the organization to deal with constraints in other divisions.
But most importantly, they help developers merge their personal interests with their company’s financial interest. Hackathons give workers the opportunity to have a meaningful relationship with their employer by giving them the autonomy to master features and products that they enjoy while creating value for their company.  Research shows again and again that mastery, autonomy and contributing to a community motivates people much more than higher salaries. Hackathons allow workers to help their company and colleagues, plus they aid in recruiting and retaining a motivated workforce.
Scrum Inc. recommends that companies throw hackathons regularly to free people up to be more creative and interactive. The value of hackathons is hard to quantify but one quick look at Google, which allows their employees to work on personal projects 20% of the time shows that when a company emphasizes creativity, awesome things happen.
-- Joel Riddle

In the last few posts on sagas, we looked at a variety of patterns of modeling long-running business transactions. However, the general problem of message routing doesn’t always require a central point of control, such as is provided with the saga facilities in NServiceBus. Process managers offer a great deal of flexibility in modeling complex business processes and splitting out concerns. They come at a cost though, with the shared state and single, centralized processor.

Back in our sandwich shop example, we had a picture of an interaction starting a process and moving down the line until completion:

Not quite clear in this picture is that if we were to model this process as a saga, we’d have a central point in which all messages must flow to for decisions to be made on the next step. But is there really any decision to be made in the picture above? In a true saga, we have a sequence of steps and a set of compensating actions (in a very simplistic case). Many times, however, there’s no need to worry about compensations in case of failures. Nor does the order in which we do things change much.

Humans have already found that assembly lines are great ways of breaking down a long process into individual steps, and performing those steps one at a time. Henry Ford’s Model T rolled off the assembly line every 3 minutes. If only one centralized worker coordinated all steps, it’s difficult to imagine how this level of throughput could be achieved.

The key differentiator is that there’s nothing really to coordinate – the process of steps is well-defined and known up front, and individual steps shouldn’t need to make decisions about what’s next. Nor is there a need for a central controller to figure out the next step – we already know the steps up front!

In our sandwich model, we need to tweak our picture to represent the reality of what’s going on. Once I place my order, the sequence of steps to fulfill my order are known up front, based on simply examining my order. The only decision to be made is to inspect the order and write the steps down. My order then flows through the system based on the pre-defined steps:

 

Each step doesn’t change the order, nor do they decide what the next step is (or even care who the next step is). Each step’s job is to simply perform its operation, and once completed, pass the order to the next step.

Not all orders have the same set of steps, but that’s OK. As long as the steps don’t deviate from the plan once started, we don’t need to have any more “smarts” in our steps.

It turns out this pattern is a well-known pattern in the messaging world (which, in turn, borrowed its ideas from the real world): the routing slip pattern.

Routing slips in NServiceBus

Routing slips don’t exist in NServiceBus, but it turns out it’s not too difficult to implement. A routing slip represents the list of steps (and the progress), as well as a place for us to stash any extra information needed further down the line:

    public interface IRoutingSlip
    {
        Guid Id { get; }
        IEnumerable<IProcessingStep> ProcessingSteps { get; }
        IDictionary<string, string> Attachments { get; }
    }

We can attach our routing slip to the original message, so that each step can inspect the slip for the next step. We’ll kick off the process when we first send out the message:

Bus.Route(sandwichOrder, new[]
{
	"Preparation",
	"Oven",
	"Packing",
});

Each handler handles the message, but doesn’t really need to do anything to pass it down the line, we can do this at the NServiceBus infrastructure level.

public class PackingHandler 
	: IHandleMessages<SandwichOrder>
{
	public void Handle(SandwichOrder message)
	{
	    // pack the sandwich
	}
}

The nice aspect of this model is that it eliminates any centralized control. The message flows straight through the set of queues – leaving out any potential bottleneck our saga implementation would introduce. Additionally, we don’t need to resort to things like pub-sub – since this would still force our steps to be aware of the overall order, hard-coding who is next in the chain. If a customer doesn’t toast their sandwich – it doesn’t go through the oven, but we know this up front! No need to have each step to know both what to do and what the next step is.

I put the message routing implementation up on NuGet and GitHub, you just need to enable it on each endpoint via configuration:

public class Startup : IWantCustomInitialization
{
	public void Init()
	{
	    Configure.Instance.RoutingSlips();
	}
}

If you need to process a message in a series of steps (known up front), and want to keep individual steps from knowing what’s next (or introduce a central controller), the routing slip pattern could be a good fit.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

As I sit here with my red-wine glass and contemplate the #NoEstimates discussion on Twitter for the last few days I can’t help but think that there is a key difference in how I look at Software development when compared with some of the Agile Pioneers like @RonJeffries, or @TOtherAlistair. And I want to explain some of those differences. They are too important to our profession to go undiscussed. Tired of the same old house First, I’d like to state that I don’t think that the construction analogies are of use anymore. It was ok to use that in the beginning of software development. Those were the most well-researched projects at that time. However, today we have a sufficient body of knowledge to warrant research and analogies from within our domain.
Also, while I know some will claim this is a gross generalization (and it is), construction is not in the Complex domain, while software is. If you follow any of the #Cynefin discussions you know that approaches suited to the Simple domain are not suited to the Complex domain. In my view most construction projects are in the Simple domain (not all), and most software projects are in the Complex domain (again, not all). Change the context, or your project will fail One other thing that makes me focus on the #NoEstimates approach to software development is my realization that the existing context is not well suited to software development. The context where Estimates are mandatory, and you will be held accountable for years to come; the context where teams are asked to “commit” to a plan that they know very well may not be possible to achieve; the context where we base all of our approaches on our belief that predictability is easily achievable in long term software development efforts.
I want to promote the #NoEstimates approach because I want to change the context surrounding software development. I’ve learned enough to know that software estimates don’t work, and I know a better alternative!
It’s the customer, simply! My approach to implementing #NoEstimates is centered on discovering value, because I assume that I don’t have all the answers up-front. Since I recognize that I don’t have all the answers, I’m ready to accept that the definition of the work to be done will change (not might, will!). So I focus my energy on discovering that most valuable work to be done. This requires that I focus on defining small increments of customer-value (instead of large chunks of “work”). I use User Stories (and Epics and Features) to help me build a vocabulary that leads to a constant dialogue around value at all levels in the company. And I’ll let you in on a secret: Sales people don’t like estimates either! Why? Because they want something out ASAP and if you tell them that they need to wait another 6 months they will hate you. Estimates or no estimates. Sales people understand something intuitively: they need value to sell. The longer they wait the more uncertain they are about that value. It is that simple. I believe #NoEstimates is a better way to manage software projects It is this simple. I’ve used #NoEstimates, I recommend #NoEstimates and I use #NoEstimates in my own work. Discover the value, deliver the value in the thinnest slice possible, rinse and repeat.
There are many concrete ways in which you can generate dialog around value, and ways in which you can enable very thin slices. Some have been published (Naked Planning by @arlobelshee being one example), others are just being discovered and experimented with.
Estimates have failed, are you looking for alternatives? The Estimation approach to software development has failed us for too long. It never really worked in the projects I participated in (and I used it a lot) and we always ended up using the only available tool to us to meet our deadlines: manage scope.
So I recognize that an approach focused on helping companies and teams zero-in on the valuable parts of the their projects and delivering those first, helps in Risk Management, focuses on welcoming the changes we know are coming instead of sticking to the plan (estimates *require* a plan, otherwise what are you estimating?), and more importantly it requires customer collaboration for it to work. Unlike Estimates that focus on contract (the estimate) negotiation.
How to use #NoEstimates to manage your project? Take a look at an example I published a few months ago, and the data that supports this approach. After all, #NoEstimates is firmly grounded on empirical data collected over many (22 at last count) projects. Again, unlike estimates which by definition are not based on data. Estimates are rather guesses about future events.
Have you experimented with some form of #NoEstimates? Leave a comment below. Let's keep the conversation alive.

I was at a client recently and one VP was convinced that Agile was “untrue” and there was no way it could possibly work. The problem was that he had never heard of backlog grooming or getting stories ready. Once he saw the infographic below, the penny finally dropped and he understood how this crazy thing called Scrum can possibly work with user stories.

 

Jeff Sutherland points out the the best way to go fast is to have a definition of done (or “done done”) that means the software is shippable (coded, tested, documented, etc.).

The second best accelerator is to get stories ready (or “ready ready”) before the sprint planning meeting. For me, “ready ready” means that people understand stories well enough for the team to have a productive Sprint Planning meeting. Not one that takes ages and ages and stops because people have to catch a train or pick up their kids at daycare.

The purpose of the diagram is to provide a conceptual model for how stories get to be in a “ready” state. People need to talk about them and maybe do a little leg work. Who is responsible for getting stories ready? The Team! (Not the Product Owner as some might say). So good teams spend ~10% or their time getting ready for the next Sprint and ~90% on the current Sprint. Please note the amount of time will vary by team and project – 10% is a conceptual number.

Of course, most teams fall into the trap of focussing so much energy on the current Sprint they fall into the vicious cycle of low quality planning meetings and disorganized Sprints.

What if it takes more than “a little work” to get a story ready or to spilt a story? No problem, just create a Technical Spike story so that the whole team can tackle this tough story together. The outcome or acceptance test of the spike is that the story is split and that all the upcoming stories are “ready”.

The next rows in the diagram show that some people on the team may spend more time getting stories ready than others. For example, architects, SME (Subject Matter Experts), etc.  User Experience designers are often focussed on the Sprint ahead while docs folks are mostly on the last Sprint. Again the numbers here are conceptual.

Here are some other good posts on getting stories Ready:

• The Definition of Ready
• Ready-ready: the Definition of Ready for User Stories going into sprint planning

Happy Scrum!

Related posts:

1. Commitment is to People, not Sprints There is a lot of debate about Sprint Commitments in...

Related posts brought to you by Yet Another Related Posts Plugin.

In business, we’re often asked for estimates with too little context to understand the request. When that happens, we’re likely to expect the worst–that our estimate will be treated as a “guarantee not to exceed” and we’ll likely be in trouble at some time in the future. Of course we think that; we’ve been burned too many times in the past. Our fear of the consequences will encourage us to spend far too much time and effort trying to get the estimate “right” so we won’t be blamed.

If an estimate is really an estimate, then we know that it’s “wrong” in the sense that the subsequent actual reality is unlikely to equal it. The estimate is a guess, perhaps an educated guess, predicting the future. Predictions are hard, especially about the future.

Given these problems with estimates, why do we bother to make them at all?

We do so because we have a decision to make, and looking into the future helps us make that decision.

If we’re trying to decide which of two development efforts to pursue next, we’ll want to estimate the value and cost of each of them. Since both value and cost depend on the amount of time we spend doing the work, we’ll want to estimate the time and effort required.

If we’re trying to decide whether a project is worth doing, we want to estimate whether the value is greater than the cost. We may not care what are the actual value and cost, just that it will be profitable.

If project A is clearly more valuable and less cost than project B, it’s clear which to work on, assuming it’s also clearly more valuable than it will cost. But what if it’s not so clear? If project A and B are estimated as about the same value and about the same cost, which would you choose? Unless you have some guideline other than the estimates, it doesn’t matter. If project A will provide value that’s only slightly more than the cost, then we shouldn’t do it at all.

These are just two simple examples. There are many different reasons that a business will want to make forward-looking estimates. There are some caveats with estimating, of course.

Remember that these are JUST ESTIMATES.

We should not trust our estimates too much. Estimates are not data. Even if we’ve done well at predicting the future in the past, we might get this one totally wrong. We should expect our estimates to be off a bit, one way or the other, from what reality shows later. So if our decision is a close call, we should consider what we’d do if we had no estimate, or if the estimate came out differently. Only when the estimate clearly favors one choice over another should we trust it. Even then, we should validate our decision with real data as we go along.

Estimate to an appropriate level of precision

Since we know that our estimates are not data about future events, we should consider the amount of precision we need to make our decision. There’s rarely a need to estimate project completion to the day, or project cost to the dollar. If we think a project is worthwhile if it costs $100,000 but not if it costs $200,000, then we don’t need to estimate with any more precision than to the nearest $50,000. Using greater precision than we need increases the cost of the estimate without increasing its value for helping us decide.

Using an appropriate level of precision will also help us remember that these are estimates, not trustworthy data. There’s also some evidence that precision interferes with moving toward our goals.

Continually check and refine your estimates.

Estimation should not be a phase, that you do once and then hold onto it. Estimates give you a model to judge your progress against your expectations. It allows us to track our investment toward our goal. The actual progress acts as a check on our estimate, potentially giving us early warning of future disappointment–early enough to do something about it.

In the early 2000s, it was often said that “you don’t need to do design in Agile software development.” A lot of people were very dismissive of Agile software development because of comments like that. In truth, you do need to do design. You just don’t need to do it all up front. You need to do enough to see where you’re headed, and continue to question it and refine it as you learn more about what you need from the design. The same applies to estimation. We project into the future given what we know, track our progress, and make new projections as we learn more.

Don’t make this a big job, though. They’re still “just estimates.” Do a little at a time, but look at them frequently and regularly. Cross-check with other ways of estimating. Estimates are tentative; don’t put your full weight on them.

When they’re not agreeing with the subsequent reality, don’t blame the reality. Estimates give you a map; they’re not the territory. When these disagree, trust the reality. Does our decision still make sense? Would we decide differently, given what we know now? Are there possibilities that we didn’t consider when we made our first estimates? Should we change our decision, given where we are and what we know?

The estimates are not the goal, they’re just a tool. When we find they’re “wrong,” there’s no sense blaming the estimates or those who made them. They’re now a historical record of our previous thoughts and knowledge. Instead, use them as they’re meant to be used–as a tool for making decisions. And make new decisions.

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 1: THE SECRET CLUB

“Membership in the secret club carries with it the need to behave in certain ways that may not be your personal inclination. My advice would be to get some experience to get a clear-eyed understanding of what it looks like because it’s not a one size fits all.”

Running time 32:37

Have you made it in the secret club? What has your experience been like? If you opted out of the secret club, what prompted you to turn away and go in a different direction?

Leave a comment on this blog or email us at leadershippodcast@gmail.com

Summary
Intro – How do you get into the secret club?
7:37 – The secret club ideology may impact or alter one’s view of the meaning of leadership.
11:17 – What does it mean to be part of the secret club? Being aware of the demands and how will it impact your professional and personal life.
15:01 – Secret clubs are not one size fits all – understanding the differences and knowing what to expect.
20:17 – Leadership at the top – It’s about willing to work hard and building field experience.
25: 12 – The effect of generational differences on organizational leadership.
27:55 – Skewed perception of what it means to be at the top.

Photo Credit: ul_Marga via Compfight cc

Platons Zitat “Pánta chorei kaì oudèn ménei” ist die knappste Formulierung der Flusslehre Heraklits, die besagt: Alles fließt und nichts bleibt. Es gibt nur ein ewiges Werden und Wandeln. Sie ist eine Metapher für die Prozessualität der Welt. Das Sein ist das Werden des Ganzen. Das Sein ist demnach nicht statisch, sondern als ewiger Wandel dynamisch zu erfassen. (Wikipedia)

Das Leben ist Wandel, das wussten also schon die alten Griechen. Und wir sind im Flow, hier und jetzt, am besten. So besagt es die Theorie. Wir sind in unserer Energie und erschöpfen uns nicht.

Doch die Realität sieht meistens anders, zumindest meine sah anders aus.

Stunden um Stunden habe ich mit Budget-, Projekt- und Personalplanungen verbracht. Für nächste Woche, für nächsten Monat  – was ja noch gerade so geht. Fürs nächste Jahr – was eigentlich gar nicht geht. In einem Projektlaufzettel (ein hochoffizielles Dokument) habe ich tatsächlich den Begriff Glaskugelschätzung gefunden! Ich denke, da erübrigt sich jeder Kommentar. Und da Leben das ist, was geschieht, während man es plant, war ein Großteil der Planung innerhalb kürzester Zeit obsolet. Projekte kamen gar nicht, dafür fielen ganz neue vom Himmel, Budgets wurden gekürzt, Mitarbeiter kamen und gingen. Diese Art der Planung war für mich in höchstem Maße Zeitverschwendung, Geldverschwendung, sinnlos. Es war eine Verwaltung von Zukunftängsten, die nur dazu diente, eine gefühlte Sicherheit herzustellen, mühselig und erschöpfend. Geht es euch auch so wie mir damals?

Und dann kam Scrum.

Keine tapetenrollenlangen MS Projektpläne, die mich schon allein optisch überforderten. Stattdessen eine Vision entwickeln. Alle Ideen, Stories, Anforderungen in einem Backlog sammeln und priorisieren, aber nur noch drei Sprints im Voraus planen. Wow, schon das allein war eine Erleichterung

Keine stundenlange Kapazitäten-Planung für die nächste Woche mit den Projektleitern, die am Ende der Woche doch nicht gemacht hatten, was sie geplant hatten und jeder hatte tausend gute Gründe dafür. Dafür im Sprint Planning zu Anfang des Sprints mit dem Product Owner und dem Team den Umfang des nächsten Sprints besprechen, sich gemeinsam auf ein Sprintziel comitten. Kontinuierliche Fortschrittskontrolle im Daily und mit Hilfe des Burn Down Charts. Jeden Tag sehen können, wo wir gerade stehen. Kontinuierliche Planung statt Glaskugelschätzung.

Keine Jour Fixes mehr, kein Status, nur noch die Review Meetings mit den Teams. Wenn ich wissen wollte, wie der tagesaktuelle Status war, musste ich mich nicht mehr durch 50-seitige Power-Point-Berichte graben (kein Scherz!) und diverse Jour fixe mit Projektleitern einstellen. Ich bin still ins Daily gegangen, einen Blick auf Task Board und Burn Down Chart werfen und ich wusste innerhalb von 15 Minuten, wo das Team, das Projekt stand. Das ist übrigens mein Geheimtipp fürs Management: Einfach mal still das Daily verfolgen! Besser und effektiver kann man nicht mitbekommen, was im Team läuft und wie die Stimmung im Team ist. 15 Minuten pro Team jeden Tag. Mehr braucht man nicht.

Das Leben und Arbeiten machte plötzlich wieder Spaß. Die Ausrichtung auf ein gemeinsamen Ziel setzt ungeahnte Energien frei und gibt der Arbeit Sinn. Meine Teams und ich konnten jetzt Visionen entwickeln  UND umsetzen. Ganz entspannt im Hier und Jetzt. Go with the (Scrum-) Flow!

Related posts:

1. Schätzen vs. Planen?
2. First things first
3. Ferien und Sprints

By Kevin Meyer

A few months ago I told you how, in my past life as president of a medical device company, I had two reliable leading indicators of a potential customer relationship.  Basically if the customer demanded automatic annual price decreases, or if their payment terms were greater than net-30.  Those few customers that offered to pay faster would become strong partners as they knew supplier financial stability is in their best interest.  Those that tried to insist on longer terms just considered suppliers a necessary evil.  The correlation was nearly perfect.

Luckily my company supplied unique components, so we also had leverage.  Upon receipt of a request for long terms I'd fire back a letter saying that in my book the oft-forgotten "respect for people" pillar of lean also applies to suppliers (and customers for that matter), and trying to turn a relatively small supplier into a bank for a Fortune-50 was an affront to a productive relationship.  Our terms would remain net-30 or less, or we wouldn't take the order.  Occoasionally I received more pushback, including from a very large multinational, coincidentally in the news lately for "discovering" lean (in 2012...) and moving their appliance manufacturing back to the U.S., asking for net-120.  Sorry, still net-30 to you, buddy.

So imagine what went through my mind when The Wall Street Journal reported last week how many companies like Procter & Gamble are pushing to lengthen terms even further.

Procter & Gamble is planning to add weeks to the amount of time it takes to pay its suppliers, a shift that could free up as much as $2 billion in cash for the consumer products giant. P&G could use that cash to fund investments in new factories overseas or to help pay for stock buybacks.

Obviously there's another party to that transaction.

That added flexibility, however, will come at the expense of the companies that supply P&G with materials or services. The suppliers will have to tie up more of their own cash in receivables or eat the interest costs charged by banks to bridge the gap until P&G pays its bills.

Yep, that's partnership.  Turn your much smaller suppliers into a bank.  And sure, it could "free up" $2B in cash for the large customer, but obviously that reduces by $2B the cash those smaller suppliers have to develop new processes and technologies.  So who really loses in the end?

The moves are creating ripple effects. Companies that hold on to cash longer create deficits at suppliers that have to find financing, raise prices or squeeze other firms along the supply chain. Smaller companies with little bargaining power and less access to credit ultimately could see their costs rise, pinching funds that could otherwise be spent on hiring or investments.

And speaking of banks...

To help suppliers deal with the changes, P&G is working with banks that will offer to advance cash to suppliers after 15 days for a fee, some of the people said.

Wait... so not only are they sucking cash out of suppliers so they can't invest in the innovations that presumably their customers - and end customers - will want later, they are adding to overall supply chain cost by giving banks a piece of the pie.  I bet some of these companies even have the gall to call themselves "lean."

I was stewing over this when our friend Bill Conerly wrote a fantastic rebuttal to this nonsense in Forbes.  If I was the CFO of P&G I'd feel pretty ashamed, or just plain stupid, after reading it.  Not that most CFOs understand the real world anyway.

Procter & Gamble is about to lose money thanks to CFO hubris. It won’t be the only large corporation, however, to get caught up in false economy. The Wall Street Journal reported that P&G will extend its payment terms to suppliers. This sounds like normal corporate practice, and it is. But normal is not always good.

Bill then digs in...

I understand working capital management, but many of these corporations don’t understand.  P&G has a Aa credit rating on its bonds. It can probably float 60 day commercial paper for 0.10%.  Small companies with bank lines are often borrowing at 3.5% to 4.5% interest.  Many small businesses, though, are not eligible for bank lines. They may use finance companies to factor receivables, or even the owner’s credit card.  So 4.0% is very conservative as an estimate of borrowing cost for small business.

Let’s say that the small business sells the large corporation $100,000 of materials.  Instead of paying in 10 days, the corporation demands 75 day terms.  OK, that extra 65 days save the corporation $8.  (60/365 times 0.10% times $100,000).  What does it cost the small business to let the payment wait an extra 65 days?  $329.  (60/365 times 4.0% times $100,000).  So the big fish saves $8, costing the small fish $329.

Yep, that's partnership.  Have I said that before?  But here's the kicker: the stated reason for this nonsense is to "free up cash."  Is sticking it to the suppliers really the best way?

The idea mentioned in the article was to “free up cash,” but cash is readily available from cheaper sources. Perhaps Wall Street would rather see “accounts payable” on the balance sheet than “commercial paper outstanding.” After the recent financial crisis, one can get nervous about commercial paper becoming unavailable.  However, any company dependent on its suppliers needs to also worry about the suppliers’ credit being jerked away. History is full of examples of small businesses losing access to credit, to the detriment of their customers.

Bill then reaches a conclusion that the truly lean company will understand:

The focus of both parties to each supply agreement should be how to provide better products at lower cost. When one party gets too focused on getting the better side of the bargain, then the joint effort is less likely to succeed. If one of the parties in a transaction has to borrow, it should be the party with the cheaper debt cost.

Amen.  So next time a customer asks you for long payment terms, perhaps you should just ask them why their financial situation is so difficult that they want to use a much smaller supplier as a bank, risking your financial solvency let alone investment in new and improved processes, instead of tapping a much cheaper line of credit.  Fools.

Five months ago we formulated our vision for the new version of Enterprise Library. Now we are delivering on it. I’m excited to announce the latest release of Microsoft Enterprise Library: version 6.

What is Enterprise Library?

Enterprise Library is made up of application blocks, each aimed at managing specific crosscutting concerns. Crosscutting concerns are those tasks that you need to accomplish in several places in your application. When trying to manage crosscutting concerns there is often the risk that you/different team members will implement slightly different solutions for each task at each location in your application, or that you will just forget them altogether. Writing entries to a system log file or Windows Azure table storage, dealing with transient error conditions and validating user input are typical crosscutting concerns. While there are several approaches to managing them, the Enterprise Library application blocks make it a whole lot easier by providing generic and configurable functionality that you can centralize and manage.

Enterprise Library application blocks are standalone. They work well together, but you only have to get the ones that you need. They are also customizable and extensible, so you can extend them to provide what you need in your specific contexts. You can choose to use it as a seedwork and grow your own library, which you can later reuse and sell. We ship under MS-PL, so this is allowed.

What are the main themes for this release?

• Simplifying the library all around
• Embracing semantic logging
• Increasing resiliency to errors
• Enhancing Unity type registration
• Supporting Windows Store apps (Unity, Topaz)
• Streamlining programmatic configuration of all blocks
• Integrating with other technologies (ASP.NET MVC and ASP.NET Web API)
• Improving ease of learning, ease of experimentation (fast start), and ease of use

  What’s in the box?

• New block
• Semantic Logging Application Block (v1.0)
• New programmatic configuration
• Updated 7 blocks:
• Data Access Application Block
• Exception Handling Application Block
• Logging Application Block
• Policy Injection Application Block
• Transient Fault Handling Application Block
• Validation Application Block
• Unity Application Block/DI Container (v3.0)
• Configuration console (largely unchanged since v5)

As usual, we are shipping not only the binaries, but also the source code and test cases (unit, integration). To see the details of what have changed and deployment instructions, see the Release Notes.

The diagram below depicts all application blocks and their dependency on the Common package (needed to support configuration tool experience) and optional interblock dependencies.

 

Additionally, in the next couple of weeks we’ll be shipping a reference implementation and several Quickstarts to showcase how the Enterprise Library can be used in certain scenarios.

How to get it?

Our primary shipping channel for code is NuGet. There are 27 NuGet packages. Search for Unity or EntLib inside NuGet Package Manager.

Additionally, we’ve made all deliverables available as self-extractable zip packages via Microsoft Download Center.

Our guidance deliverables are available on Codeplex today. After post-production work is completed, they will be published on MSDN. You will also be able to order the hardcopies of the Developer’s Guides or get them in PDF, Epub or Mobi formats.

How to get started?

Whether you are experienced with Enterprise Library or new to it, we have guidance to help you make the most out of this release:

• Dependency Injection with Unity – new Developer’s guide (preview on Codeplex)
• Updated Developer’s Guide to Enterprise Library (preview on Codeplex)
• Updated reference documentation (preview on Codeplex)
• Reference implementation (v5 and v6) (available in May)
• Reference API (on MSDN)
• Quickstarts (available in May)
• New Migration Guide to help you move from v5 to v6
• Videos (on Channel 9)

The table below will help you orientate:

Do I have to upgrade?

Strictly speaking, no. If you are happy with Enterprise Library 5.0, you can continue using that version. If the new and improved features of Enterprise Library 6.0 appeal to you, then you would want to migrate. Note: Enterprise Library 6.0 targets .NET4.5 framework only. Enterprise Library 5.0 works fine on .NET3.5, .NET4.0 as well as .NET4.5. So, in order for you to move to .NET4.5, you don’t have to upgrade.

How to get help and provide feedback?

Many people provided feedback on our vision, our backlog and CTPs. We thank you all.

If you’d like to provide further feedback, please post it via the Codeplex forum. This is where you can also get support. We have a dedicated sustained engineering team monitoring the forum regularly. To report a bug, use online Issue Tracker.

If you have a story of how your team leverages EntLib and would like to share it with the broader community, please contact us. We’ll be happy to work with you on a case study.

Happy coding!

Sainsbury's slimline toilet roll to wipe 140 tonnes from carbon emissions

Supermarket launches new roll with 11mm shaved off cardboard tubing, meaning about 500 fewer lorry trips a year

...

 

http://www.guardian.co.uk/environment/2012/apr/20/sainsburys-toilet-roll-carbon-emissions

 

[mentioned on the QI show last week]

I've had a beard since the start of the year. 

This evening I had a little learning experience when I realised - too late - that the previous time I used it I finished on setting 2 (low, for tidying up the edges) without resetting it setting 5 (middling length).

Today I'm a 2 all over.

ooops.

Richard Hundhausen has put together a great list of funny Scrum/Agile related videos. Some of these are classics such as High Moon Studios: Portrait of Scrum and Adam Weisbart’s Shit Bad Scrum Masters say.

Be warned, not all of these are actually that funny. I’ve never found The Downfall of Agile Hitler to be funny, because the original film is harrowing and difficult to watch. I also find the Scrum Haka to be trite and unwatchable … this is what a real haka should look like.

So here’s the list and, once you’re done (in the words of Adam Weisbart), “Get back to work!”

I want to run an agile project http://www.youtube.com/watch?v=4u5N00ApR_k I want to run an agile project (part 2) http://www.youtube.com/watch?v=lAf3q13uUpE The Power of Scrum (Ian Sense Scrum Master) http://www.youtube.com/watch?v=P6v-I9VvTq4

The making-of http://www.youtube.com/watch?v=ncjdtqf1gSg Developer Abuse http://www.youtube.com/watch?v=LYlhCGng5Mk Spooning and pair programming http://www.youtube.com/watch?v=dYBjVTMUQY0 Improving Sprint Reviews (is that Jeroen?) http://www.youtube.com/watch?v=fpBQ5yxrR_c The Downfall of Agile Hitler http://www.youtube.com/watch?v=l1wKO3rID9g High moon studios: Portrait of Scrum http://www.youtube.com/watch?v=UT4giM9mxHk Shit Bad Scrum Masters Say http://www.youtube.com/watch?v=GGbsgs611MM The Scrum Haka (hideous) http://www.youtube.com/watch?v=Qvqq97unS2w Joe Justice Team WikiSpeed http://www.youtube.com/watch?v=x8jdx-lf2Dw Deathstar Project Deployment Meeting http://www.youtube.com/watch?v=2T5QNcb_Z8g Raking Leaves – A Scrum/Agile Approach http://www.youtube.com/watch?v=StBS-loIIz4 I Need Agile Methodology http://www.youtube.com/watch?v=nvks70PD0Rs

Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.

When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!

The Product Owner role is the most difficult in Scrum to do well. This Learning Event solves that problem by giving you real practical techniques that you can apply immediately!

Learning Objective(s): Create a Product Backlog that allows your Scrum team to start delivering value quickly.

Days: June 25, 2013, June 26, 2013

Location:

Audience: This course is designed for those who care about the business success of their products and projects: product managers, project managers, business unit leaders and business analysts. Some basic knowledge of Scrum is recommended prior to attending this Learning Event.

Price: $1600.00

Contact: Valerie Senyk at 1-905-868-9995

Email: valerie@berteigconsulting.com

Link to Register: http://www.worldmindware.com/Certified-Scrum-Product-Owner-Mississauga-June-2013

 

Refactoring can pry panic’s fingers away from your poor, overburdened adrenal glands and restore your sanity. Not that it went missing, of course. Never that! This talk will cover the two reasons why refactoring works as well as (or better than) whiskey, sky diving, and massages as therapy, explore a handful of effective strategies to [...]

If you find you can't keep up with the world around you, then break things down.  Breaking things down is the key to finishing faster.

Breaking things down is also the key to agility.

One of the toughest project management lessons I had to learn was breaking things down into more modular chunks.   When I took on a project, my goal was to make big things happen and change the world. 

After all, go big or go home, right?

The problem is you run out of time, or you run out of budget.  You even run out of oomph.  So the worst way to make things happen is to have a bunch of hopes, plans, dreams, and things, sitting in a backlog because they're too big to ship in the time that you've got.

Which brings us to the other key to agility ... ship things on a shorter schedule.

This re-trains your brain to chunk things down, flow value, chop dependencies down to size, learn, and, move on.

Best of all, if you miss the train, you catch the next train.

Unlängst schilderte mir ein guter Bekannter, ein Unternehmensberater, dass er eine Führungskraft zu unterschiedlichen Ausprägungen ihrer Kompetenz befragte. Er wollte mit der betreffenden Person gemeinsam Handlungsfelder identifizieren, in denen diese sich entwickeln könnte. Es kam allerdings heraus, dass die Führungskraft mit dem Stand ihrer Entwicklung vollends zufrieden war und dass aus ihrer Sicht derzeit kein wirklicher Handlungsbedarf bestand. Etwas irritiert erzählte mir der Bekannte, dass er sich über die vollkommen übersteigerte Selbsteinschätzung dieser Führungskraft ärgerte und er gar nicht verstehen könne, dass die Diskrepanz zwischen seiner Meinung und der der Führungskraft so groß war. Er begründete seinen Ärger mit den Worten: „Das ist so typisch. Sie (die Führungskraft) denkt tatsächlich, dass sie schon alles weiß. Es gäbe so viel zu verbessern. Ich habe die Arroganz und Ablehnung in ihrem Gesicht gesehen. Wie kann man nur so von sich überzeugt sein!“ Ich stutzte, sah meinen klagenden Bekannten mit einem Schmunzeln an und erwiderte: „Du hörst dich an wie Othello.“ Fragend sah er mich an: „Othello? Was hat der denn damit zu tun?“

Der Othello-Effekt

Othello, Feldherr in der Republik Venedig und mit der wunderschönen Desdemona verheiratet, wurde das Opfer einer Intrige. Ihm wurde der schreckliche Floh ins Ohr gesetzt, dass Desdemona eine Affäre mit seinem bestem Freund Cassio hätte. Der voreingenommene und rasend eifersüchtige Othello konfrontierte seine Ehefrau mit dieser Anschuldigung, forderte sie auf zu gestehen und beging dabei den Fehler, ihren unter Tränen vorgebrachten Unschuldsbeteuerungen keinen Glauben zu schenken. Rasend vor Eifersucht erwürgte er sie, nachdem er zuvor bereits ihren angeblichen Geliebten getötet hatte. Othello sah, dass Desdemona offensichtlich Angst hatte, als er sie zur Rede stellte. Als sie dann auch noch zu weinen begann, nachdem sie von Cassios gewaltsamen Tod durch die Hand ihres Mannes erfahren hatte, fühlte sich Othello zusätzlich bestätigt. Für die Tränen seiner Frau auf die Nachricht vom Tod ihres Geliebten und für die Angst in ihrem Gesicht konnte es nur eine Erklärung geben: Sie musste schuldig sein. Desdemonas Angst war für Othello ein Schuldbekenntnis des Ehebruchs, der ans Licht gekommen war.

 

Othello hatte Desdemona leider – wie sich später herausstellen sollte – zu Unrecht getötet und zwar ohne anderen Ursachen für die Angst und Pein seiner Ehefrau Raum zu geben: Dass nämlich Desdemonas Angst die Reaktion einer unschuldigen Frau sein könnte, die wusste, dass ihr von Eifersucht geblendeter Ehemann im Begriff war sie umzubringen. Und sie hatte ja keinerlei Möglichkeit mehr, ihre Unschuld zu beweisen, weil der Einzige, der es hätte bestätigen können, bereits tot war.

 

 

Emotion verrät uns nichts über ihren Ursprung

Emotionale Signale, wie z.B. Ärger, Überraschung oder in Othellos Fall Angst, verraten uns nie etwas über ihren Ursprung oder anders ausgedrückt (vgl. Ekman, 2011, S. 80ff):  Wenn ich das Was kenne, weiß ich noch lange nichts über das Warum. Wollen wir den Othello-Effekt vermeiden, müssen wir daher der Versuchung widerstehen, zu rasche und einseitige Schlüsse zu ziehen. Dies gelingt uns nur, wenn wir uns darum bemühen, neben der für uns offensichtlichsten, also der erstbesten Ursache für ein Gefühl, mindestens eine Erklärungsalternative zuzulassen.

 

Wenden wir uns mit dieser Erkenntnis erneut meinem Bekannten zu. Die Führungskraft reagierte auf sein Weiterentwicklungsangebot mit arroganter Ablehnung. Die offensichtlichste Ursache lag für meinen Bekannten auf der Hand: Die Führungskraft erkannte keinen Handlungsbedarf für sich. Diese ablehnende Haltung wurde durch die Erwartungshaltung meines Bekannten verstärkt, der aus seiner Sicht Handlungspotentiale identifiziert hatte und daher mit einer ganz anderen Reaktion gerechnet hatte. Fremd- und Selbsteinschätzung gingen vollkommen auseinander. Mit freundlichen Grüßen, Othello.

 

Welche weiteren Ursachen könnte das ablehnende Verhalten der Führungskraft gehabt haben? Antworten finden sich, wenn wir uns Fragen nach alternativen Ursachen stellen:

 

• Welche Erfahrungen hatte die Führungskraft in der Vergangenheit mit Weiterentwicklung gesammelt?
• Welchen Anteil hatte der Berater und die Art und Weise seines Angebots, dass die Reaktion so ausgefallen war?
• Wie würden der Vorgesetzte der Führungsraft oder das Team reagieren, wenn sie wüssten, dass diese noch Handlungsbedarf in punkto Führung hat?
• Was wohl andere Führungskräfte über mögliche Defizite dieser Führungskraft denken?

 

Wie ihr seht, eröffnen die Fragen mehrere, alternative Zugänge auf Ursachen für die Reaktion bzw. Emotion der Führungskraft. Der Othello-Effekt ist in unserem Alltag allgegenwärtig und handlungsleitend. Achtet darauf und nehmt euch Zeit dafür, Ursachen zu erforschen. Wenn ihr bei eurem Gegenüber eine Emotion wahrnehmt, dann bewertet sie nicht gleich. Oder, wenn ihr das tut, dann denkt an Othello und gebt einer zweiten Meinung zu eurer Bewertung eine echte Chance.

 

Und in Teil 2 von ScrumMaster sind Meister der Effekte und Illusionen geht es um den Halo-Effekt und seinen Einfluss auf die Teamleistung und die Teamkommunikation.

 

Literatur

Ekman, P. (2011). Gefühle lesen. Wie Sie Emotionen erkennen und richtig interpretieren. Spektrum.

Related posts:

1. Der ScrumMaster ist eine Versicherung (Mike Beedle)
2. Über das Schreiben | Schreibblockaden
3. Über das Schreiben | Leidenschaft

Any sports coach knows that the Team must have desire.

In my classes I talk to the people about how much improvement they expect to make in 1 year. With 1 team.  Often it is in the 20% range.

And I use Henry Ford’s famous quote: “Whether you think you can, or you can’t, you’re right.”  So, I usually think that 100% improvement in 1 year is realistic for a specific team.

As a coach or a SM, if they are going to achieve hyperproductivity, the Team must want it.  And, to some degree, they must believe it is possible.

So, the question becomes, how do you get them to have the desire?

This is not an easy thing. In fact, you cannot make them have desire.  But, if there is something inside them, you can draw on that.  You can blow on that ember of desire, and make it blaze.

Sometimes you can give them a challenge. To be the best team in your company, or your state.  For example. Or to be much better than they are today, and prove that with metrics.

In Lean, we have the idea, expressed in a Lexus ad, of the ‘continuous pursuit of perfection.’  So, we establish a vision of perfection. (Usually we know this vision is not perfect, or later we see it is not really perfect.  But it motivates us; it gives us something concrete that seems within our grasp.)  So, we use the vision of perfection to build the desire.

Little’s Second Law: People are remarkably good at doing what they want to do.

So, if you can help them build their desire, in a concrete way, then they can start to make the changes that can drive tremendous improvement.

The key members from the technology group are waiting to hear about the new project that the director is going to announce. The meeting is about to begin, and the room is filled with silence. They know that the project has something to do with Java, Oracle, and the cloud. The director starts explaining the importance of this strategic project and delivering it on time to the customer.

Read the complete article on  Cutter